Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. Scaling a Development Team Up and Down
Software Strategy

Scaling a Development Team Up and Down

Demand for engineering is rarely flat. How a mixed permanent and augmented model absorbs the peaks without cycles of hiring and redundancy.

Updated 2 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

Size the permanent team for the work that is always there and use augmentation for the peaks. The failure is sizing permanently for the peak, which leaves you overstaffed in the troughs and facing redundancies you could have avoided.

The short answer

Hire permanently for your baseline, which is the work that exists every month regardless of what is happening. Use augmentation for anything above it. That way the peaks do not turn into redundancies when they pass.

Most teams size for the peak because the peak is when the decision gets made, under pressure, with a backlog that looks permanent.

Find your actual baseline

  • Maintenance and support that happens whatever else is going on
  • Security patching and dependency upgrades
  • The steady flow of small product improvements
  • Incident response and the work that follows it
  • Whatever keeps existing customers from leaving

That is your floor, and it is usually smaller than the current team. Everything above it is project work, which is where flexibility belongs.

The cost of getting it wrong

Sized forIn a peakIn a trough
Peak demandFinePaying for idle capacity, or redundancies
Baseline onlyEverything is lateEfficient
Baseline plus augmentationAbsorbs itEngagement ends, no redundancy

The bottom row is not free. Augmentation costs more per day and repeats onboarding. It buys you the ability to be wrong about demand without it costing someone their job.

Keep the permanent core strong

Flexing works only if the permanent team holds the knowledge. If augmented people outnumber the people who understand the product, the engagement ending takes the knowledge with it.

Practical rule: your own people should be able to run everything in production and review everything that gets merged. If that stops being true, the balance has tipped too far.

Plan the ramp honestly

  1. Augmentation is quicker to start than hiring, not instant. Allow weeks.
  2. Onboarding costs your team time every cycle, so fewer and longer beats many and short.
  3. Notice periods mean ramping down takes weeks too.
  4. Knowledge transfer has to happen before the ramp-down, not during it.
  5. A short trough is usually cheaper to absorb than to react to.

When permanent hiring is the right answer

If the work above your baseline has been there for a year and shows no sign of ending, it is not a peak, it is your new baseline. Keeping it on augmentation indefinitely costs more and leaves knowledge outside the company.

The honest signal is renewing the same engagement repeatedly. At the second or third renewal, the question is whether you are buying flexibility you are not actually using.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

What ratio of permanent to augmented is sensible?

No universal number, but once augmented people outnumber those who know the product, knowledge retention and review both come under strain.

How quickly can we scale up?

Faster than hiring, typically weeks rather than months, but not instant. Vetting and notice periods still apply.

Is it cheaper than hiring and making redundant?

Almost always, once you count recruitment, redundancy costs and the effect on the people who remain.

What if we keep extending the same engagement?

That is a signal the work is baseline rather than peak, and a permanent hire is probably the better economics.

Keep reading

More on Software Strategy

Software Strategy

Machine Learning Myths That Waste Budgets

Eight beliefs about machine learning that quietly inflate project costs, what is actually true instead, and how to spot each one in a proposal.

Start here

Thinking about adding developers to your team?

Tell us what you are building, what your team looks like now and where the gap is. We will come back with an honest view on whether augmentation fits, how many people it would take and what it costs. If hiring directly would serve you better, we will say so.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →