A reduction in force removes engineers in a day. It does not remove the roadmap, the customer commitments, the on-call rota or the technical debt. The people who remain inherit all of it, usually with a hiring freeze attached, and the leader who has to make it work is often the same person who delivered the bad news. This guide is a practical plan for the months that follow: how to triage what the smaller team should do itself, how to protect that team from the slow collapse that follows layoffs, which work to buy as fixed-price scopes instead, and how to avoid the common outcome where the company pays recruitment fees a year later to rebuild exactly what it cut.
The first month: stop the roadmap from running on autopilot
The most damaging thing after layoffs is a roadmap that continues unchanged. It was planned for a larger team; left alone, it will simply be delivered late and badly, and the remaining team will absorb the blame. Three actions in the first month prevent that.
Re-plan against the team you have, not the team you had
List every committed item and sort it into four groups: contractual commitments with dates, work that protects revenue, work that reduces operating cost, and everything else. Be explicit about which items the remaining team can deliver on time, which they can deliver late, and which they cannot deliver at all. Write it down and share it with the executives who own the commitments. The point is to force decisions upward, where they belong, rather than letting them land on the team as overtime.
Separate keeping the lights on from building new things
A smaller team's first obligation is operational: incidents, security patches, customer-blocking bugs. Measure how much of the team's capacity this consumes in a normal week. What remains is the real capacity for new development, and it is usually much smaller than the headcount suggests. Plan new work against that number.
Identify what only your team can do
Some work genuinely requires people who know your product, your customers and your history: product decisions, incident response, customer-facing engineering, the parts of the system nobody has documented. Other work is specifiable: a new module, an integration, a migration, a rebuild of a subsystem. The first category must stay with the team. The second category is what you can buy as a fixed-price scope, and separating the two is the key decision of the whole plan.
Protect the remaining team
Layoffs are followed by voluntary departures more often than leaders expect. The people who stayed are the ones with options, and the months after a reduction are when they exercise them. Keeping them is cheaper than any other measure in this guide.
- Take new development off them if it means overtime. A team doing maintenance by day and features by night will lose its best people first.
- Make the re-plan visible. Engineers leave when they believe management does not understand the situation. A written, honest re-plan is evidence that it does.
- Keep them as owners. If outside capacity is used, your engineers must remain the owners of the codebase: they review and merge, they decide architecture questions that affect the system's future, they are not reduced to supervising a vendor by the hour.
- Document while you still can. The knowledge that left with the laid-off engineers is gone. Spend a little of the remaining capacity writing down what is left before it leaves too.
Decide what to buy as fixed-price scopes
For the specifiable work, the question is not whether to get outside help but what kind. Hourly contractors bring back the monthly cost structure that was just cut, with none of the institutional knowledge. Agencies on time and materials shift the risk of overruns to you at a moment when you cannot absorb it. Re-hiring is slow and, during a freeze, off the table.
A fixed-price scope is the option that fits a reduced budget: a defined piece of work, a price known in advance, a delivery in days or weeks, and no ongoing cost when it ends. To use it well:
- Pick items that are complete outcomes. A new reporting module, an integration with a partner system, a migration off a deprecated platform. Not "help with the backlog".
- Write each as a scope with outcomes, boundaries and acceptance criteria. The format is in how to write a scope for a fixed-price quote. The team that remains should write the acceptance criteria; they know what will break.
- Insist on tested, documented deliveries that pass through your normal review. Your team stays in charge of the codebase; the vendor delivers packages your team integrates.
- Start with one real, bounded piece before committing to a larger scope. A vendor is best evaluated on your own code. In our engagement that first piece is a trial build at a fixed 9,900 euros, delivered within 72 hours of written scope confirmation, with the price deducted in full from the main project.
- Keep the architecture decisions with someone accountable. On our side AIPOS OÜ designs the architecture and specification in-house and agrees them with you in writing, so your senior engineers are not pulled into design work they no longer have time for; on your side, one person confirms scopes and accepts deliveries in writing.
What this buys is development capacity that does not appear on payroll, does not need onboarding, and ends when the scope is delivered. The page for companies after developer layoffs sets out how it works in detail.
Security and compliance do not get a holiday
A smaller team is also a smaller security team. When outside capacity touches your codebase, the requirements are the same as before the layoffs, and the people checking them are fewer. The minimum to insist on from any vendor: a separate, isolated environment for your project in the vendor's own infrastructure; no connection to your systems; every delivery scanned and reviewed before it reaches you; and clear written terms on how AI models, if used, handle your code. These are the conditions we work under, and the checklist is in security when AI agents build your software.
Avoid paying twice for the same capacity
The expensive mistake after layoffs is the re-hire eighteen months later: recruitment fees, higher salaries, onboarding time, for the same roles that were cut. It happens when the roadmap was never re-planned and the company tries to return to the old operating model as soon as the budget loosens.
The alternative is to change the operating model permanently. Keep a core team that owns the product, the architecture decisions and the work that needs institutional knowledge. Buy the large, specifiable scopes at fixed prices as they arise. Hire only for roles that need a person inside the company for the long term, with evidence of what that role is. The comparison between the two models is set out in instead of hiring developers, and the cost structure behind it in the real cost of an in-house developer.
This model has a side effect that matters after layoffs: it makes the next budget cut, if there is one, far less destructive. Fixed-price scopes stop when you stop ordering them. Nobody has to be laid off to reduce development spend.
A ninety-day plan
Days 1–30. Re-plan the roadmap against real capacity; separate operations from new development; identify work only the team can do; write down what is undocumented; share the plan upward.
Days 31–60. Write the first specifiable roadmap item as a scope with acceptance criteria. Run a trial build on it with a fixed price, a daily written report and a code package at the end. Judge the code, the speed and the written process with your team.
Days 61–90. If the trial meets the bar, quote the full scope at a fixed price and deliver it. Add the next specifiable items to the same pipeline. Report to executives in terms of scopes delivered and accepted, not hours or headcount.
By the end of the quarter, the roadmap is moving again, the team is doing the work only it can do, the cost of development is known in advance, and the company is no longer one budget cycle away from another round of layoffs. The request form is where the first scope goes; the reply is a written scope description.
Frequently asked questions
Our remaining engineers are already overloaded. How do they also manage a vendor?
They should not have to. A fixed-price scope with written communication, architecture designed by the vendor and agreed with you in writing, and tested packages that pass through your normal review means your engineers confirm a scope, read a daily report and review deliveries. There are no stand-ups, status calls or timesheets to manage.
Is it safe to let outside capacity into a codebase we barely have time to maintain?
It is, if the conditions are right: an isolated environment in the vendor's own infrastructure, no connection to your systems, scanning and independent review of every delivery, and tested, documented packages that your team reviews. A package at every milestone also means your team keeps the full history and ownership.
Should we use hourly contractors instead?
Hourly contractors restore the monthly cost structure that was just cut, carry no responsibility for the result, and still need managing. For specifiable work, a fixed-price scope gives a known cost, a known delivery and no ongoing commitment. Contractors fit better for roles that need a person present, such as on-call cover.
How do we explain this to the executives who approved the layoffs?
In their own terms: development spend becomes a variable cost tied to specific outcomes with known prices and dates, rather than a fixed payroll. Report scopes delivered and accepted. The trial build gives them a concrete, bounded first step to approve.
What if we need to rebuild the team later?
Then you do it with evidence: a working product, a documented architecture, and a clear picture of which roles genuinely need a person inside the company. Many companies find that a smaller core team plus fixed-price scopes is the better permanent model, because the next budget cut no longer requires layoffs.
How quickly can outside capacity start?
In our model, you receive a written scope description after sending the request form, and the trial build is delivered within 72 hours of your written confirmation of that scope. There is no recruiting or onboarding period.