A fixed price is only as fixed as the contract behind it. I have seen "fixed-price" agreements that were really an hourly deal with a hopeful estimate on top. The difference is in about ten clauses, and none of them need a lawyer to understand.
This is general information for business owners, not legal advice. Have a lawyer read anything you sign.
Key Takeaways
- The scope and the acceptance criteria are the heart of the contract. Everything else depends on them.
- Payment should follow accepted milestones, not the calendar.
- You should own the code, and the contract should say so in plain words.
- Look for a written change process, a warranty period, and a clean way out.
The Ten Clauses
1. Scope, as an attachment
A list of what will be built, in plain language, attached to the contract. Screens, kinds of users, integrations, and anything explicitly excluded. A two-page feature list is a scope. "Build a booking app" gives a builder nothing to price.
2. Acceptance criteria
For each feature, how you will both know it is done. "A customer can book a free slot; a taken slot cannot be booked twice." Without these, "done" is an argument.
3. Milestones and payment
The project broken into stages, each with a price. You pay when a milestone is accepted, not because a date passed. On our software factory projects, each milestone has its own invoice, and you only pay for work you have accepted.
4. Review window
How long you have to test each milestone before it counts as accepted. Ours is five business days. Too short and you cannot test properly. No window at all and the builder cannot plan.
5. Change process
How changes are requested, priced, and approved, in writing, before work starts. See what is a change order in software development.
6. Ownership of the work
Who owns the code, designs, and documents. You want full ownership transferred to you, with the builder keeping rights only to their general tools and know-how. In the US, code written by an outside contractor usually does not become yours unless there is a signed written assignment, so this clause matters. Our post on who owns the code a contractor writes explains why.
7. Where the code lives
The code should sit in a repository you own from day one, not handed over "at the end." Same for hosting, domains, and app store accounts.
8. Warranty
A period after launch during which bugs, meaning things that do not meet the acceptance criteria, are fixed at no charge. Ours is 90 days. It should say clearly that new features are not bugs.
9. Handover
What you receive at the end: the code, setup instructions, a list of accounts and passwords, and notes on anything unfinished. See the software project handover checklist.
10. Ending early
What happens if either side wants out halfway. Usually you pay for accepted milestones plus work in progress, and you receive everything built so far. Without this clause, stopping a project can mean losing the code you already paid for.
Red Flags
| What you see | Why it worries me |
|---|---|
| "Estimated" next to the total | It may not be fixed at all |
| Payments tied to dates only | You pay whether or not anything works |
| Large upfront payment, over a third | Little reason for the builder to finish well |
| Code in the builder's account until final payment | Your project can be held back in a dispute |
| No acceptance criteria | Every milestone becomes a negotiation |
| "Reasonable changes included" | Nobody agrees what reasonable means |
A Concrete Version
A contract for a $24,000 client portal, four milestones:
| Milestone | Deliverable | Price |
|---|---|---|
| 1 | Written plan, screen designs, accounts set up in the client's name | $3,000 |
| 2 | Clients log in and see their documents | $7,000 |
| 3 | Clients upload files and message the office | $8,000 |
| 4 | Launch, handover notes, final fixes | $6,000 |
Each milestone lists its acceptance criteria. The owner has five business days to test. A change process is attached. The code lives in the owner's repository from milestone 1. A 90-day warranty covers bugs against the criteria. If the owner stops after milestone 2, they have paid $10,000 and own a working login and document viewer.
That last line is what a good contract buys you: at any point, what you paid for is yours.
The Honest Counterpoint
Fixed price is not always the best deal. It works when you can describe what you want. If your idea is still changing weekly, a fixed-price contract will turn into a stream of change orders, and a time-based arrangement with a weekly cap may cost less and cause less friction. Builders also add a buffer for risk on fixed-price work, because they carry the risk of underestimating. Our post on hourly vs fixed price developer covers when each fits.
Frequently Asked Questions
Can I write this contract myself?
You can draft the scope and acceptance criteria yourself, and you should, because nobody knows your business better. Have a lawyer check the legal clauses, especially ownership and ending early.
What deposit is normal?
It varies. A first milestone that delivers the written plan and account setup is a fair way to start, because you get something real for the first payment. Our guide on how to pay for custom software in milestones has examples.
Should the contract name the developers?
It helps. Knowing who will actually do the work, and requiring your approval before they change, protects you from quiet swaps. See how to tell if a software agency subcontracts your project.
What does a warranty not cover?
New features, changes in what you want, and problems caused by someone else editing the code. Read what a software warranty should cover.
The Bottom Line
Scope, acceptance criteria, milestone payments, ownership, and a way out. Get those five right and "fixed price" means what it says. If you do not have a scope yet, the honest read ends with a short spec any developer can quote from.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and places pre-vetted senior LATAM engineers with US teams. Get a free honest read on your idea.
