You are about to commission a website, an app or an MVP, and two kinds of proposals land in your inbox. One says “€12,000, delivered in 8 weeks”. The other says “€65/hour, estimated between 150 and 250 hours”. On paper they can cost the same. In practice they are two different contracts, with different incentives — and picking the wrong one is the most common way a software project ends in frustration.
We work with fixed prices and say so on our homepage. But this article is not about that: it is about you understanding what you are signing in each case, because there are projects where time and materials is the honest option.
What each model is, plainly
Fixed price: you agree on a concrete scope and a fixed amount. If the vendor takes longer than expected, the overrun is theirs. Execution risk sits with whoever executes.
Time and materials (an hourly bucket): you pay for time worked, usually against a rough estimate. If the project drags on, the overrun is yours. Execution risk sits with you.
Neither one is “the good one”. The right question is: who is in a better position to control the risk of this particular project?
What time and materials doesn’t tell you
The sales pitch for hourly work is flexibility: “you can change your mind along the way”. True. What gets said more quietly:
- The estimate is not a commitment. “Between 150 and 250 hours” means 250 isn’t a ceiling either. When the hours run out, the conversation is not “you missed the target” but “shall we top up the bucket?”. And mid-project, with half-built software, your negotiating position is minimal.
- The economic incentive points against you. No bad faith required: nobody who bills by the hour is structurally in a hurry to finish. Efficiency depends on the vendor’s ethics, not on the contract.
- You control the budget… in theory. In practice, deciding what gets cut requires technical judgement. If you knew how to weigh technical debt against features, you probably wouldn’t be hiring outside help.
What a fixed price demands from you
Fixed pricing isn’t magic either. It only works under two conditions, and both depend on you too:
- A genuinely defined scope. “A corporate website of around 6 pages with a contact form” can be priced. “A platform we’ll figure out as we go” cannot. If a vendor quotes a fixed price against a fuzzy scope, be suspicious: either the price is padded to cover them, or you will fight over every change.
- Discipline with changes. Anything that appears after the agreement gets quoted separately. That is not rigidity: it is what makes the initial price mean anything. A serious vendor will tell you no mid-project, and that is a good sign, not a bad one.
In exchange, you get what an SMB needs most when commissioning software: a figure you can put in your cash-flow plan and a vendor with a real incentive to finish.
When each model makes sense
| Situation | Reasonable model |
|---|---|
| Corporate website, e-commerce, MVP with definable scope | Fixed price |
| New product with scope that can be boxed into phases | Fixed price per phase |
| Ongoing evolution of a live product | Hourly bucket or monthly retainer |
| Rescuing someone else’s undocumented project | Hours for the diagnosis, fixed price after |
| Pure research, with no definable deliverable | Hours, with frequent check-ins |
The pattern: when the scope can be defined, a fixed price protects you. When it genuinely cannot — maintenance, exploration, inherited code nobody understands — forcing a fixed price only inflates it with a risk cushion. That is why a well-framed MVP gets a fixed price (the 6-week scope is defined in week one), while its later evolution is usually agreed differently.
Five questions before you sign
- What exactly happens if the project runs long? The answer tells you who carries the risk, whatever the model is called.
- What does the price include and, above all, what doesn’t it? Hosting, domains, licences, post-delivery support, bug fixes. The unpleasant surprises live in the “not included”.
- How are scope changes handled? If the answer is “we’re flexible”, push until you get a concrete mechanism.
- Who owns the code, and from when? Repository in your name from day one. No exceptions, under any model.
- How often do I see working software? A regular demo of real software — not screenshots, not slides — is your best insurance under both models.
Our position, in short
We publish “from” prices per service and close the final figure before starting, with the scope in writing. Not because hourly billing is a scam — it isn’t — but because for most SMB projects the scope can be defined, and then a fixed price is the fairest risk split: you own the what, we answer for the how much and the when.
If you have a project and don’t even know where to start scoping it, tell us about it. We’ll tell you what can be fixed-priced, what can’t, and why — including when the honest answer is that you don’t need to hire anyone yet.