Photo: Google Gemini · AI-generated
Every software vendor has the same problem: the roadmap is bigger than the team.
There are two honest ways to close that gap with a partner. You can extend the team — external developers join your product team, work in your codebase, and follow your architecture. Or you can hand off a module — a partner takes a defined piece of work and delivers it end to end. Both models work. Choosing the wrong one for the wrong work is what gets expensive.
Here is the framework we use with the software vendors we work for — and two real projects that show each side of the line.
Hand off what is separable
Some work has a natural boundary: a clear scope, a stable interface to the rest of your product, and no need for your team’s day-to-day involvement. That work is a candidate for a full hand-off.
Two examples from our own client work. ERP Advisor is a lead-qualification tool we built for an ERP consulting company — a guided questionnaire that produces a tailored ERP recommendation and books qualified prospects into consultations. It matters commercially, but it is not the vendor’s core product, and it runs on its own stack. Handing it to a partner end to end cost the vendor’s own team nothing: no context switching, no stack detour, no roadmap delay.
Mobile ERP sits closer to the product but shows the same boundary logic. A vendor’s warehouse app had to move off Windows CE — an end-of-life platform — onto Android, while talking to Sage 100 exactly as before. The interface was the boundary: as long as the new app used the same data layer, the entire modernisation could be delivered white-label by a partner, and the vendor’s team never had to become Android specialists for a one-time platform move.
The pattern in both cases: separable scope plus a stable interface equals hand-off. The partner carries the delivery risk; your team keeps building the product.
Extend the team for the core
The calculation reverses for work inside your core product. Continuous feature development, architectural evolution, the code your customers renew for — this work has no clean boundary, and it benefits from context that builds up over months and years. Handing it off piece by piece means paying the knowledge-transfer tax on every piece.
For this work, the right model is a dedicated team: external developers embedded as a stable extension of your own engineering organisation — your backlog, your architecture decisions, your standards, their capacity. The value compounds precisely because the people stay: an engineer eighteen months into your codebase makes decisions a rotating contractor cannot.
The four questions
When a software vendor asks us which model fits, we ask four things:
- Is the scope separable? Can you draw a line around it and define the interface? If yes, hand-off is possible.
- Is it your core product? Work your customers directly renew for belongs close to your own team — extend, don’t hand off.
- Is the work bounded or continuous? A migration or a standalone tool ends; core development doesn’t. Bounded favours hand-off, continuous favours an embedded team.
- Does it match your team’s stack? A one-time detour into an unfamiliar technology is a strong hand-off signal — building that expertise in-house for a single project rarely pays back.
Two of those answers usually point the same direction. When they conflict, the core-product question wins: keep the core close, hand off the edges.
We work with software vendors in both models — often both at once for the same client. If your roadmap is bigger than your team, tell us what’s on it — we’ll tell you honestly which pieces are hand-off candidates and which aren’t.