There are two ways to work with us: a fixed-scope project with a defined end, or a long-term partnership on a system that keeps growing. Our process page sets them side by side: what each includes, how it is billed and how changes are handled.
This article is about the harder part: choosing. Neither model is better. They suit different situations, and picking the wrong one makes an otherwise good project feel difficult.
The question underneath
Most of the decision comes down to one question: how much will change after launch, and who will make those changes?
If little will change, or someone else will make the changes, a defined project fits. If the product will keep changing and nobody else is there to change it, a partnership fits. Everything below is a way of answering that question honestly.
Signals that point to a fixed scope
- You can describe the one journey that must work on day one. Not every feature, just the core journey. If you can say it in a sentence, it can be scoped.
- Someone will own it afterwards. An in-house developer, or a product that needs little change once it is live.
- The budget is a fixed amount for a defined outcome, such as a budget line for this year.
- A date matters. A season, a launch, an exam period. A bounded project is easier to fit to a fixed date.
Signals that point to a partnership
- People already use it, and they ask for things.
- Priorities change month to month, as feedback arrives.
- There is no engineer in your team who knows the system, and you don't plan to hire one yet.
- It can't be left alone. Security updates, dependency upgrades and small fixes can't wait for a new project each time.
- The work is many small things rather than one large one.
A partnership is not a way to postpone deciding the scope.
Signals that mislead
Some reasons for choosing feel sound and aren't.
"We'll figure out the scope as we go." A partnership chosen to avoid deciding what to build becomes a monthly payment for uncertainty. Decide what the first version must do; a partnership can follow once it exists.
"Fixed scope is cheaper." It is more predictable, which is different. A product still finding its users will change a lot, and on a fixed scope every change is weighed and priced on its own. If change is certain, a partnership is often the calmer arrangement.
"A website doesn't need anyone after launch." It needs much less, but not nothing: renewals, updates, a new service or a changed price. A fixed-scope site still needs someone named to do that, whether a member of staff, another developer or a small arrangement with us.
"We need a partner because the project is big." Size isn't the signal. A large project with a clear scope is still a fixed-scope project; it simply has more of it.
Three examples
These are illustrations, not descriptions of particular clients.
A tradesman's website with a quote form. Once it is live, changes are rare: new photos, a new service, a seasonal offer. Fixed scope, with someone named for the small updates.
A first release of a booking platform for one business. The core journey is clear, but nobody knows yet what users will ask for next. A fixed-scope first release, then a decision once real use shows what comes next.
A learning product used every day. New content, new questions and new features are requested every month, and there is no in-house team. A partnership, so the people who know the system keep improving it.
When we recommend each
We usually recommend a fixed scope for a first release, even when a partnership is likely to follow. A bounded first version forces the decisions that make everything after it cheaper.
We recommend a partnership when a system is in production with real users, and nobody else looks after it.
Sometimes we recommend neither. If the real need is a clear page and a contact form, a project is more than it needs. And if a product will need full-time engineering for years, an in-house developer may serve it better in the long run, so we build the system to be handed over.
How clients switch
Choosing isn't permanent. Clients move between the two, and each move has a natural moment.
From fixed scope to partnership. The most common path. The scope document is replaced by a shared priority list. The first weeks after launch are the best time to decide, because real use shows what matters next.
From partnership to a defined project. When a large, well-defined piece of work appears inside a partnership, such as a client portal, it can be scoped as its own project, so it doesn't consume the monthly capacity meant for keeping the system healthy.
From partnership to an in-house team. The goal is a quiet exit: documentation current, open work listed, accounts already in the client's name. What that takes technically is in The handover is part of the product.
A quick self-test
Can you describe the one journey that must work at launch? yes → fixed scope
Will someone else own and change it after launch? yes → fixed scope
Do users already ask for changes every month? yes → partnership
Is there an engineer in your team who knows the system? no → partnership
Would you rather decide the scope once, or every month? once → fixed scopeMostly one answer: start there. A mix: a fixed-scope first release, then decide with real use in front of you.
What this means for your project
Ask how much will change after launch, and who will change it. Little change, or an owner afterwards, points to a fixed scope; a live product that keeps changing, with nobody else to change it, points to a partnership. If you're unsure, a fixed first release followed by a decision is rarely wrong.
