Half built, and not moving
The project started with energy. The first release was planned, a developer or two were on it, some screens exist. Then it slowed. Priorities shifted, a key person got pulled onto something else, a technical problem ate a month. Now nothing much has happened for a while and people have stopped asking about it in meetings.
You want to restart it. The question everyone raises is whether to bring in extra developers to join your team, or to hand the whole thing to an agency and get it done. Articles comparing staff augmentation and outsourcing in general do not quite answer it, because they are not about your stall.
Start with why it stopped
The right model depends on what is actually missing. Adding developers to a project with no owner does not restart it, and outsourcing a project your own team needs to control makes the next stall more likely.
| Why it stalled | What is missing | Usually fits |
|---|---|---|
| Developers pulled onto other work | Hands | Staff augmentation |
| A technical problem nobody could solve | A specific skill | Staff augmentation with a specialist |
| Nobody owns the project day to day | Delivery ownership | Outsourcing a bounded piece |
| Scope keeps changing | Product decisions | Neither, until that is fixed |
| The team has no experience of this type of build | Method and experience | Outsourcing, with handover planned |
The scope row is worth being honest about. If decisions keep changing, any extra capacity will be spent building things that get thrown away.
The cost of choosing the wrong model
Pick augmentation when nobody on your side can direct the work, and the added developers wait for decisions or make them without context. Pick outsourcing when your team needs to own and evolve the product, and you end up with a delivered system nobody in-house understands, plus a handover problem later.
Both mistakes cost money and time, and both leave the project in roughly the same stalled state with a bigger bill attached.
Waiting has a cost as well. A half-built project is not neutral. The code ages, the people who remember the early decisions drift away, and the business need it was meant to meet gets solved some other way, usually with a spreadsheet. The longer it sits, the more of the existing work has to be re-learned or redone when someone finally picks it up.
How we restart it
- Diagnose the stall. We look at the code, the backlog, recent activity and who is involved, and talk to the people who were working on it.
- Agree the missing piece with you: hands, a skill, ownership, or decisions.
- If it is hands or a skill, we add developers from SpiderHunts to your team. They work in your repository and tools under your direction.
- If it is ownership, we take on a clearly bounded part of the project (a module, an app, an integration) with our own delivery lead, working to acceptance criteria you agree, in your repository.
- If it is decisions, we help run a short scoping exercise to settle them before any building starts, because otherwise extra capacity will be wasted.
- Either way, we plan the handover from day one: documentation, tests and your team reviewing code, so the project does not depend on us to keep moving.
Many projects end up with a mix: a bounded piece outsourced to us, and a developer embedded in your team for the rest. That is fine. The point is to match the model to the cause.
Once it is moving again
Work is visible again: tickets moving, releases landing on staging, decisions being made. The people on your side know what they own and what we own. And because the code and knowledge stay with you, the project can carry on after the extra capacity steps back.
Is this your project?
- Something was started, partly built, and then went quiet.
- You are debating whether to add developers or bring in an agency.
- Nobody has clear day-to-day ownership of the project.
- The team hit a technical problem outside its experience.
- You want it finished without losing control of it.