Most conversations about "project or team" start from price — fixed or hourly — and get stuck there. But price is a consequence of the decision, not the decision itself. The real question is who holds the decisions about what gets built, and who carries the responsibility when the result is not what was expected. This guide answers it in five parts: what is known vs changing, a responsibility matrix, how each model prices change, two marked examples, and what is handed over at the end.
What is known and what is changing? — three questions before the model
The right model follows from three answers. All of them are about your side, not the vendor's:
- How clear is the scope? If you can write today what the system will and will not do — as user actions, not features — there is a basis for a project. If the answer is "we will know when we see it", a fixed-price project will turn into a series of change proposals.
- How clear is the duration? If a date depends on the deliverable — a launch, a customer contract, a funding round — a project gives a commitment to a date against scope. If the work simply continues as long as the product lives, there is no "end" to commit to.
- Who will manage it on your side? An ongoing team needs someone on your side who decides every week what comes next, answers questions and makes product decisions. Without that person the team will invent the priorities itself — or wait. A project needs less: someone who signs off milestones and answers questions on time.
Rule of thumb: two "clear" answers out of three — a project. Two "changing" — a team. One each — start with a small project that clarifies the scope, and decide after it.
Responsibility matrix — who holds what in each model
This is the table that saves most arguments later. Five areas, and in each — who is responsible in a project, and who with a team. "Responsible" here means who makes the decision and carries its consequence.
| Area | Defined project | Ongoing team |
|---|---|---|
| Product — what gets built | You, once, in the scope document; afterwards only through a change process | You, every week or two, in the backlog; the team advises and estimates |
| Budget | Fixed against the scope; overrun is the vendor's problem unless the scope changed | Fixed per period by capacity; how much 'comes out' of it depends on your priorities |
| Quality and QA | The vendor — against written acceptance criteria; you run acceptance at the end of each stage | The vendor — tests, code review and standards are part of the capacity; you sign off each delivered item |
| Development — how it gets built | The vendor, within the technical constraints in the agreement (stack, environments, code ownership) | The team, by agreed standards; major architecture decisions — together |
| Production — monitoring, deployments, incidents | Until handover — the vendor; afterwards — per a separate maintenance agreement, or you | The team, within the scope and service hours the agreement defines — not beyond them |
How is change priced? — fixed price, hourly and capacity
Here price comes in — but as a question about change, not about a sum. The three common pricing models behave differently the moment something changes, and that is what actually matters about them. Keep two things apart: the pricing model (how you pay) and the service model (project or team) are two decisions. A project can be hourly; a team can be a fixed monthly price.
| Pricing model | What you pay for | What happens when something changes | Your risk |
|---|---|---|---|
| Fixed price | A defined deliverable, regardless of how long it took | A written change proposal: what is added or removed, what it costs, how it moves the date. No approval — no change | Under-defined scope surfaces as a string of changes; a vendor who prices low and then 'finds' changes |
| Hourly (time and materials) | Actual working time, at a rate per role | You simply work on the new thing; the cost updates. Transparency depends on reporting | No built-in ceiling; without close management the sum grows while the deliverable does not advance |
| Capacity (retainer) | Roles at a defined allocation for a period — e.g. 'one full-time developer and a designer at a quarter' — at a fixed monthly price | Change is not priced — the queue is reordered. What is deferred is deferred | Capacity wasted because nobody on your side decides; a 'team' that is in fact half a person if the allocation is not written down |
The rule that repeats across all three: what is written is enforced, what is not written is argued about. With capacity — the allocation per role, in writing, before anyone uses the word "team". With fixed price — the scope document and acceptance criteria. Hourly — the reporting: what was done, how long it took, and what was achieved.
Two engagement examples — illustrative
Example A — project: an ordering system for business customers
A distributor wants its business customers to enter orders in a portal instead of by phone, and there is a date: the start of the season. The scope is clear — catalogue, basket, credit approval, integration with the existing ERP — and nobody at the company will manage developers. The model: a fixed-price project against a scope document with four stages and acceptance criteria for each. Halfway through, the CEO also wants an app for field reps. It does not go in "on the way": a change proposal is written — what is added, what it costs, how it moves the date — and the company chooses to defer it until after the season. At the end: handover of code, accounts and documentation, and a separate maintenance agreement for production.
Example B — team: the same company, a year later
The portal is live, customers use it, and requests arrive every week: a new report, a change to the approval flow, the deferred field-rep app. The company has appointed a product manager who decides what comes next. The model moves to a team at a defined capacity — the agreement states explicitly which roles and at what allocation, for a quarter, at a fixed monthly price. There are no more change proposals: the product manager reorders the queue every two weeks, the team estimates and advises, and every delivered item is signed off by her. The agreement also sets what the team does in production — monitoring, deployments, incident handling — and in which hours. At the end of each quarter: a report of what was delivered, and a check whether the capacity suits the next quarter — up, down, or back to one-off projects.
What changes between the two examples is neither the vendor nor the product — but who decides, how clear the next step is, and who manages it on the client's side. That is exactly what the three questions in the first section test.
Advantages and disadvantages — honestly, for both models
| Comparison | Defined project | Ongoing team |
|---|---|---|
| Advantages | Price and date certainty against scope; clear vendor accountability; little management needed from you; easy to compare vendor proposals | Flexibility — direction changes without negotiation; knowledge accumulates in a team that knows the product; continuity in production; a steady pace to plan around |
| Disadvantages | Every change costs time and money; the vendor is incentivised to stick to scope even when the need changed; knowledge moves to you only at handover; an 'end' after which maintenance has to be arranged | Needs someone on your side deciding every week; no commitment to a deliverable — only to capacity and quality; easy to pay for unused capacity; harder to compare vendors |
What is handed over at the end — in either model
A project has a handover day. A team has a day when the engagement ends or shrinks. In both cases what passes to you needs to be written in advance, because that is the moment it is hardest to demand:
- Code — the repository in your name from day one, not transferred at the end. Including the change history.
- Access and accounts — cloud, domain, app stores, third-party vendors: owned by you, with access granted to the vendor — not the other way round.
- Documentation — how to run, how to deploy, each environment's configuration, and which architecture decisions were made and why.
- Knowledge — with an ongoing team this is the easiest part to lose: whoever worked on the product for a year knows things that are not written down. A defined overlap period, in writing, is part of the agreement.
- Delivered vs ordered — in a project: a list against the scope document. With a team: what was delivered in the last period and what remains in the queue.
How this works with us
We work in both models, and often one after the other: a defined MVP project that ends in handover, then — if the product is live and direction keeps changing — an ongoing team at a written capacity. In both cases the roles, the allocation and what is delivered are defined in the agreement, not in a conversation. Both tracks are detailed on the service page.
Track A — a defined MVP project: deliverables, scope and exclusions, acceptance conditions, and what happens after handover. Project track details
Track B — an ongoing development team: roles and allocations, responsibility split, cadence and reporting, and how it starts and ends. Team track details
And once the model is chosen — how to choose the vendor itself, and what to ask them, in a separate guide. How to choose a software house — questions, warning signs and what to check