Most advice tells startups to avoid fixed-price contracts because you cannot pivot. Two thirds of that advice is right. Vendors do pad fixed-price quotes by 20-50%, and milestone plans do slow you down. But the pivot problem is not caused by the price structure. It is caused by who holds the source code when the project ends. Here is how to tell the difference before you sign.
The case against fixed price, in the industry’s own words
Search for “fixed price vs time and materials” and you will find eight near-identical articles, all written by software agencies, all reaching the same conclusion: time and materials is better for startups.
They are not hiding an agenda. Several of them sell fixed-price work. They land on the same answer because they are describing the same thing, and their criticism of it is accurate.
Here is what they say. Orangesoft, on flexibility: “Any changes to the scope are handled via a change request and priced separately.” Saigon Technology, on cost: “Vendors often add buffers (20-50%) to cover their risk, so you will pay more.” Saigon again on quality, and this is the sharpest thing anyone on that page says: fixed-price vendors “protect their margin by cutting corners: less testing, skipping refactoring, and assigning junior developers.”
Strip those down and you get three charges: fixed price costs more, it locks your timeline, and it stops you changing direction. There is a fourth charge about quality, serious enough that it gets its own section further down. This post takes the three in order.
One thing you should know before reading our answer to any of them: we sell fixed-price builds. That is our business model. Read the concessions below as the parts that cost us something to write.
And then the sentence the third charge rests on, from Fabrity:
“If you do realize you need more functionalities or changes after the entire project is done, the cost of improving the final product can be prohibitive.”
Read that again, because it is doing two things at once. The experience it describes is real, and most founders who have been through it will recognize the feeling. The explanation it offers is wrong. That cost has almost nothing to do with the words “fixed price.”
Two definitions, since the terms get used loosely. A fixed-price engagement sets one agreed price for one agreed scope before work starts, and the vendor absorbs the overrun if the estimate was wrong. A time and materials engagement bills for hours worked at an agreed rate, so the scope can move and the total is unknown until the work stops. Everything else people argue about follows from those two sentences.
Two of the three complaints are true
Let’s get the concessions out of the way, because you will hear these from anyone you ask and you should hear them from us first.
The buffer is real. A vendor quoting a fixed price absorbs the cost of their own bad estimate. They protect themselves by padding, usually 20-50%. If the work would have taken 400 hours, you are paying for something between 480 and 600. That is the honest cost of moving risk off your balance sheet and onto theirs, and anyone who tells you fixed price is cheaper per hour is selling you something. If what you want is the underlying price levels rather than the contract structure, we broke down what separates a $5K build from a $50K one separately.
Whether that trade is worth it depends on one question: can you survive being wrong about the total? A funded company with a finance team can absorb an overrun on an hourly engagement and treat it as a variance. A bootstrapped startup with nine months of runway cannot. At that stage, budget certainty is what keeps the company alive while you find out whether the product works.
The milestone rigidity is real too. A fixed price requires a defined scope, and a defined scope means somebody wrote down what version one does before anyone started building. That front-loads planning. It also means that halfway through, when you have a better idea, the answer is often “that’s version two.”
We are not going to pretend this is secretly a feature. It’s a constraint. What we will say is that the constraint is bounded: it applies to the weeks you are inside the build, and it ends the day the project ships. Which brings us to the part the industry gets wrong.
The third complaint is about code ownership, not pricing
“The cost of improving the final product can be prohibitive.”
That is only true if you do not have the code.
Think about what has to be true for a small change to be expensive after a project ends. Somebody has to be the only party who can make it. They have the repository. They have the deployment credentials. They know how it fits together and nobody else does. When you ask for a change, you are asking the only available supplier what they would like to charge, and then deciding whether to pay it.
None of that comes from the words “fixed price” in a contract. All of it comes from where the code lives.
Here’s the part that catches most non-technical founders off guard: code written by a contractor belongs to the contractor by default. Not to you, and not because anyone is being dishonest. Code written by your own employees belongs to your company automatically. Contractor code does not, unless the contract explicitly assigns it, usually through a work-made-for-hire clause or an IP assignment. If the agreement you signed is silent on the point, the answer is usually that you paid for a license to use something somebody else owns.
This is not a secret, and we are not claiming to have discovered it. Plenty of people have written the “make sure you own your code” article, and they’re right. What is missing is the connection to the pricing conversation. We read the four highest-ranking comparisons of fixed price against time and materials in full. All four discuss scope, buffers, change requests, and milestones. None of them mentions who is holding the repository when the invoice is paid.
That’s the wrong axis. Code ownership is the axis that decides it. You can sign either contract and end up locked in, or sign either contract and end up free.
What happens when you want to change something
The cost of changing direction after delivery depends on three things, and the pricing model isn’t one of them.
Who has the repository. If the code lives in a GitHub organization the vendor owns, you have a negotiation. If it lives in an account with your name on it and you granted the vendor access to work, you have a codebase.
Whether anyone else can read it. A documented codebase with a README, environment setup instructions, and a deployment guide can be picked up by a new team in 2-4 weeks. The same codebase with no documentation, or with an outgoing vendor who is slow to answer questions, takes 6-12 weeks, because the new team has to reconstruct knowledge that should have been written down. That gap is the real switching cost, and it is invisible until the day you need it.
Where it’s deployed. If the product runs on the vendor’s AWS account, moving it means a migration project. If it was deployed to your account on day one, moving means changing who has access.
Here is the same situation played out two ways. The founders below are composites, not clients, but the mechanics are ordinary. Two of them launch on the same week, both on a fixed price, and six weeks later both need the same change: swap the payment provider, because the original one will not support the market they are actually selling into. The first founder emails her vendor and waits four days for a number. It comes back at roughly a fifth of the original build cost, because it is a change request and there is nobody else she can ask. The second founder posts the job, gets three quotes from contract developers who cloned the repository and read the code that afternoon, and picks one by Friday. Same change, same product, same contract structure. The only difference is whose account the repository was sitting in.
Get those three right and a pivot costs whatever a developer costs. Get them wrong and it costs whatever the vendor decides, because you are not really buying a change, you’re buying your way out.
What you actually receive at the end
Ask a shop what you get on the last day. The answer tells you more than the quote does.
Most proposals describe the work: discovery, design, sprints, QA, launch. Very few describe the artifact. Here is what a complete handoff looks like, and you should feel free to take this list to anyone you are talking to and ask them to confirm each line in writing.
- The source code, in a repository owned by your account, with full history. Not a zip file emailed on the final day.
- A written assignment of the intellectual property to you or your company, effective on final payment.
- The running product deployed to infrastructure you control, under your billing, with you as the account owner.
- Every credential and account, transferred to you: hosting, database, domain, payment processor, email, error monitoring, and any third-party API keys.
- Setup documentation good enough for a developer who has never seen the project to run it locally and deploy a change.
- The environment configuration, so a new developer can reproduce the production setup without guessing.
A vendor who intends to keep your business through dependency cannot honestly commit to that list. That is what makes it a useful question. You are asking them to describe their own business model, and the hesitation tells you as much as the answer.
This is how we work at Asyncdot, and it is written into how we scope and ship every project. You get a finished, production-grade product at a fixed price, the full source code, deployed to your own account, yours to keep. If you decided tomorrow to take it to a different team, the only thing you would lose is us.
What a change costs after the project ends
This is the comparison that matters, and it’s the one the standard articles don’t run. Notice that the pricing model appears nowhere in it.
| Vendor keeps the code | You own the code | |
|---|---|---|
| Who holds the repository | The vendor’s account | Your account |
| Where it runs | Vendor infrastructure | Your account, your billing |
| Who owns the IP | The vendor, unless assigned | You, on final payment |
| A small change costs | A change request at the vendor’s price | Market rate, from anyone |
| Another developer can start | Only if the vendor cooperates | Same day |
| A new team is productive in | 6-12 weeks if the handover is contested | 2-4 weeks with documentation |
| If the vendor goes quiet | You have a serious problem | You have an inconvenience |
Both columns can be a fixed price. Both can be time and materials. The contract structure does not decide which column you land in, and that is the whole point.
Does a fixed price mean you get a worse product?
Sometimes, yes. This is the strongest argument against fixed-price work and it deserves a straight answer rather than a rebuttal.
The accusation is that a vendor who has already agreed a price has one lever left when the estimate slips: spend less. Fewer tests. Skip the refactor. Put a junior on it and hope. That is a real incentive and it produces real damage, and if you have inherited a codebase from a cheap fixed-price build you have seen what it looks like.
Two things make the incentive go away, and you can check both before you sign.
The first is whether the vendor expects to still be around. A shop that hands you the code and disappears can afford to cut corners, because the consequences land on you. A shop that expects to work with you again, or that publishes case studies with named clients, is spending its reputation on the quality of what it hands over.
The second is the estimate itself. Corner-cutting starts when a vendor bids low to win the work and then discovers the price does not cover the job, so the fix sits upstream: a scope specific enough that both sides know what “done” means, and a price that reflects it. A quote that comes back dramatically under everyone else’s should be read as a prediction about what will get dropped later.
The reason we can quote a fixed price without padding it into absurdity is that our engineers work with a toolchain that removes most of the estimation risk. The predictable parts of a build, the CRUD, the form validation, the API routes, the component scaffolding, come back as drafts fast enough that the uncertainty sits in a much smaller part of the project. Engineers still make every architectural, security, and payments decision, and still review everything that ships. Compressing the predictable work is what makes a fixed price honest instead of defensive.
When fixed price is the wrong choice for you
We would rather you not hire us than hire us for the wrong shape of work. Three cases where a fixed price genuinely does not fit:
You do not know what you are building yet. If you cannot describe what version one does, no honest vendor can price it. What you need first is a discovery engagement or a cheap prototype to find the shape of the thing. Pricing a build you cannot specify produces either a padded quote or an argument in week three.
You need an open-ended research phase. Some products, particularly ones with a genuine machine learning problem at the center, involve work where nobody knows how long it takes because nobody knows whether it works. That is research. Research is time and materials, and a vendor who quotes a fixed price for it is either misunderstanding the problem or planning to stop early.
You want a team embedded for the long haul. If your plan is a standing engineering function for the next two years, what you need is ongoing capacity. That is a different engagement entirely, and pricing it as a one-off deliverable would serve neither of us.
Notice that none of these is “because you might change your mind.” Changing your mind is normal, and it is handled by owning the code, not by paying hourly for the privilege.
How to compare two quotes
Four questions. They take about five minutes and they will tell you more than a rate card.
- Whose account holds the repository during the build, and whose holds it after?
- What exactly transfers on final payment? Ask for the list, in writing.
- Where does the product run, and whose credit card is on the hosting?
- If we part ways after launch, what does the next developer need from you, and how long does it take?
A shop that answers all four crisply has thought about your position after the engagement ends. A shop that gets vague on question two or four has told you something important.
If you are still deciding whether an outside team is the right move at all, we wrote separately about why the technical cofounder search is usually the wrong first step, and about what an MVP actually costs at each budget tier, which is the other half of this question.
The short version
For a startup, fixed price versus time and materials is a real decision and it turns on one thing: whether you can survive being wrong about the total. If you cannot, buy certainty and accept the buffer.
But it’s the smaller of the two decisions you are making. The larger one is code ownership: whether the code ends up in your account or someone else’s, which is what sets the cost of changing direction six months from now. You can settle that one in a single email before you sign anything, and most founders never think to send it.