The first build is usually a project: a list, a date, a ceiling. The second conversation is different. You still need software. You no longer need a twelve-week "phase 1" theatre if the team already knows the repo. Retainer vs project vs team extension is how you pick the shape after that first SOW without sliding into an unnamed bench.
This is the map we use on how we work. It sits on fixed vs hourly, startup vs enterprise, and what belongs in a SOW. Billing is the price tag. The shape is who decides next week's work.
Three Shapes, One Engineering Bar
| Shape | You buy | You do not buy |
|---|---|---|
| Project | A named outcome, milestones, acceptance | Infinite adjacent tickets |
| Retainer | A reserved senior capacity per month, a backlog the owner ranks | A person who vanishes when the hours run out mid-incident |
| Team extension | Named engineers in your rituals, your repo, your tracker | A vendor PM translating every Slack message |
Tests, CI, secrets, and weekly demos do not become optional because the PO number changed.
When a Project Is Still Right
Stay on a project SOW when:
- The outcome can be listed (screens, APIs, a cutover)
- You can accept or reject a milestone without living in the backlog
- You want a ceiling more than you want "someone on tap"
Rebuilds, first MVPs after discovery, and regulated slices with a go-live date belong here.
Refuse a "project" that is actually "we will Jira whatever comes in." That is a retainer with worse accounting.
When a Retainer Fits
A retainer is for product teams that already shipped v1 and now have a mix of bugs, small features, and operational work that should not restart procurement each time.
Write down:
- Hours or a day-count per month, and what happens if you under-use them (expire vs roll a cap)
- Named lead, response window, timezone overlap
- How a large item is split back into a project SOW (so the retainer does not swallow a rebuild)
- Demo or written weekly note - silence is how retainers become a subscription to guilt
A retainer without a product owner on your side is an expensive inbox.
When Team Extension Fits
Team extension is capacity inside your system: standups, your GitHub org, your on-call doc. It is closer to hiring than to buying a milestone.
Use it when:
- You have an engineering manager who can rank work
- The codebase is yours (IP and repo already settled)
- You need months, not a six-week slice
Do not use it to skip having a manager. A "staffed pod" with nobody on your side to say no will invent work.
Rates and India-based senior delivery context live in custom software cost. Use ranges for planning; the SOW still names people.
What to Refuse
- Bench language ("we will assign whoever is free")
- Account layers between you and the people writing code
- Retainers that forbid you from a fixed project when a big item appears
- Team extension with IP left in the vendor org
- Volume metrics as a substitute for a named lead
A Simple Rule
If you can write acceptance tests for the next increment, prefer a project. If you cannot predict the tickets but can predict the need for a senior, prefer a retainer. If the work is your backlog and you can manage people, prefer team extension.
Hybrid is allowed: a project for the launch, a retainer for the ninety days after, written as two SOWs so finance can see the join.
FAQ
Can we start on a retainer with no prior project? Only if the backlog is real and someone on your side owns it. Otherwise buy discovery, then a project.
Is team extension just staff aug? It is staff aug with your repo and your rituals. If the vendor still owns Git and the PM, it is a project in disguise - usually a worse one.
What if we under-run a retainer? That should be in the SOW: a modest roll-over or a pause. Do not invent hours to "use the budget." That is how you get software nobody asked for.
The Bottom Line
Retainer vs project vs team extension is a decision about how work is chosen, not about how serious you are. Write the shape, name the lead, keep the demo. Then the second year of the product does not require a new origin myth.
Choosing a shape after the first build? See engagement models, browse services, or contact us for a free estimate.