Public sector software pricing works nothing like commercial SaaS pricing, because an agency buyer has to defend the spend in public, inside a fixed budget cycle, against written evaluation criteria. To price software for public sector buyers you build a documented cost baseline, choose a pricing model the agency can actually fund, map that model to the contract type that carries the risk, then write a price narrative an evaluator can trace line by line.
Below is the framework I walk vendors through first, the cost ranges agencies tend to see, and the mistakes that quietly turn a winning bid into a losing business.
Table of Contents
- The 8-step framework for pricing software for public sector buyers
- How to price software for public sector buyers: typical cost ranges
- What is the best pricing model for public sector software?
- Which contract type changes your price the most?
- What affects the price of software for public sector buyers?
- How to estimate the public value of the software
- How to build a proposal that is easy for a public buyer to approve
- How to handle change requests and scope creep
- Ways to save on software costs for public sector buyers
- Frequently Asked Questions
- How do I price a software product for a public sector buyer?
- What is the rule of 2 in government contracting?
- How do you justify a software price to a government agency?
- What margin is typical on public sector software contracts?
- What are the tools of procurement?
- What software is available for government contractors?
The 8-step framework for pricing software for public sector buyers
- Read the price section of the solicitation first. Section L or Section M tells you how price is weighted and whether the agency buys lowest price technically acceptable or best value.
- Identify the contract vehicle. Direct purchase, a cooperative master agreement, or GSA Schedule each cap how much pricing freedom you keep.
- Build the fully burdened cost baseline. Hosting, support, engineering time, compliance, and the cost of selling to government, all loaded.
- Price compliance as its own line. Section 508 and WCAG accessibility work, security reviews, and SOC 2 reporting cost real money and belong in the estimate.
- Pick a pricing model the agency can budget. Per-seat, tiered, usage-based, or outcome-based, depending on how the buyer already funds software.
- Set your margin and write down your floor. Most public sector software work lands in a 7 to 15 percent band, with 8 to 12 percent fee common on cost-reimbursable work.
- Validate against public data. Check prior awards on USAspending.gov, labor wage determinations on SAM.gov, and competitor list prices on GSA Schedule.
- Document the assumptions and run a sanity check. Labor mix, hours, escalation, and indirect rates all written down before submission.
Steps one and two take an afternoon. Steps three through six take a week of real work, which is why pricing should start at capture rather than two weeks before the close date.
How to price software for public sector buyers: typical cost ranges
These are typical US ranges. They vary by region and change over time, so treat them as a sanity check on your own model rather than a quote you can hand to a buyer.
| Project type | Buyer size | Annual software and implementation range (USD) | Pricing model | Usually excluded |
|---|---|---|---|---|
| Sandbox or pilot | One department, roughly 50 to 200 named users | 25,000 to 90,000 | Per-seat subscription, twelve-month term billed up front | Data migration, custom integrations, training beyond onboarding |
| Department rollout | 200 to 1,500 users across several teams | 90,000 to 400,000 | Tiered subscription with implementation milestones | Legacy data conversion, hardware, agency staff time |
| Multi-department platform | 1,500 or more users, several departments, multi-year | 400,000 to 1,500,000 and up | Enterprise agreement on a cooperative master agreement or GSA Schedule | Third-party fees, agency internal labor, ongoing custom development |
On a per-seat basis, most government SaaS deals I see quoted fall between 25 and 150 dollars per user per month, with the wide end reserved for products that carry implementation services inside the subscription. Permit and case management platforms sit at the higher end because they carry integration work; data portals and dashboards sit lower because they mostly deliver software.
The simplified acquisition threshold matters here. It is the dollar level at which a federal buyer may use simplified acquisition procedures under FAR Part 12 instead of running a formal solicitation, and it currently sits at 250,000 dollars for the fiscal year. The micro-purchase threshold is far lower, in the low five figures. Both are set by statute and get adjusted, so confirm the current figures before you build a bid strategy around them.
What is the best pricing model for public sector software?
There is no single best model. The best pricing model for public sector software is the one that matches how the agency already funds technology, because an agency cannot approve a pricing structure it cannot put on a purchase order.
| Pricing model | How it is billed | Buyer acceptability | Where the risk sits |
|---|---|---|---|
| Per-seat subscription | Fixed monthly or annual fee per named user | Very high, because agencies already own seats in other tools | Vendor, if the agency keeps adding and removing seats late in the term |
| Tiered by department | One annual fee per tier, priced on modules and user bands | High, and it lets a small department start small | Shared, once you define expansion rules clearly |
| Usage or consumption based | Fee on records processed, transactions, or API calls | Mixed, because the agency cannot forecast consumption from a budget line | Buyer usually, and overage disputes are common |
| Milestone linked | Payments tied to accepted deliverables, usually for services | High, and it protects a buyer with thin cash flow | Vendor, on schedule pressure during delivery |
| Outcome or value based | Fee tied to a measured result such as permit turnaround time | Growing, especially for visible operational wins | Vendor, unless the baseline and measurement are fixed in writing |
| Support and hosting only | Annual fee for an agency-owned instance | High where the agency already owns infrastructure | Split, and renewal terms decide who wins |
Value-based pricing has the most upside and the most risk. If you charge a share of the savings you create, write down the baseline before the pilot starts, agree on who measures it, and cap the fee. One line item I have seen sink a good proposal is a phrase like guaranteed savings with no method attached. Evaluators cannot justify that line internally, so they cut it.
Which contract type changes your price the most?
Risk allocation is where the money moves. The same scope priced under a firm fixed price and under a cost-reimbursable agreement can differ by 15 to 25 percent, entirely because of who absorbs an overrun.
| Contract type | How the price is set | Who carries cost risk | Margin implication |
|---|---|---|---|
| Firm fixed price | One agreed total for defined scope | Vendor | Quote your overrun risk explicitly, usually 8 to 12 percent for defined scope |
| Firm fixed price with options | Base price plus priced option years | Vendor | Keeps current-year margin thin while funding a longer relationship |
| Time and materials | Ceiling price against hours and rates | Split, with a not-to-exceed cap | Bounded but thin; rate realism gets audited |
| Cost reimbursable | Allowable cost plus a fee | Buyer | Lower fee, commonly 8 to 12 percent, with audit exposure |
| IDIQ with task orders | Ceiling for the vehicle, price set per order | Vendor on each order | Ceiling limits upside, so price each order properly |
The rule of thumb from experienced GovCon practitioners holds up: the more defined the scope, the more a fixed price is fair to both sides. If the agency cannot describe the deliverable, do not accept a fixed price, and a good pricing conversation will say so.
One phrase that shows up constantly, the rule of 2 in government contracting, is not a real federal pricing rule. It appears on shortlist and certification pages as shorthand for small-business participation and set-aside goals. It does not set your price, it does not override the simplified acquisition threshold, and it never overrides FAR cost principles.
What affects the price of software for public sector buyers?
Hosting and infrastructure are the easy part, and they are usually a minority of a government software price. The bigger drivers sit in the lines vendors forget to estimate.
- Product scope and module count. Every added module adds testing, documentation, and support load that never goes away after go-live.
- Integrations. Each connection to a permitting system, a utility billing platform, or a state identity service is real interface work plus ongoing monitoring when the other side changes.
- Data migration. Cleaning and loading records from a legacy system is the single most common source of change orders in public sector software deals.
- Accessibility. Section 508 for federal buyers and WCAG conformance generally require remediation, testing, and a conformance report, which is priced work, not a checkbox.
- Security and assurance. Security questionnaires, SOC 2 maintenance, and penetration testing all sit on the seller’s side of the line.
- Implementation and training. Configuration, onboarding sessions, and administrator training for staff who rotate through the role every couple of years.
- Procurement overhead. Proposal cost, capture time, security review, and the legal review of contract terms. These belong in the model even when the contract does not reimburse them.
- Contract duration and escalation. A five-year term with no escalator loses value every year, because your costs do not stay flat.
- Total cost of ownership. Agency staff time, internal licensing, storage, and the cost of the process change the software is meant to improve.
For services-heavy work, contractors usually bill on a convention of about 1,920 billable hours a year rather than 2,080, because paid time off already sits in the fringe rate. Every service contract priced under the Service Contract Act also carries a government-set health and welfare rate, currently around four dollars an hour, that has to be funded in the estimate. Pull the current wage determination from SAM.gov rather than working from memory.
How to estimate the public value of the software
A price justified by outcomes is far easier to approve than a price justified by feature count. The work is connecting each feature to something a budget owner already reports on.
Start with what the department is measured on. A permitting office cares about application turnaround and the backlog. A transit agency cares about on-time performance and how many riders use the trip planner. A city IT department cares about service-request resolution time and the number of systems it has to keep patched. A parks or energy team cares about inspection coverage.
Then build the arithmetic in three lines: current state, expected state, and the assumption behind the gap. If a permitting office processes 400 applications a month and each takes nine staff hours today, that is 3,600 hours a month. If the software takes six, that is 2,400 hours a month, or 14,400 hours a year. State the staffing assumption behind those hours. Evaluators respect the arithmetic even when they do not accept the conclusion.
Document every assumption in writing: sample size, time period, whether the baseline includes overtime, who collects the data, and when it gets measured. This protects you as much as it protects the buyer.
Avoid promising guaranteed savings or fixed outcome language in a proposal. Agencies have budget rules that make guaranteed savings awkward to record, and an auditor downstream will ask who validated the number.
How to build a proposal that is easy for a public buyer to approve
The proposal that wins public sector software work is usually not the sharpest one. It is the one an evaluator can score without a meeting.
Split the response into layers: the must-have requirements that answer the solicitation line by line, optional modules priced separately, implementation services priced by milestone, ongoing subscription costs, and a list of assumptions. When an option can be dropped without breaking the base product, an agency can actually use the option line to stretch a budget, which is how you get to a yes.
Then attach acceptance criteria to each line. Define what the agency receives, in what state, and how it gets verified. An evaluator worried about being blamed for a bad purchase will pick the bidder who made their risk smaller.
On fixed price versus time and materials: use fixed price where scope is genuinely defined and you can absorb variance, and time and materials where discovery is still happening or the agency itself does not know what it wants. Pricing an undefined scope as fixed price just moves the argument to the change order.
It helps to know what happens on the other side of the quote. Procurement practitioners on public forums describe a frustrating pattern: quotes arrive as a single number with no breakdown, and the agency cannot compare it against anything or defend it internally. Your competitor is not only the other vendor, it is the easy path of doing nothing.
The tools of procurement on the buyer side are the same ones worth knowing: electronic procurement systems such as SAM.gov for solicitations and vendor registration, USAspending.gov for what comparable agencies paid, FPDS-NG for award details, and the contract vehicle itself. If you can quote from those records, your price arrives already supported.
How to handle change requests and scope creep
Public sector software scope creep usually arrives politely and in writing. A new integration request, an extra report, a data extract someone needs before election, a new accessibility standard. None of those are the buyer’s fault. They still cost you money if you have no change-control process.
Put the process in the contract before signature. Define who can request a change, the written form required, the review window, and the categories of work that count as a change rather than a defect fix. Then hold the line on the review window, because a change approved verbally in a meeting is the one that ends up free.
Sample language for a change request: This request adds a new interface to the state licensing system and a custom reporting format. We estimate a schedule impact of three weeks and will provide a cost estimate within five business days of receiving this request in writing. Work begins on written authorization from the contracting officer.
Two details save the most time. First, define defect correction separately from enhancement work, so a complaint is never quietly logged as a new feature. Second, cap the number of included iterations per deliverable, such as two rounds of review comments, with anything beyond that treated as a change.
Ways to save on software costs for public sector buyers
Buyers and vendors both have levers here, and the honest ones do not hide costs in later years.
- Start with a pilot on a small, real dataset. A six-month pilot at one department costs less than a failed rollout and tells you what the integration work actually is.
- Use open standards for data exchange. Anything that keeps exports in standard formats caps the cost of leaving later, which buyers care about deeply.
- Limit customization. Every configuration choice is support debt. Prefer configuration settings over unique forks of the product.
- Phase the implementation. Roll out by department or by workflow rather than big-bang across the whole agency.
- Bundle support and hosting. One annual fee is easier to approve and easier to renew than four line items.
- Reuse existing integrations. Many agencies already pay for an identity or data platform; connecting to it costs less than building a parallel stack.
- Negotiate a renewal cap. A fixed percentage escalator, or a cap tied to a published index, protects both sides from surprises at renewal.
- Price the pilot as the pilot. A low pilot fee that requires a full re-negotiation later wastes buyer time and rarely wins the follow-on.
Some savings are illusions. Discounting year one heavily and raising renewal sharply looks like a bargain at signature and becomes a budget fight at month thirteen. Cheap per-seat pricing that excludes implementation pushes the real cost into a change order. Cutting support to hit a number usually shows up as slow incident response, which the agency pays for in staff overtime.
For the vendor side, the cheapest savings measure is bid discipline: decide whether to bid before you build the cost model, not after. A well-chosen no-bid protects your team for a pursuit that fits.
Frequently Asked Questions
How do I price a software product for a public sector buyer?
Build a fully burdened cost baseline first, then add a documented fee, then choose the pricing model the agency can fund. Document your labor mix, hours, indirect rates, and escalation assumptions in a price narrative. Validate the number against prior awards on USAspending.gov and competitor list prices on GSA Schedule before you submit it.
What is the rule of 2 in government contracting?
There is no universal rule of 2 that governs how you price a government software contract. The phrase circulates as shorthand for small-business participation and set-aside goals on shortlists. It does not set your price, does not change the simplified acquisition threshold, and does not override the cost principles in the FAR. Price your actual costs plus a defensible fee.
How do you justify a software price to a government agency?
Tie each line to a documented cost or a measurable outcome. Fully burdened labor comes from your payroll and the SAM.gov wage determination, not from a market average. Software lines come from hosting and support records. Outcome lines come from a baseline you measured before the pilot, with the assumption stated in writing. Traceable beats optimistic with evaluators.
What margin is typical on public sector software contracts?
Most practitioners put public sector software margins in a 7 to 15 percent band, with fees around 8 to 12 percent common on cost-reimbursable work. Fixed price work for well-defined scope can sit higher because you carry the overrun risk. Multi-year terms without an escalator quietly compress that margin every year, which is why escalation belongs in the base proposal.
What are the tools of procurement?
On the buyer side, the main tools are SAM.gov for solicitations and vendor registration, USAspending.gov for award history and spending data, FPDS-NG for individual award details, and the contract vehicle that structures the purchase. Vendors use the same sources to check who bought similar software, what they paid, and whether the price fits an active contract ceiling.
What software is available for government contractors?
Government contractors buy a fairly predictable set of categories: proposal and capture management, contract and compliance tracking, time and expense reporting, security and compliance tooling, and data analytics on spend. Procurement staff look for the same categories plus records management and case management. Availability is rarely the hard part, so focus your effort on integration and contract fit instead.
If you do one thing this week, open your last government quote and rebuild it line by line: real hosting cost, real support cost, real compliance cost, then a fee you can defend out loud. If the total holds up against what agencies actually paid, you have a price. If it does not, better to find that out before the solicitation closes.
