Which engagement model is cheapest?

Fixed scope, if the scope turns out to be right. It stops being cheapest the moment requirements move, because each change is priced separately. For work with genuine uncertainty a retainer usually costs less in total, even though the monthly number looks larger.

Can we change model partway through?

Yes, and it's common. Plenty of engagements start fixed-scope for a first phase — enough to prove the thing works — then move to a retainer once there's a roadmap worth pursuing. Changing direction mid-project is a conversation, not a penalty.

How do you decide whether to take a revenue share?

We look at whether we can actually influence the outcome. If success depends on a sales team we're not part of, or a market that won't exist for three years, a revenue share is us gambling on something we don't control. We say no to most of them, which is the honest answer.

What happens if we run out of budget mid-build?

You keep everything built so far, in a state you can hand to someone else — that's what the documentation and test coverage are for. We'd rather stop cleanly at a working milestone than leave you with a half-finished system nobody else can pick up.

01Engagement models

Three ways to work with us, and when each one is wrong

Most agencies offer one model and present it as the natural way to work. We offer three, because the right one depends on how much of your problem is already understood — and each of them fails in a specific way.

Fixed scope

One deliverable, one price, agreed before anything starts.

Suits: A defined piece of work you can describe in a paragraph — an integration, a migration, a prototype to test one question.
Fails when: Anything where the requirements will move. Every change becomes a negotiation, which is slow for you and defensive for us.

You carry: The risk that the scope was wrong
We carry: The risk that it takes longer than estimated

Monthly retainer

A recurring fee for the build and the team behind it.

Suits: A product being discovered as it's built, which is most first products. Priorities can change every fortnight without a contract conversation.
Fails when: A team that can't decide what it wants. Without a clear goal a retainer bills months while the product goes sideways.

You carry: The risk that progress is slower than hoped
We carry: The risk of being replaced if it is

Revenue share

A slice of what the product earns, paid only once it earns.

Suits: Founders with a strong distribution advantage and limited cash, on a product with a clear path to revenue we can both see.
Fails when: Long-horizon products, anything with a complex cap table, or work where we can't influence whether it sells. We decline more of these than we accept.

You carry: Giving up upside if it works
We carry: Being paid nothing if it doesn't

The short version

If you can write the scope down and be confident it won't change, fix it. If you can't — and for a first product you usually can't — take the retainer and keep the flexibility. Revenue share is the exception rather than the default: it suits a narrow set of situations, and we turn down most of the ones we're offered.

The model matters less than whether the incentives point the same way. All three of ours are built so that we're worse off if the product doesn't ship.

Questions we get asked

Fixed scope, if the scope turns out to be right. It stops being cheapest the moment requirements move, because each change is priced separately. For work with genuine uncertainty a retainer usually costs less in total, even though the monthly number looks larger.
Yes, and it's common. Plenty of engagements start fixed-scope for a first phase — enough to prove the thing works — then move to a retainer once there's a roadmap worth pursuing. Changing direction mid-project is a conversation, not a penalty.
We look at whether we can actually influence the outcome. If success depends on a sales team we're not part of, or a market that won't exist for three years, a revenue share is us gambling on something we don't control. We say no to most of them, which is the honest answer.
You keep everything built so far, in a state you can hand to someone else — that's what the documentation and test coverage are for. We'd rather stop cleanly at a working milestone than leave you with a half-finished system nobody else can pick up.

Tell us what you're building and we'll say which of these fits — including if the answer is none of them.

Start a project