How small can a SaaS team be in 2026?

The question behind most enquiries we get is not really about technology. It is: how many people do I have to pay to keep this product alive? For a decade the answer for a modest B2B SaaS was six to ten — a couple of backend engineers, a frontend, someone doing QA, someone doing infrastructure, a product person, and an on-call rota stretched across whoever was left.

That number has changed. It has not changed to zero, and the gap between those two claims is where people lose money.

What genuinely moved

Implementation moved first and moved furthest. Writing a well-specified feature against an existing codebase is now largely an agent task, and this is the part everyone has seen.

Less obvious, and commercially more significant: the surrounding work moved too. Code review, test authoring, deployment orchestration and first-line incident response are all now substantially agent-run — and in headcount terms those were never one job each. They were the reason you needed a rota.

• Code review. An agent reviews every PR before a human sees it, which changes review from a bottleneck into a filter.
• Testing. Cases derived from acceptance criteria, run on every change, maintained by the thing that wrote them.
• Deployment. Canary, watch, roll back — decided by the deploy agent rather than by a person at 3am.
• First-line triage. Correlating an alert against recent deploys is pattern matching, and pattern matching is what these systems are for.

What did not move

Two things, and they are the same problem wearing different clothes: deciding what should happen when the specification does not say.

Deciding what to build

An agent will build what you specify, quickly and without complaint. It will not tell you that the feature is a distraction, that the customer asking for it is about to churn anyway, or that solving it properly means changing the pricing model. That judgement is commercial, it depends on context that lives outside the codebase, and it carries consequences an agent does not bear.

Owning the consequences

Someone has to be accountable for a production release and for an incident that reaches customers. Not because agents are unreliable — increasingly they are not — but because accountability is a property of people. In regulated environments this is written down. Everywhere else it is still true, and you discover it during your first serious outage.

So what is the number?

For a B2B SaaS with real customers and a normal feature cadence, the shape we see working is one to two people plus a well-wired agent pipeline, where previously it was six to ten.

The caveats matter more than the table. That senior reviewer has to be genuinely senior — someone who can tell a plausible diff from a correct one, which is a harder skill than writing the diff was. A team of one junior plus agents is not a small team; it is an unreviewed one, and it will accumulate problems faster than the old process ever did.

The costs do not go to zero either. They change shape, from salaries to inference and tooling, and inference scales with activity rather than with headcount. That is usually a much better cost curve, but it is a real line and it needs a cap.

The parts beyond engineering

The same pattern extends past the codebase — support triage, content drafting, ad copy variants, social scheduling, reporting. Anything with structured inputs and a checkable output is a candidate, and small teams get real leverage here.

Two honest caveats. The output still needs someone with taste deciding what ships, because the failure mode of automated marketing is volume without judgement, and that is worse than doing less. And anything customer-facing needs the same escalation rule as production: when confidence is low, a human answers.

How to tell if you are ready

The constraint is almost never the agents. It is whether your codebase and your process can be automated against.

1. Can you describe a feature precisely enough to test it? If your requirements are conversations rather than criteria, agents will amplify the ambiguity.
2. Does your test suite mean anything? Agents lean on it as the safety net. A suite nobody trusts is not a net.
3. Is a deploy one command? If shipping requires tribal knowledge, no agent can do it either.
4. Can you roll back in under a minute? This is what makes unattended deploys safe.
5. Is there one senior person who will actually read the reviews? Without this, you have automated production and left out quality control.

Five yeses and the pipeline in the agentic SDLC is a few weeks of work. Fewer than five, and fixing those gaps is the higher-value project — it makes the human team faster too.

This is the work we do: wiring agent pipelines into products that already have customers, so the team that runs them can stay small. Book a call and we will tell you which of the five you are missing, whether or not you hire us.

Frequently asked questions

References

1. DORA research programme — DORA
2. SWE-bench — SWE-bench
3. Subagents — Anthropic
4. Site Reliability Engineering — Google