Fixed price vs time and materials: a buyer's guide to software projects
Two ways to pay for custom software, and the protections that matter more than the model: a written scope, milestone payments, ownership, and a plan for after launch.
Fixed price vs time and materials is the choice between paying an agreed total for an agreed result and paying for the hours a team spends. Most articles on the question are written by the people who send the invoice. This one is written for the person who pays it: what each model protects you from, what it leaves you exposed to, and what to check in a proposal before you sign.
The two fears behind the question
Buyers who ask about pricing models are rarely asking about accounting. They are asking about two things that went wrong before, for them or for someone they know.
The first is a price that moves. The proposal said one number, the project is half done, and the new estimate is double. You cannot stop, because half a system is worth nothing, and you cannot easily go on, because nobody can say where the number ends.
The second is a team that disappears. The developer stops answering, or the agency moves its people to a bigger account, and you find out that the code, the hosting and the logins are in their name. You paid for software you cannot touch.
A pricing model can help with the first fear. Only the contract and the way the work is set up help with the second. Keep both in mind as you read the rest.
Fixed price vs time and materials, side by side
A fixed price is one total for a written scope and a deadline, agreed before work starts. Time and materials means you pay for the hours worked, at an agreed hourly rate, plus any costs, for as long as the work takes. Neither model is honest or dishonest by itself. Each one puts the risk of a wrong estimate on a different side of the table.
| Question | Fixed price | Time and materials |
|---|---|---|
| Who carries the risk of a wrong estimate | The vendor | You |
| What you know before you start | The total and the deadline | The hourly rate, and an estimate that can change |
| What it needs to work | A written scope with acceptance criteria | Your time to steer and approve the work every week |
| How changes are handled | Quoted separately, with their own price and deadline | Added to the hours as they happen |
| How you pay | By milestone, tied to delivered work | Usually every month or every two weeks, for hours spent |
| Where it fails | A vague scope, which leads to arguments about what was included | A project with no end date, where the budget runs out before the result arrives |
| Best fit | A result you can describe: a portal, an integration, an internal tool, a first version | Open research, or a team that works with you every month without a fixed goal |
The honest reading: time and materials fits work you cannot describe yet. If nobody can say what "done" looks like, a fixed price is a guess with a contract around it. But most business software can be described. You know which forms, which reports and which systems have to talk to each other. For that kind of work, a fixed price moves the risk to the side that knows how long software takes to build.
What makes a fixed price real
A fixed price is only as firm as the scope behind it. A one-line proposal with a total at the bottom is not a fixed price. It is an opening bid. Four things turn it into a commitment.
- A written scope with acceptance criteria. Each part of the work says what it does and how you will check it. "A customer portal" is a wish. "Customers log in, see their open invoices and download a PDF of each one" is something you can accept or reject.
- Changes priced on their own. You will change your mind about something, and that is normal. A real fixed price handles it with a separate quote for the change, with its own price and deadline, which you approve before anyone works on it. The original price does not move.
- Payment by milestone. You pay in steps that follow delivered work, never far ahead of what you received. Smaller projects are often half to start and half on delivery. Larger ones split into three or four milestones.
- A deadline in the proposal. The date is part of the agreement, not a hope in an email.
This is how we work on custom software, at a fixed price. You tell us what you need, we answer within 24 hours with questions or with the scope confirmed, and you get a proposal with a fixed price and a deadline within 2 business days. You approve it, pay the first milestone, and we build it, with a written update every working day and no status meetings. The daily update matters as much as the price: you see a problem the day it appears, not at the end.
A fixed price does not have to be a slow one, either. In the Reevia HubSpot integration, more than 2 million records were brought together, and the integration was live in 4 weeks. That is the result of one project, not a promise for yours. Your deadline comes in your proposal.
Who owns the code
You should own the code, the data and every account as soon as you have paid for them, with nothing left in the vendor's name. Ownership is the protection against the second fear, and the pricing model does not decide it. A fixed-price project can leave you with nothing if the contract is silent, and an hourly one can leave you in full control if the contract is clear.
Two things decide it:
- What the contract says. Look for a clause that transfers the rights to the code and the work to your company once it is paid. Without one, the default rules depend on the country, and they do not always favor the buyer.
- Whose name everything is in. The code, the hosting, the domain and the logins should be registered in your company's name from the first day, not moved over at the end. A transfer at the end depends on goodwill at the moment the relationship is weakest.
With us, everything we create is set up in your company's name from day one, and once paid, 100% of it belongs to you. Every role on a project also has a named backup under contract, written into the agreement, so no project depends on one person.
This section is not legal advice. Ask a lawyer in your country to read the ownership clause before you sign.
What happens after launch
Software needs work after delivery too, and the proposal should say what happens then. A buyer who compares only the build price is comparing half of the cost and none of the risk.
Look for three things:
- A handover guide. A written document that explains how the system runs, how to update it and where everything is, so any team can take over. If the vendor disappears, this is what lets you carry on.
- A fix period. We fix anything that comes up for 30 days after delivery, at no charge.
- A clear maintenance option. Not a vague promise of support, but a plan with a named level and a response time.
Our maintenance plans have three levels, each priced per system in the proposal, and you can cancel any month:
- Essential: hosting and backups, monitoring and alerts, security updates every month, and bug fixes. Response within 2 business days.
- Growth: everything in Essential, plus a monthly block of hours for improvements (unused hours carry over while the plan is active) and a monthly report of what changed. Response within 1 business day.
- Partner: everything in Growth, a larger block of hours, a monthly roadmap review, and several systems under one plan. Response the same business day.
If someone else built your system, maintenance starts with a system assessment: a written report in business language on what is at risk, what is urgent and what can wait, with the options to keep, fix or rebuild. The report is yours, even if you never take a plan.
How a software price is built
A fixed price comes from the scope and the deadline. The scope is what the software must do, which systems it connects to, and how you will accept it. The deadline is when you need it, which decides how much of the work has to run at the same time. Maintenance is priced per system, by level.
That is why no honest vendor can quote a serious project from a two-line email. If you get a total before anyone has asked about your systems, your users and your deadline, the number came from a template, and the gaps in the template will come back later as change requests.
To get prices you can compare, send the same short brief to every vendor: what the software must do, who uses it, which tools it must connect to, and when you need it. Then compare the proposals on scope, milestones and ownership as well as on the total. If you want ours, tell us what you need. You get an answer within 24 hours, and a proposal within 2 business days of having the scope.
Red flags in a software proposal
Any one of these is a reason to ask questions before you sign. Two or more is a reason to keep looking.
- No acceptance criteria. The scope lists features but never says how you will check each one.
- Accounts in the vendor's name. The hosting, the code or the logins sit in the vendor's account, "to make it easier".
- Payment far ahead of the work. A large share is due before you have seen any working software.
- No backup. One person holds all the knowledge, and the proposal says nothing about who steps in.
- No process for changes. Nothing says how a change is priced, approved and scheduled.
- No word on ownership. The contract does not say who owns the code once you have paid.
- Nothing after delivery. No handover guide, no fix period, no maintenance option.
- Open-ended hours. Time and materials with no budget cap and no regular review of what the hours bought.
Frequently asked questions
Is a fixed price more expensive than time and materials?
The quoted total can be higher, because the vendor carries the risk of a wrong estimate and prices that risk in. With time and materials you carry the risk yourself, so the first number looks lower and the final number is unknown. Compare the fixed total with a realistic estimate of the hours, including the weeks that estimates usually leave out.
What if I change my mind in the middle of the project?
You can. The change gets its own quote, with its own price and deadline, and you approve it before work on it starts. The price of the original scope stays the same. If you decide the change is not worth it, the project continues as agreed.
Who keeps the code if I change vendors?
You do, if everything was registered in your company's name from the first day and the contract transfers the rights once you pay. A handover guide lets the new team start without guessing. Check both in the proposal, not at the end of the project.
Is there a guarantee?
The guarantees worth asking for are the ones in writing. Ours: the price does not move unless you approve new scope, you own everything once it is paid, every role has a named backup, you get a written update every working day while we build, and we fix anything that comes up for 30 days after delivery at no charge.
When is time and materials the better choice?
When the goal is still open: research, an experiment whose result decides the next step, or a team that works with you every month on whatever matters most at the time. In that case, set a monthly budget cap and review every week what the hours delivered.