Most first-time buyers of custom software get pitched two commercial models. One is time-and-materials — pay the team's hourly or daily rate for as long as the work takes. The other is fixed price — agree the scope, agree the number, sign, and start. The internet is full of arguments in both directions, mostly written by studios trying to sell whichever one suits them.
This post is the version we tell our own clients. We work fixed price for first builds and switch to a retainer once a product is live. Time-and-materials sits in a narrower band than the industry pretends, and almost never serves a first-time buyer well. The argument matters because the commercial model decides whose interests are aligned, and that decides whether the project ships.
What fixed price actually means when we use the term
Fixed price is not a fixed budget for an undefined project. That is the version of fixed price that has given the model a bad reputation, and it deserves it — pricing an unbounded scope is just guessing, and somebody loses the bet.
A real fixed-price engagement is built on three things in writing. A scope document that describes the outcomes the software has to deliver — specific, testable, with an explicit out-of-scope list. A timeline broken into milestones that are tied to delivery rather than dates. And a change-request mechanism that says, in plain language, what happens when the buyer wants something the scope did not cover. Without all three, "fixed price" is just a number with no defence, and it falls apart at the first surprise.
When a studio agrees to a fixed price properly, they are agreeing to absorb the risk of estimating wrong on the work that is in scope. That is what the buyer is paying for — not a discount on the hours, but the transfer of execution risk from buyer to studio. The number on the contract usually contains a contingency between 10 and 25 percent for things the studio could not foresee but is now responsible for. That is correct. A fixed-price quote without a contingency is a quote that is going to break or be renegotiated.
Why time-and-materials quietly punishes first-time buyers
The argument for time-and-materials is that the buyer only pays for what they consume, and the model flexes with changing requirements. Both are technically true. Both miss what actually happens in practice.
Time-and-materials moves all the planning risk onto the buyer. The studio's incentive is to bill hours; the buyer's is to ship. Those are not the same incentive, and the imbalance shows up in three predictable ways.
First, T&M projects almost always run longer than the buyer expected. The early estimates are framed as "ranges" and "directional", and the studio is usually careful not to commit to a finish line. Three-month scopes routinely become five-month scopes, and the buyer signs off because each individual two-week sprint feels reasonable. The cumulative bill, six months in, is well past whatever fixed-price quote made them flinch in week one.
Second, scope discipline gets outsourced to the buyer, who is usually buying custom software for the first time and is not equipped to push back on engineering decisions. The studio is paid to build whatever is asked for. If the founder asks on a Tuesday standup whether they could "also have an audit log", the answer is yes, and an audit log gets built — at full T&M rates, on the path of the next milestone, with no one telling the buyer that this is the third feature this week that has cost them a fortnight.
Third, the relationship gets adversarial at exactly the wrong moments. When something breaks, the question of whether the fix is billable becomes a negotiation. When a feature doesn't behave the way the buyer expected, the question of whether the original spec covered it becomes a negotiation. T&M turns every ambiguity into a billing conversation, and the buyer almost always loses these conversations because they don't have the context the studio has.
The honest summary is that T&M is the right model for a buyer who has a strong internal product manager driving scope and treating the studio as extra capacity. It is the wrong model for someone hiring a partner to take a definable problem and ship a working product. That is most of the market.
The buyer's case for fixed scope, fixed price
The case for fixed price is not that it is cheaper. Sometimes it is, sometimes it isn't. The case is that it gives the buyer four things that T&M does not.
A budget they can take to their CFO or partners. The number on the contract is the number that hits the bank. There is a 10–25 percent change-request envelope on top of that, sized in writing, and beyond it everything is repriced — but the base number is real, not aspirational.
A delivery date that is somebody's job to hit. The studio is on the hook to ship the agreed scope by the agreed milestones. Slippage costs the studio, not the buyer. That single fact rearranges the whole engagement — it makes the studio careful about scope, careful about complexity, and honest about what a feature is going to take.
A scope conversation up front, when it is cheap. Fixed price forces the spec to be clear before anyone starts building. T&M lets that conversation drift into the build phase, where every clarification is paid for at engineering rates. Spending two weeks on scoping before the contract is the cheapest engineering work you will ever buy.
A change-request mechanism that surfaces decisions instead of hiding them. Every meaningful change in a fixed-price project triggers a small written exchange — here is the change, here is the price, here is the impact on the timeline. The buyer learns to think about scope as a budgeted resource, which is a skill that will serve them for the rest of the product's life. T&M actively prevents this skill from forming.
Where fixed price genuinely does not work
This is the half of the argument most studios skip, and it is the half that makes the rest of the argument believable.
Fixed price is a bad fit for genuinely exploratory work. If the goal is to learn what to build — a research spike, a hardware prototype, a feasibility study, a design discovery — fixing a price and a scope is pretending to know things you don't. We do this kind of work on a small fixed-fee discovery basis (a defined number of weeks for a defined deliverable, not a defined feature set), or on T&M for a strict capped duration.
It is also a bad fit for the second year of a product. Once a product is live, the work shifts from build to operate-and-extend — bug fixes, small features, performance work, customer-driven additions. The right model for that work is a monthly retainer sized to the team you actually need. Trying to fix-price every small change after launch creates more contract overhead than the work itself is worth.
And it is a bad fit for projects where the buyer genuinely cannot make decisions and stick to them. Fixed price assumes that the buyer can hold a scope steady for the duration of a phase. If the buyer is going to change their mind every two weeks because they're still figuring out what they want, fixed price will end with a heavy change-request log and a frustrated client. Those clients are better served by T&M, or — more often — by a longer discovery phase before any build is contracted.
How a fixed-price scope is actually built
The scope-of-work document is where most fixed-price engagements live or die. A good one has six things, in plain language.
A summary of the problem and the user. One paragraph each, written in business terms, not technical ones. If we cannot describe who the user is and what they do today, we are not ready to price anything.
A list of capabilities — the things the software will let people do. Each capability is one or two sentences and reads like a user-facing outcome. "A clinic receptionist can book a follow-up appointment for an existing patient and confirm it on WhatsApp." Not "build a calendar component."
An explicit out-of-scope list. The things we have discussed and deliberately decided are not in this version. This is the most useful section of the document. It prevents the slow accumulation of "I thought that was included" arguments in month four.
The integrations. Which third-party systems the software talks to, what flows through each connection, and who is responsible for the credentials and accounts on the buyer's side. A surprising number of projects slip because a payment gateway account is two weeks late.
The non-functional requirements. Roughly: how fast it should feel, where it should be hosted, who should be able to log in, what compliance the buyer cares about, what data lives where. Light but specific.
The milestones, each one tied to something delivered (a working prototype, a staging build, a production launch) rather than to a date on a calendar. Dates appear, but as targets attached to deliveries rather than the other way around.
A scope this shape takes us between five and ten working days to write properly with the client, in a discovery sprint before the build contract is signed. We charge a small fixed fee for that period regardless of whether the build goes ahead. The buyer ends up with a usable specification document either way, which they can take to other studios if they choose. We have lost a couple of clients that way, and that is fine — the alternative is pricing a project we don't understand, which is worse for everyone.
A worked example
A two-clinic owner in Bengaluru asked us to replace the appointment-and-billing workflow that was being run on a mix of EClinic and a Google Sheet. The capabilities ended up being: receptionist appointment booking with WhatsApp confirmation, doctor-side patient note capture, billing with GST-compliant invoices, end-of-day reconciliation, and a small owner cockpit showing OPD volumes and outstanding payments by branch.
The out-of-scope list was longer than the in-scope list — no patient app, no third branch, no insurance claim flow, no inventory module beyond consumables — and that list is what kept the project shippable.
Fixed price came out at INR 16.4L for a 12-week build, milestoned across four payments of roughly equal size. A 15 percent change-request envelope sat on top of the base price. The post-launch retainer was scoped at INR 45,000 a month for nine months, covering bug fixes, small feature additions, and the gradual addition of the third branch. The total first-year spend was INR 21.45L plus change-requests, against a T&M proposal from another studio that quoted "INR 9–12L for 8–12 weeks" but had no scope document and no out-of-scope list.
Twelve months on, the change-request log shows seven approved CRs totalling INR 2.1L — well inside the envelope — and zero billing disputes. That is the outcome we are optimising the commercial model for. Not the lowest possible quote, but the smallest gap between the number we said and the number that actually got paid.
When to switch out of fixed price
The signal that an engagement should leave fixed price and move to a retainer or capped T&M is when the buyer's questions stop being "is the build done?" and start being "what should we build next?". That is a different kind of work, and pretending it is the same kind only because the same team is doing it leads to bad incentives on both sides.
When that switch happens — usually two to three months after launch — the right shape is a monthly retainer sized to the team the product actually needs, with clear monthly deliverables and a quarterly review. For deeper engineering work that comes up later (a new module, an automation layer that connects to a new ERP), we go back to fixed price for that specific phase. The retainer keeps the lights on and the relationship warm; phases handle the chunks of new build.
Fixed price is not a religion. It is the right starting model for almost every first build, and the right return model for every well-defined later phase. The other models exist for the cases that don't fit those shapes — but those cases are narrower than the industry sells. For a buyer trying to pick a model for their first custom-software engagement, the answer is almost always: fixed scope, fixed price, with a written change mechanism and a retainer waiting on the other side of launch. The Project Management Institute's standard on contract families says roughly the same thing in more formal language.
If you want to talk through what a fixed-price scope would look like for the project on your desk — including the discovery shape, the milestone breakdown, and the realistic price band — tell us about it here. We will tell you honestly whether fixed price is the right model for the work, and what we would change about the scope before quoting it.