Insights · Working together · 22 July 2026
Fixed scope or hourly: how to buy a build
Most build relationships go wrong at the buying stage, not the building stage. The pricing model you choose decides whose side the incentives are on.
Two contracts are sitting in your inbox. Both are for the same build. One says the studio will work for a fixed price of a fixed scope, delivered by a fixed date. The other says the studio bills a day rate and will invoice you monthly for time spent.
Most people compare the totals. The totals are the least important difference between those two documents. What you are actually choosing is whose side the incentives sit on for the next three months, and that choice decides more project outcomes than any technology decision you will make.
The problem with the hour
Hourly billing feels safe because you only pay for what happens. In practice it means nobody on the selling side is paid to finish. Estimates drift, meetings multiply, and the client becomes the only person in the room with a reason to want the project done.
Watch where the pressure flows on an hourly project. Every ambiguity resolves toward more work: another meeting to align, another revision round, another week of polish. None of it is malicious. It is just what a system does when finishing pays worse than continuing.
Hourly has honest uses, and it is worth naming them: genuine research where the destination is unknown, open ended maintenance, an extra pair of hands inside your own team where you direct the work daily. In each of those, time really is the product. But for building a defined thing, paying for time is a way of postponing the decision about scope, and postponed scope decisions are the most expensive kind.
The three shapes that work
The fixed scope build. A defined product, a fixed quote, a deadline, and working software shown every week. This is the default for a reason: it forces the scope conversation to happen at the start, where it costs a conversation, instead of at the end, where it costs a lawsuit. It also makes the studio carry its own estimating risk. If the work takes longer than quoted, that is the studio's problem, which is exactly the pressure that produces honest estimates.
The embedded team. A standing design and engineering squad inside your company, quarter by quarter, working in your tools on your roadmap. You are not buying a deliverable, you are renting capability, and it is priced accordingly. This suits products already in motion, where the work is a stream rather than a thing.
The advisory sprint. One to two weeks, a fixed small price, an expert review of your product or codebase or AI plans, and a written recommendation you keep either way. It exists for the moment before a big decision, so you can spend a little to avoid spending a lot in the wrong direction.
How to choose in one minute
If you can name the thing you want built, buy a fixed scope build. If the work is a stream with no finish line, embed a team. If you cannot yet name the thing, buy the sprint, and let the naming be the deliverable.
There is a corollary worth taking seriously: a studio that refuses to put a fixed number on a defined scope is telling you something about its own estimating. Treat that refusal as data.
The two clauses that are never optional
Whatever shape you choose, two lines belong in the contract, and both should cost a good studio nothing to accept.
First: changes are priced and agreed in writing before they are built. Scope always changes, and this clause is what keeps change from becoming resentment on either side of the table.
Second: everything produced belongs to you from day one. Code, designs, accounts, all of it. Ownership that arrives only at final payment is a lock dressed as a milestone.
We have signed both clauses on every project we have run, and we have never once regretted it. The studios that bristle at them are answering a question you did not ask out loud, which is the most useful kind of answer there is.