Add a squad without adding headcount.
Not one developer — a small group with its own lead, working alongside your team on a defined slice of the roadmap. Scale up for a launch, scale back after, without a hiring or redundancy process.
We add a small cross-functional squad — typically two to six people with an embedded lead — alongside your existing team. They own a defined slice of the roadmap rather than individual tickets. Monthly, scaling up or down as your plans change.
Updated August 2026
Four developers, or one squad.
The same headcount costs your lead very different amounts of attention.
One extra developer helps. A squad ships a thing.
A single developer added to a busy team still needs your lead to break work down, review it and unblock it. That is real management time, and it partly cancels the gain.
A squad comes with its own lead. You hand over an outcome — the new checkout, the reporting module, the mobile app — and they run it, syncing with your team rather than depending on them for every decision.
It suits a period rather than forever: a launch, a migration, a quarter with more roadmap than team. When it ends, it ends. No redundancy process, no hiring to unwind.
What a squad looks like.
An embedded lead
Someone who breaks the work down and runs the day-to-day, so your lead is not managing four extra people.
Two to six people
Engineers, plus a designer or QA where the work needs it. Sized to the outcome, not to a package.
One outcome to own
A module, a platform area, an app. Clear enough that progress is obvious without a status meeting.
Working in your process
Your repository, your board, your release process. Not a parallel project delivered at the end.
One sync with your lead
Weekly, or daily during a launch. Enough to stay aligned without absorbing your team's time.
Scaling monthly
Add for a push, reduce after. The whole reason to do it this way.
Knowledge that stays
Documentation and walkthroughs as they go, so nothing walks out when the squad does.
A defined end
We plan the handover from the start, because a squad that becomes permanent should have been a hire.
One developer, a squad, or a fixed project.
The question is how much of your lead's time you can afford to spend on managing the extra capacity.
| One developer | Squad | Fixed project | |
|---|---|---|---|
| You hand over | Tickets | An outcome | A specification |
| Management load on you | Real — daily | Light — one lead to one lead | Almost none |
| Changing direction | Free | Free within the outcome | Re-scope and re-quote |
| Visibility of progress | Your board | Your board | Milestones |
| Good for | Filling a specific skill gap | Owning a slice of roadmap | A well-understood build |
| Poor for | Owning anything end to end | Vague or shifting outcomes | Anything still being figured out |
What we can staff.
12+ developers, 2 designers, 2 project managers, 2 marketing strategists.
Behind Doha and Muscat. A shared working day rather than overnight handoffs.
Up for a launch, back down after, without a redundancy process.
When a squad fits.
More roadmap than team, for a quarter or two
The classic case. Hiring for a temporary peak leaves you overstaffed after it.
A big piece nobody has capacity to own
A migration, a rebuild, a new platform area that keeps being deferred.
You need to move on two fronts
Keep shipping the core product while something new gets built beside it.
Not for permanent core work
If it is central and ongoing, hire. We will say so — a squad that never ends is an expensive way to avoid recruiting.
How we work.
We agree the outcome
What the squad owns, and how you will know it worked. Vague outcomes are the main reason this model fails.
We size it
Skills and number of people, against the outcome and the deadline. Sometimes the answer is fewer people and more time.
You meet the lead
The most important person in the arrangement. If your lead is not confident in them, we change them.
They start inside your process
Your tools and release process from week one, so nothing has to be integrated at the end.
One sync, not many
Lead to lead, weekly or daily as the phase needs. Your team keeps working.
We plan the ending
Documentation and handover as we go, so it is done before the squad leaves rather than after.
Frequently asked.
6 questions answered. Still have one? Reach out.
Dedicated developers work your board and your lead assigns their tasks. A squad brings its own lead and owns an outcome — you hand over the reporting module rather than a list of tickets. The practical difference is management load: one extra developer still needs your lead's time daily, while a squad needs one conversation a week.