Four ways to work together, with the catch on each
Every commercial model has a downside. A page that lists four options and only describes their benefits has not helped you choose — it has just moved the discovery of the trade-off to month three.
Discuss which fits- Model 01
Fixed scope, fixed price
A defined outcome for a defined number.
Best for
Work whose shape is genuinely known — usually after a discovery has already been done.
How it works
- Scope, acceptance criteria and price agreed in writing before work starts
- Payment against milestones, each tied to something you can actually use
- Change requests costed and approved separately rather than absorbed silently
- We carry the risk of estimating badly, which is why the estimate follows discovery
The trade-off
Fixed price makes change expensive, because every change has to be re-negotiated. If your requirements are genuinely still moving, this model turns that movement into contractual friction and both sides end up managing the contract instead of the product.
Good fit
- A well-understood build following a completed discovery
- A defined integration or migration with a clear finish line
- Procurement processes that require a fixed number to approve
Bad fit
- Anything still being figured out
- Long programmes where priorities will legitimately shift
- Work where you want to change direction based on what you learn
- Model 02
Time and materials
Pay for the work as it happens, change direction when you learn something.
Best for
Products still being shaped, where the ability to change your mind is worth more than a fixed number.
How it works
- Billed monthly against time actually worked, with a written summary of what it went on
- An agreed ceiling per month, so the exposure is bounded even though the scope is not
- Priorities set by you at each two-week boundary
- Stop at any month boundary with one month’s notice
The trade-off
You carry the estimating risk rather than us, and it requires trust in both directions. We mitigate it with a monthly ceiling and a written record of where time went, but if you need a guaranteed total number before you can start, this is not the model.
Good fit
- New products where discovery continues into the build
- Ongoing development against a roadmap that will evolve
- Work where you want the option to redirect after each slice
Bad fit
- Procurement that requires a fixed total before approval
- Situations where nobody on your side has time to set priorities
- Model 03
Dedicated team
Named engineers, allocated to you, directed by you.
Best for
Teams that know where they are going and need capacity rather than direction.
How it works
- Named engineers with real CVs, interviewed by your team before starting
- Monthly rate per engineer, one month’s notice either way
- They work in your repository, your tracker and your review process
- Our senior engineers available for technical escalation at no extra charge
The trade-off
You are buying capacity, not accountability for the outcome. An augmented engineer optimises for the ticket in front of them — if the tickets are wrong, they will be implemented efficiently and wrongly, and nobody is structurally responsible for noticing. This model needs someone on your side doing that thinking.
Good fit
- An existing team with a backlog and a technical direction
- A capability needed for six months but not permanently
- Scaling up faster than hiring allows, reversibly
Bad fit
- Nobody on your side with time to set priorities or review code
- An expectation that we will own the outcome — that is a project engagement
- Model 04
Support retainer
A named engineer who knows your system, on defined response times.
Best for
Systems that are live and need to stay correct, patched and available.
How it works
- A monthly retainer covering a defined band of hours
- Response times agreed by severity, with an out-of-hours escalation path
- Security patching, dependency updates and platform deadlines included
- A monthly written report of what changed, what was patched and what is coming due
The trade-off
A retainer is capacity reserved, which means in a quiet month you have paid for availability rather than for output. That is the trade you are making, and it is the right one for a system where downtime is expensive — but it is worth naming rather than glossing.
Good fit
- Live systems where an outage has a real cost
- Software inherited from a team that has moved on
- Organisations without in-house engineering capacity
Bad fit
- Active feature development, which should be budgeted separately
- Systems nobody uses, where on-demand support is more economical
Who carries which risk
This is really the only question. Every difference between these four models follows from the answer.
| Model | Scope | Estimating risk | Priorities set by | Exit |
|---|---|---|---|---|
| Fixed scope | Fixed up front | Ours | The contract | At a milestone |
| Time & materials | Evolves | Yours, capped monthly | You, every two weeks | One month’s notice |
| Dedicated team | Your backlog | Yours | You, daily | One month’s notice |
| Support retainer | Defined hours | Shared | Severity, then you | One month’s notice |
Notice what is the same in every row: you can leave in a month. We do not use contractual lock-in, because a firm that needs it to keep clients has told you something about the work.
Contracts, ownership and getting out
Do you offer fixed-price contracts?
Yes, for work whose shape is genuinely known — usually meaning after a discovery. What we avoid is a fixed price on a poorly understood problem, because that arrangement forces us to price in a large risk buffer and then to defend scope aggressively, and both parties end up managing the contract instead of the product. For work that is still being shaped, time and materials with an agreed monthly ceiling serves you better.
Who owns the code and the intellectual property?
You do, from the first commit. Work happens in your repository under your organisation account, not in ours. There is no escrow arrangement, no licence-back clause and no per-seat fee on something you paid to have built. If you stop working with us tomorrow, everything keeps running and any competent team can pick it up. We think a firm that needs to hold your code to keep you has already told you something about the work.
What happens if we want to leave mid-project?
You leave. One month’s notice, we finish or cleanly stop the current slice, and we spend the remaining time on handover rather than on new work. Because each slice is a working piece of the system, you stop with something that runs rather than with a half-built layer. We would rather end an engagement well and be recommended than hold on to one that is not working.
Will you sign an NDA?
Yes, routinely, and usually before the first substantive conversation if you would prefer. We will also sign yours rather than insisting on ours. The only clauses we push back on are ones that would prevent us working in an entire industry for several years, which is a different thing from protecting your confidential information.
Not sure which of the four you need?
It usually comes down to one question: who is going to decide what gets built. Tell us the answer and the right model is normally obvious within ten minutes.