What a fixed-budget software project actually includes, and how to read a fixed bid
Every engagement we run is a fixed number agreed before work starts. People ask what that number buys, what happens when something changes, and why anyone would take on the risk of a fixed price. This post answers all three, and gives you a way to read any fixed bid, ours or anyone else's, so you know what you are signing.
the short version
- A fixed price is only as good as the scope behind it. The scope document, not the number, is what you are really buying.
- Acceptance criteria turn a scope into something testable. Without them, done means whatever the builder says it means.
- Change is normal. What matters is that each change is priced and agreed before anyone works on it, never discovered on an invoice.
- Read the exclusions as carefully as the inclusions. Hosting, model usage, licenses, and data cleanup are common gaps.
01why fix the budget at all
Hourly billing on a project with unknowns puts all of the estimating risk on the client. The builder gets paid the same whether the estimate was good or bad, so there is no pressure to estimate well and little pressure to stop scope from drifting. A fixed budget flips that. If the builder underestimated the work they agreed to, that is their problem to absorb, which is exactly where the risk belongs, because they are the ones who know how long software takes.
The second reason is planning. A number you can take to the board, a lender, or an investor is worth something in itself. Nestwell came to us pre-product with a $30K budget: enough to build the right thing once, and no room to build the wrong thing first. Knowing the number up front shaped every decision about what to build first and what to defer.
02what is in the scope document
The scope document is the real product of the sales process. A good one includes:
- The problem and the outcome. One paragraph on what the software must return in hours, errors, revenue, or customer experience. This is the yardstick for every later decision.
- Users and roles. Who uses it, what each role can see and do.
- Features, in plain language. Each one described as behavior a person can observe: "a coordinator can approve or reject a drafted reply and the decision is logged," not "approval module."
- Integrations. Every system it reads from or writes to, with what data moves in which direction.
- Platforms. Web, iOS, Android, internal only, customer facing. Each one is real work.
- For AI features: the evaluation approach, the test set source, and the quality bar the system has to meet before it goes live.
- Milestones. What working software you will have at each two-week point.
- Assumptions. What the builder is assuming about your data, access, and availability of your people. Assumptions are where disputes are born, so they should be written down.
- Exclusions. What is not included. More on this below.
03acceptance criteria: how done gets defined
A feature without acceptance criteria is a feature that is done whenever the builder says so. Acceptance criteria are short, testable statements written before the work begins:
"Given a new intake form with a missing insurance ID, the system flags it for review within one minute and does not create a record."
"On the evaluation set of real past requests, drafted replies are rated acceptable by the operations lead at or above the agreed threshold before launch."
The second example matters for AI work. Because model output varies, the acceptance test for an AI feature is usually measured against a set of real examples rather than a single happy path. Agree on the set and the threshold during scoping, not after the demo.
04how change requests work
Change is not failure. You will learn things when you see working software, and some of them will change what you want. The question is how change is handled.
- You ask for something that is not in the scope.
- The builder writes it up: what it is, what it affects, what it costs, how it moves the timeline.
- You decide: approve it, drop it, or swap it for something of similar size already in scope.
- Only then does anyone work on it.
The rule that matters is the order. Change requests are priced before they are started, never after. If a builder starts work on a change and tells you the price later, your fixed budget has quietly become hourly.
Not every adjustment is a change request. Clarifying how an in-scope feature should look or behave is normal collaboration. A good scope document makes the line between clarification and new work easy to see.
05the two-week cadence
A fixed budget does not mean a black box until delivery day. Working software should land in your hands every two weeks, in an environment you can actually use. That cadence does three things:
- You see where the budget went, every two weeks, in software rather than status reports.
- Your operators catch misunderstandings while they are cheap to fix.
- Change requests surface early, when trading one feature for another is still easy.
06what is usually not included
A fixed bid covers the work in the scope. These are the items that commonly sit outside it, and that you should expect to see listed:
| Item | Why it is excluded | What to ask |
|---|---|---|
| Hosting and infrastructure | Billed by the cloud provider, varies with usage | Whose account, and what is the expected monthly range at our volume? |
| AI model usage | Billed per call by the model provider | What drives it, and how is it monitored? |
| Third-party licenses | Paid to other vendors | Which services, and are there alternatives? |
| App store and developer accounts | Owned by you, paid to Apple and Google | Who sets them up, in whose name? |
| Data cleanup | Size is unknown until the data is seen | Was the data reviewed during scoping? |
| Ongoing support | Continues after the agreed post-launch period | What is included after launch, and how is it priced later? |
07how to read a fixed bid
When a fixed bid lands on your desk, run through this list before you look at the number:
- Could you test every feature against its description? If not, the scope is too vague to fix a price against.
- Are there acceptance criteria, including a quality bar for any AI feature?
- Are integrations named specifically, with the direction data moves?
- Is there a milestone plan with working software at regular intervals?
- Is the change process written down, with pricing before work?
- Are assumptions and exclusions listed?
- Who owns the code and accounts?
- Did the builder ask you detailed questions before pricing? A fast number is a guess with a contract wrapped around it.
Then compare numbers. Two bids with very different prices often have very different scopes once you read them side by side.
08when fixed price is the wrong model
Fixed budgets work when the outcome can be described up front. They are a poor fit for open-ended research, for indefinite staff augmentation, or for a client who cannot commit people to answer questions during scoping. In those cases, a time-based arrangement with tight weekly reporting is more honest.
09how we do it
Every Insomnia Club engagement, whether custom software development, custom AI development, or mobile apps, is a scoped plan with a fixed number agreed before work starts. Change requests are priced before they are started, never after. Working software lands every two weeks, and the team stays after launch. The people who scope the work are the people who ship it, which is the only reason we can afford to fix the price.
If you would rather pay by the hour and manage the team yourself, we are not the right shop. If you want a number you can plan around, the next step is scoping, which I walk through in how to scope an AI project.
common questions
What is fixed price software development?
A model where the builder and the client agree on a written scope and a single price before work starts. The builder carries the risk of underestimating the work in that scope, and any change to the scope is priced separately and agreed before it begins.
Is fixed price more expensive than hourly?
The quoted number can look higher because the builder is pricing in the risk of the unknowns. The final cost is often lower, because hourly projects tend to grow without a clear point where anyone says no. The fair comparison is fixed price against what hourly projects actually end up costing.
What happens if requirements change on a fixed price project?
The change is written up, its impact on cost and timeline is estimated, and you decide whether to approve it before any work starts. You can also trade: drop something of similar size to keep the total the same.
What is usually not included in a fixed bid?
Commonly excluded items are hosting and infrastructure bills, AI model usage fees, third-party licenses, app store fees, cleanup of messy source data, and support after the agreed post-launch period. A good bid lists them explicitly.
How do I know a fixed bid is realistic?
Check that the scope is specific enough to test, that acceptance criteria exist, that working software is delivered on a regular cadence, and that the builder asked detailed questions before pricing. A quick number after one short call is a guess.