How we work
Why we don’t bill by the hour
Fixed scope and fixed price instead of an hourly rate: why it works better for a first version, what happens when scope changes, and when hourly billing is actually the right choice.
In short
We price a build by its scope, not by our hours, because an hourly rate puts all the risk of a slow week on you. The scope is written down and the price fixed before work starts; if we estimated wrong, that is our problem. Scope changes are handled as a new, separate quote, so the original price and launch date hold. Hourly billing is still the better model for open-ended work with no clear finish line.
Key takeaways
- Fixed price moves the estimation risk to the people doing the estimating.
- It forces the hard conversation about scope to happen before the work, not during it.
- Changes don’t disappear — they become a new quote you agree to first.
- Hourly is right for open-ended, exploratory or ongoing work.
What does an hourly rate actually buy?
Time. It doesn’t buy a result, and it doesn’t tell you what the result will cost until the work is done. If the week goes badly — a library misbehaves, a design takes three attempts — you pay for every one of those hours. The person with the least control over the estimate carries all of its risk.
It also blurs the most important decision in a first version: what is in it. When the meter is running, “could you also add…” feels cheap. Ten of those later, the launch has slipped and the bill has doubled, and nobody made a single bad decision.
How does fixed-price work here?
- A free scoping call, where the product is cut down to what fits.
- A written scope — what’s in, what’s explicitly out — and one price for it, before you commit.
- The week itself, with a preview link and a written update every evening.
- Launch, and a handover. The price you agreed is the price you pay.
If the work takes us longer than we estimated, that’s ours to absorb: we did the estimating. It’s also why we’re careful on the call — a fixed price only works if the scope is honest. See the ways to work together and the published prices.
What happens when the scope changes?
Small adjustments inside the agreed scope are part of the work — a label, a layout, the order of a form. Anything new goes on a written list. When the week ends, that list becomes the scope of the next week, with its own quote you agree to first. The original launch date and price don’t move.
The rule that makes this work: after Day 1, when the data model and screens are signed off, new ideas are welcome — they just belong to the next week.
When is hourly billing the better choice?
When there is no clear finish line. Open-ended research, long-running maintenance with unpredictable requests, or embedded work alongside your team are all better paid for by time, because nobody can write down the scope in advance. For ongoing care after launch we use a fixed monthly plan with a set number of hours, which is the same idea in a predictable shape.
What should you ask any studio before you hire them?
- What exactly is out of scope, in writing?
- What happens — and who pays — if it takes longer than you think?
- How do changes get priced, and when do I agree to them?
- Who owns the code and the accounts from day one?