Grants management software pricing is not transparent. None of the major platforms publish their pricing on a public page, SmartyGrants included. You have to request a quote, sit through a discovery call, and receive a proposal tailored to your organisation's size and requirements. This is a common practice in B2B software, and it is not inherently dishonest — but it does create a comparison problem for buyers who are trying to make a responsible procurement decision.
This article is for the grants manager or operations lead who is partway through an evaluation and trying to understand what they are actually comparing. It applies to any grants management platform. SmartyGrants is the relevant reference point for most Australasian buyers, so the structure of their pricing model is worth understanding — not to criticise it, but because understanding what you are paying for helps you ask the right questions of every vendor on your shortlist.
Three different pricing models exist in the market, and they produce very different total costs depending on how your programme operates.
Per-user seat pricing charges based on the number of staff accounts on the platform. This model is predictable if your team size is stable, but can become expensive as you scale. It also creates an incentive to limit access — which has downstream effects on process design when you have part-time staff, external assessors, or board members who need read-only access to certain records.
Per-application pricing charges based on the volume of grant applications processed through the platform. This model can look attractive at low volumes and unpredictable at high ones. Organisations running high-volume community grant rounds — hundreds of applications per round — may find this model penalises their programme activity rather than enabling it.
Annual licence with add-on modules is the most common structure for established platforms. A base licence covers core functionality, with additional charges for features such as advanced reporting, assessor portals, applicant portals with specific capabilities, or integrations with finance systems. This model can offer good value if your organisation's needs map closely to the base product — and significant cost overruns if you discover the features you actually need are all in the premium tier.
Most quotes from established vendors combine elements of all three: a base annual licence, per-user charges for staff accounts above a certain threshold, and module fees for capabilities beyond the standard offering. Understanding which element drives the largest proportion of your total cost is the key question to ask before you accept a proposal.
SmartyGrants does not publish specific pricing, and this article will not speculate on figures. What is well understood from the market is the general architecture.
The pricing structure typically includes an annual licence fee scaled to the organisation's size or grant-round volume, per-user charges for administrator and assessor accounts, and optional module fees for capabilities such as an assessor portal, advanced reporting, or API access. Implementation — the work of configuring the platform to your processes, migrating existing data, and training your team — is typically either a separate project fee or a time-and-materials engagement.
This structure is not unusual. It mirrors how most enterprise software is sold. The point worth noting is that the components add up in ways that are not always visible from the initial proposal, particularly when implementation is quoted separately from the licence.
The most common evaluation mistake is comparing annual licence fees without accounting for the full cost of operating the platform over a three-year horizon.
Implementation cost. A platform implementation for a mid-sized grants programme typically involves configuration (setting up your workflows, form templates, and process logic), data migration (moving historical grant records, grantee contacts, and active programmes from your current system), and training. If implementation is billed separately, it can add a material amount to year-one costs that does not appear in the headline licence comparison. Ask specifically how the vendor supports the transition period — the productivity dip during the first two or three grant rounds is real and rarely appears on a vendor proposal.
Workarounds for missing features. Every platform has gaps. The question is what your organisation will do when it encounters them. Workarounds are not free: they require staff time, introduce error risk, and create shadow processes that sit outside the platform's audit trail. If assessment management lives in the platform but post-award management requires a spreadsheet, you are running a hybrid system with all the operational overhead that implies. Count that cost against the platform.
Integration costs. Most grants programmes eventually need the grants platform to talk to a finance system, a CRM, or a reporting tool. Integration can be a standard feature, a premium module, or a custom development project. Understand which category applies before you finalise your comparison.
The word "configurable" appears in every grants management software pitch. It is not meaningless, but it requires interrogation.
There is a difference between a platform that is configurable by the grants manager using built-in tools, and a platform that is configurable by a developer or implementation consultant who charges by the day. Both might accurately be described as "configurable." Only one of them lets you adjust your assessment criteria before next month's round without raising a support ticket.
When a vendor describes their platform as highly configurable, ask: "Who does the configuring, and what does that cost?" If the answer is "our professional services team" or "your Salesforce admin" or "contact your account manager for a scoping conversation," the configurability is not a feature you control. It is a budget line you have not yet quantified.
This matters particularly when your grant programmes change — new funding streams, revised eligibility criteria, changed reporting requirements. If adapting to those changes requires professional services engagement every time, the operational cost of the platform is higher than the licence fee suggests.
These questions apply to any grants management platform, not just SmartyGrants. They are designed to surface costs and constraints that vendor proposals typically do not foreground.
1. What is included in the base licence, and what requires an add-on or additional fee? Ask for a written list of features that are not included in the quoted package.
2. What does implementation cost, and is it included in the first-year quote? Get implementation scoped and priced explicitly, not as a vague "setup fee."
3. How are assessor and applicant accounts priced? Specifically: does adding external assessors or increasing applicant account capacity change the licence cost?
4. What does post-award management look like in the platform? Ask to see milestone tracking, contract management, and accountability reporting in a live demonstration — not slides.
5. How does the platform handle changes to your process mid-programme? Ask who makes configuration changes, how long they take, and what they cost.
6. What does integration with your finance system cost and require? Ask whether finance integration is native, a premium module, or a custom development, and what the ongoing maintenance responsibility is.
7. What is the data export process? You need to know you can get your data out cleanly if you switch platforms in three years. Ask to see a full data export from a completed grant record.
8. Where is data hosted, and does it meet your organisation's compliance requirements? For NZ government agencies and Crown entities, data residency and NZISM alignment are not optional considerations.
9. What does the audit trail look like, and is it exportable? For publicly-accountable organisations, an immutable, exportable audit trail is a practical compliance requirement.
10. What do existing customers say about implementation and ongoing support? Ask for references from organisations of similar size and complexity. Talk to them directly, not through the vendor.
The distinction that matters most in the GMS market is not between vendor A and vendor B. It is between platforms that were designed as grants management systems and platforms that were adapted from another foundation — typically CRM, case management, or generic workflow software.
Adapted platforms can cover grants management adequately, and many organisations operate them successfully. The cost pattern tends to be higher configurability fees (because the underlying model was not designed for grants), more frequent workarounds (because the data model was not built around grant rounds, milestones, and accountabilities), and more dependency on consultants or internal specialists to maintain the configuration.
Purpose-built platforms make different trade-offs. The configuration space may be narrower — because the product was designed for a specific set of workflows — but the cost of operating within that space tends to be lower. Features like milestone-triggered payment approvals, blind assessment workflows, and audit-ready reporting exist as standard functions rather than custom builds.
This is not an argument that purpose-built is always better. It is an argument that the distinction is relevant and should be part of your evaluation framework. Ask each vendor: what is this product built on, and what was it originally designed to do?
The right evaluation question is not "which platform is cheapest?" but "which platform costs the least to operate well, over the lifetime of our use?" Those are different questions with different answers.
If you would like to see how Tahua is priced — including what is and is not included — book a 30-minute walkthrough.