SaaS Development Team Structure
- Pre-PMF / Pre-Seed: 2–4 engineers, CTO or senior full-stack anchor
- Seed (£500k–£2M ARR): 5–12 engineers, first dedicated DevOps, first QA
- Series A (£2–8M ARR): 12–30 engineers in 2–4 squads, first Engineering Manager
- Series B (£8–25M ARR): 30–80 engineers, platform team forming, Staff Engineers needed
- Series C+ (£25M+ ARR): 80–200+ engineers, full Team Topologies model, Principal Engineers
- AI impact: Each engineer tier is producing ~30–50% more output vs 2022 — adjust headcount targets accordingly
Every SaaS company needs engineers. But the question of how to structure, sequence and scale an engineering team — and when to hire which role — is one that founders and engineering leaders consistently get wrong in predictable ways. Hiring backend engineers before you have product-market fit, promoting your best developer into an Engineering Manager role too early, not building a platform function until after a production incident has cost you customers — these mistakes are common, expensive, and avoidable.
This guide covers how a SaaS development team should be structured at each funding stage, which roles to hire in what order, when to separate Engineering Manager from Tech Lead, how to think about outsourcing vs in-house, and what AI tools are doing to headcount planning in 2026. UK salary benchmarks for each key role are included throughout. Vertical vs horizontal SaaS architecture
Note: this guide focuses on the engineering and development function. For the product management side of the team — CPO, Head of Product, Product Manager roles and their relationship to engineering — see our companion guide: SaaS Product Team Structure 2026.
- How SaaS Engineering Differs From Other Software Development
- Core Roles in a SaaS Development Team
- Team Structure by Funding Stage
- Engineering Team Models: Squads, Tribes and Team Topologies
- The Hiring Sequence That Matters
- Engineering Manager vs Tech Lead: When to Hire Which
- DevOps, SRE and Platform Teams: When to Break It Out
- Insourcing vs Outsourcing: The Decision Framework
- AI Impact on SaaS Development Teams in 2026
- UK Salary Benchmarks by Role
- Common Structural Mistakes
- Frequently Asked Questions
How SaaS Engineering Differs From Other Software Development
SaaS engineering is not the same as building bespoke software or enterprise IT projects, and structuring a team for it requires a different approach. The defining characteristics that should shape your team design:
- Continuous delivery, not project delivery: A SaaS product is never “finished.” Your team structure must support releasing multiple times per week (or day) indefinitely — not working to a single go-live date. This means DevOps, CI/CD and observability are first-class concerns, not afterthoughts.
- Multi-tenancy by default: Every architectural and team decision has to account for serving many customers from shared infrastructure. Data isolation, access controls and reliability requirements shape what skills your engineers need.
- Product and engineering are tightly coupled: The speed of iteration that defines successful SaaS depends on product managers, designers and engineers working in the same room (or squad), not via waterfall handoffs. Your team structure should reinforce this coupling.
- Subscription economics punish downtime: Churn caused by reliability failures directly hits MRR. This means your team must treat on-call, SLOs and incident response as core engineering concerns — not as “ops overhead.”
- Conway’s Law applies here more than anywhere: Your software architecture will reflect your team communication structure. If you want a modular, independently deployable product, you need teams that can work independently. Design your team structure first, then let the architecture follow.
Core Roles in a SaaS Development Team
Below are the engineering roles that appear across SaaS development teams, with clarity on where they sit, what they own, and at what stage you typically need them.
| Role | What they own | First needed | UK salary range (2026) |
|---|---|---|---|
| CTO | Technical strategy, architecture decisions, hiring standards, investor/board communication | Day 1 (or as a co-founder) | £100,000–£180,000 + equity |
| VP of Engineering | Engineering org delivery, team health, hiring pipeline, processes, EM management | Series A–B (when CTO needs to focus on strategy) | £110,000–£160,000 + equity |
| Engineering Manager (EM) | People management, squad delivery, hiring, career development, team health | When team reaches 6–8 engineers | £80,000–£110,000 |
| Tech Lead | Technical direction, architecture within squad, code review standards, unblocking engineers | Once squad forms (3–5 engineers) | £75,000–£100,000 |
| Staff Engineer / Principal Engineer | Cross-squad technical leadership, architectural standards, solving the hardest problems | Series B+ (when cross-squad alignment breaks down) | £100,000–£140,000+ |
| Senior Software Engineer | Feature delivery, technical mentoring, design discussions, squad backbone | Pre-PMF; your first hires should be senior | £65,000–£90,000 |
| Mid-level Software Engineer | Feature delivery, scoped tasks, growing toward senior | Once senior engineers are established | £45,000–£65,000 |
| Junior / Graduate Software Engineer | Well-scoped tasks with mentoring; contributes to velocity with support | Series A+ (once mentoring capacity exists) | £28,000–£42,000 |
| DevOps / Platform Engineer | CI/CD pipelines, infrastructure, observability, on-call infrastructure, developer tooling | Seed–Series A; before your first production incident | £55,000–£90,000 |
| Site Reliability Engineer (SRE) | Reliability engineering, SLOs, incident management, capacity planning | Series B+ (when reliability is a customer contract requirement) | £70,000–£100,000 |
| QA Engineer / SDET | Test strategy, automated test suites, release quality gates, regression coverage | Late Seed (after MVP; focus on automation, not manual) | £40,000–£70,000 |
| Security Engineer | Application security, pen testing, compliance (SOC 2, ISO 27001), threat modelling | Series A–B (when enterprise customers require security certifications) | £70,000–£110,000 |
| Data Engineer | Data pipelines, analytics infrastructure, event tracking, data warehouse | Series A (when product analytics become a strategic priority) | £55,000–£85,000 |
| AI / LLM Engineer | LLM integration, prompt engineering, AI feature development, RAG pipelines, evaluation | Series A+ (if AI is core to product, earlier) | £70,000–£120,000+ |
Team Structure by Funding Stage
The right engineering team structure at £500k ARR is not a scaled-down version of what works at £20M ARR — it is a fundamentally different structure with different priorities. Here is how it evolves:
Pre-PMF / Pre-Seed: 2–6 Engineers
Goal: Get something in front of customers fast enough to learn. Everything is disposable.
| Role | Headcount | Notes |
|---|---|---|
| CTO / Technical Co-founder | 1 | Owns architecture, writes code, sets standards. If not a co-founder, this is your first hire — not a mid-level developer. |
| Senior / Full-stack Engineer | 1–3 | Generalists who can cover frontend + backend + basic infra. Avoid specialists until you know what you’re building. |
| UI/UX Designer (optional) | 0–1 | Often a contractor or freelancer at this stage. Many early-stage products are built by engineer-designers. |
What to avoid: Hiring specialists (dedicated frontend, dedicated QA, dedicated DevOps) before you have anything worth specialising around. Premature specialisation at pre-PMF is a runway drain.
Seed Stage: £500k–£2M ARR, 5–15 Engineers
Goal: Accelerate delivery once you have evidence of product-market fit. Start building operational foundations.
| Role | Headcount | Priority |
|---|---|---|
| CTO + 1–2 Tech Leads | 2–3 | Core architecture owners; still writing code |
| Senior Engineers (backend / frontend split) | 3–5 | Feature delivery. Specialism starts to make sense here. |
| First DevOps / Platform Engineer | 1 | High priority — before your first major production incident, not after |
| First QA Engineer (automation-focused) | 1 | Focus on test automation, not manual QA. The ratio you want is more automation coverage, not more manual testers. |
| Mid-level Engineers | 2–4 | Filling out team once senior foundation is in place |
Series A: £2–8M ARR, 12–30 Engineers
Goal: Structured, predictable delivery at scale. Introduce squad model. First people management layer.
| Role | Headcount | Notes |
|---|---|---|
| CTO (+ VP Eng emerging) | 1–2 | CTO moving to strategy; VP Eng may be first hire to take over people management |
| Engineering Managers | 1–3 | One EM per 6–8 engineers; first EM hire is critical — see guidance below |
| Tech Leads (one per squad) | 2–4 | Distinct from EM; still primarily IC (individual contributor) |
| Senior Engineers | 5–10 | Mix of backend-specialist, frontend-specialist, full-stack depending on product |
| Mid-level Engineers | 4–8 | Core delivery layer; need senior mentoring capacity in place first |
| DevOps / Platform team | 2–3 | Moving from single DevOps hire to small team; internal developer platform emerging |
| QA Engineers (automation) | 2–3 | 1 QA per 5–8 engineers is a reasonable ratio at this stage |
| Data Engineer | 1 | Product analytics, event tracking, BI infrastructure |
| Security Engineer (optional) | 0–1 | Critical if enterprise customers are requiring SOC 2 or ISO 27001 |
Series B: £8–25M ARR, 30–80 Engineers
At Series B, the engineering organisation is large enough that cross-team coordination becomes a problem in itself. The focus shifts to:
- Fully autonomous squads that can each deploy independently
- A Platform team providing internal tooling, shared infrastructure, and developer experience
- Staff / Principal Engineers providing cross-squad technical leadership without management responsibility
- An Engineering Enablement function (formal onboarding, internal documentation, architecture review processes)
- A dedicated VP of Engineering freeing the CTO for external-facing strategy
Typical David Sacks ratios that apply at this scale: 1 PM per 5–8 engineers, 1 DevOps per 15 engineers, 1 EM per 6–8 engineers.
Engineering Team Models: Squads, Tribes and Team Topologies
Most SaaS companies eventually adopt some variant of squad-based organisation. The dominant frameworks in 2026 are the Spotify Model and Team Topologies — they solve different problems and are not mutually exclusive.
The Spotify Model
The Spotify Model organises engineers into autonomous cross-functional squads, each owning a product area or user journey end-to-end. Squads are grouped into Tribes (related product areas). Horizontal Chapters (engineers of the same discipline across squads) and Guilds (voluntary interest groups) provide community and standards without hard hierarchy.
- Squad: 6–12 people, cross-functional (engineer, designer, PM, QA), autonomous delivery
- Tribe: Collection of squads working in a related area (40–150 people)
- Chapter: Same-discipline group across squads (e.g., all frontend engineers in a tribe); led by an Engineering Manager
- Guild: Voluntary community of interest across tribes (e.g., security guild, accessibility guild)
When it works well: Series A and beyond, when you have multiple product areas that can be developed in parallel without tight coupling.
When it breaks down: When squads are too interdependent to actually work autonomously. If every squad is waiting on every other squad, the Spotify Model adds organisational overhead without the delivery benefit.
Team Topologies (Skelton & Pais)
Team Topologies is the more architectural framework, focused on how different team types should interact to minimise cognitive load and maximise flow. It defines four team types:
| Team type | What it does | SaaS example | When you need it |
|---|---|---|---|
| Stream-aligned | Owns a continuous flow of work delivering customer value | “Billing squad,” “Onboarding squad,” “Integrations squad” | Your primary squads from Series A onwards |
| Platform | Provides internal services to reduce cognitive load on stream-aligned teams | Internal developer platform, shared auth layer, observability tooling | Series B+ (when stream-aligned teams are duplicating infrastructure work) |
| Enabling | Temporarily helps stream-aligned teams acquire new capabilities, then steps back | Security enablement, accessibility, performance engineering | When you need to embed a new practice without permanently embedding specialists in every squad |
| Complicated-subsystem | Owns an area requiring deep specialist knowledge not widely held | ML/AI team, cryptography, real-time processing engine | Only when the subsystem genuinely requires specialist expertise that would be prohibitive to distribute |
Practical advice: At Seed and early Series A, every team is stream-aligned by default. Resist the temptation to create a platform team too early — it often becomes a bottleneck rather than an enabler before you have enough stream-aligned teams to justify it. A good rule of thumb: build a platform team when you have at least 3–4 stream-aligned teams duplicating the same infrastructure work.
The Hiring Sequence That Matters
The order in which you hire engineering roles has a bigger impact than the specific number of hires. The most common mistakes all follow the same pattern: hiring implementation capacity before you have the architectural foundation to use it effectively.
| Stage | Hire this first | Then this | Common mistake |
|---|---|---|---|
| Pre-PMF | CTO / Senior full-stack anchor | 1–2 additional generalist senior engineers | Hiring 3 mid-level engineers before hiring a senior who can set standards |
| MVP → Seed | First DevOps engineer (infra + CI/CD) | QA automation engineer; 2–3 more seniors | Delaying DevOps until after the first major incident; hiring manual QA instead of automation QA |
| Seed → Series A | First Engineering Manager (when team hits 6–8) | Mid-level engineers to fill squads; second EM when first squad is 8+ | Promoting your best engineer into EM without management training; hiring EM too early (3 engineers) or too late (12+ engineers) |
| Series A → B | Staff Engineer (cross-squad technical coherence) | VP Engineering; Platform team (2–3 engineers); Security Engineer | Not hiring a Staff Engineer and letting architectural drift compound across squads |
| Series B+ | Platform team lead + VP Engineering if not already in place | Principal Engineers; Security Engineering team; Data team expansion | Hiring for headcount targets rather than for specific capability gaps; creating management layers without ICs to manage |
Engineering Manager vs Tech Lead: When to Hire Which
The Engineering Manager / Tech Lead question is one of the most mishandled decisions in SaaS engineering org design. Many companies either conflate the roles (leaving one person burned out trying to do both), promote the wrong person into each, or hire in the wrong order.
| Dimension | Tech Lead | Engineering Manager |
|---|---|---|
| Primary responsibility | Technical quality, architecture, code standards | People health, delivery process, hiring, career growth |
| Time coding | 50–70% | <20% |
| Career track | Individual Contributor (IC) → Staff → Principal | Management → Director → VP → CTO |
| Who they report to | Engineering Manager | VP Engineering or CTO |
| Owns delivery? | Technically yes, managerially no | Yes — accountable for sprint delivery |
| When to split the roles | When a single person is doing both and either (a) architecture decisions are being delayed by meetings, or (b) engineers are not getting regular 1:1s and growth conversations | |
| UK salary (2026) | £75,000–£100,000 | £80,000–£110,000 |
The most common mistake: Promoting your best engineer into an Engineering Manager role because they’re the most respected in the team. The skills required for EM are almost entirely different from Senior/Lead engineering skills. A great Tech Lead who becomes an EM against their will loses both their technical productivity and their job satisfaction. Always ask the individual which career track they want before assuming.
DevOps, SRE and Platform Teams: When to Break Them Out
Most SaaS companies go through three phases with infrastructure and operations:
- Phase 1 — “Everyone does it” (pre-seed to early Seed): Engineers manage their own deployments. Infrastructure is minimal. Cloud consoles are shared. This works until it doesn’t.
- Phase 2 — Dedicated DevOps engineer (late Seed to early Series A): One or two specialists own CI/CD, infrastructure, on-call, and developer tooling. They serve all engineers. This works until the one person becomes a bottleneck.
- Phase 3 — Platform team (Series B+): A dedicated internal platform team builds and maintains the internal developer platform — deployment tools, observability, shared services, infrastructure abstractions. Stream-aligned teams consume the platform without managing infrastructure themselves.
When to make the Phase 2 → Phase 3 transition:
- Multiple stream-aligned teams are each maintaining their own infrastructure configuration independently, creating drift
- Your DevOps engineers are spending more time fielding requests from other teams than building improvements
- Onboarding new engineers to the deployment process takes more than a day
- You have 30+ engineers and the DevOps-to-developer ratio exceeds 1:20
SRE vs DevOps: Site Reliability Engineering is a distinct discipline from DevOps. DevOps focuses on delivery pipelines and infrastructure. SRE focuses on reliability engineering — defining and measuring SLOs, error budgets, incident management processes, and capacity planning. Most SaaS companies don’t need a dedicated SRE function until they have enterprise customers on SLAs and are running at scale where reliability directly affects revenue. If a customer’s contract includes uptime guarantees, you probably need at least one SRE.
Insourcing vs Outsourcing: The Decision Framework
The question of whether to build your development team in-house or use an external agency / offshore team is genuinely context-dependent. The right answer is not always “insource as soon as possible” — but it is usually “outsource for specific, bounded, well-defined work.”
| Scenario | Outsource? | Rationale |
|---|---|---|
| Building the very first MVP before raising seed | Yes, potentially | If the founders are non-technical, a dev agency can build a demonstrable MVP fast. Accept high future rework cost as a trade-off. |
| Validating product-market fit with your first paying customers | No | Iteration speed and institutional knowledge are critical here. Agencies are too slow and too expensive for this phase. |
| Filling a specific short-term skills gap (e.g., mobile dev while you hire) | Yes | Contractors or small agencies can fill well-scoped gaps while you build permanent capacity. |
| Scaling delivery capacity during a sprint push | Yes, with caveats | Works if the work is well-defined and doesn’t require deep product context. Senior contractors embedded in your team work better than agency teams. |
| Core product engineering (ongoing feature delivery) | No | Institutional product knowledge, fast iteration, and roadmap ownership require employed engineers, not external teams. |
| Security audit / pen testing | Yes | External security specialists are expected by enterprise buyers; independence is a feature, not a bug. |
The offshore question: Offshore engineering teams (Eastern Europe, South Asia, Latin America) can work well for SaaS companies that have strong technical leadership in-house, a robust spec and review process, and asynchronous working practices. They work poorly when the bottleneck is product clarity (not coding capacity), when iteration cycles are short, or when the offshore team lacks senior engineering ownership. The time-zone overlap for UK-based SaaS companies is best with Eastern Europe (Poland, Romania, Ukraine) for near-real-time collaboration.
AI Impact on SaaS Development Teams in 2026
The honest picture of how AI is changing SaaS engineering teams in 2026 is more nuanced than either the “AI is replacing developers” or “nothing has changed” camps suggest.
What is measurably changing
- Individual output is higher: GitHub Copilot, Cursor and Claude Code are increasing productive output by 30–50% for well-specified tasks. Engineers who use these tools effectively are delivering more in the same hours — not being replaced, but becoming individually more productive.
- The role of junior engineers is evolving: Boilerplate code generation was previously a primary output of junior developers. AI tools do this well. Junior engineers are now expected to review, evaluate and direct AI output rather than write it from scratch — requiring stronger judgment and code literacy earlier in their career.
- QA teams are shrinking: AI-assisted test generation is reducing the headcount required for test automation coverage. A QA team that previously needed 4 people can often achieve equivalent automation coverage with 2–3 people augmented by tools. Manual QA headcount is contracting faster.
- LLM/AI engineering is a real new role: Building AI-powered features — RAG pipelines, LLM integrations, evaluation frameworks, prompt management — requires a specialist skill set. Companies building AI-native products are hiring AI engineers who understand model behaviour, context windows, fine-tuning, and evaluation. UK demand for this profile is growing significantly.
What has not changed
- Systems thinking and architecture remain human work. AI tools are excellent at generating implementation code; they are poor at system design, trade-off analysis, and understanding the business context that shapes good architecture decisions.
- Senior engineers and tech leads are not less valuable — they are more valuable as directors of AI-assisted engineering teams.
- Headcount per £1M ARR has decreased slightly — companies are hiring 10–15% fewer engineers per ARR milestone than in 2022. This does not mean teams are shrinking; growth is absorbing the productivity gain.
Hiring implications
| Role | AI impact | Hiring implication |
|---|---|---|
| Junior Engineer | High — boilerplate, scaffolding, test writing now AI-generated | Hire fewer; filter for AI tool fluency and judgment over raw coding speed |
| Mid-level Engineer | Medium — well-defined features built faster; review/direction now key | Still a core hire; assess ability to evaluate AI output critically |
| Senior / Staff Engineer | Low impact on role value — increased leverage | Demand growing; one senior can now effectively direct more junior/AI-assisted output |
| QA Engineer | High — test generation largely automated | Hire fewer; shift profile toward SDET (automation engineering) and test architecture |
| AI / LLM Engineer | New role category | Growing demand; UK salary premium £70–120k; assess RAG, evaluation, and LLM ops skills |
| DevOps / Platform | Low to medium — infrastructure still human-owned | Unchanged hiring need; AI-generated IaC code needs review but doesn’t replace the function |
UK Salary Benchmarks by Role (2026)
UK salary data for SaaS engineering roles, based on market intelligence and live job posting data (April 2026). “National” means UK excluding London; London adds approximately 15–25% across most engineering roles.
| Role | Junior / Entry | Mid-level | Senior | Lead / Staff / Principal |
|---|---|---|---|---|
| Software Engineer (Backend) | £28–42k | £45–65k | £65–88k | £90–130k+ |
| Software Engineer (Frontend) | £26–40k | £42–60k | £60–82k | £85–120k |
| Full-Stack Engineer | £28–42k | £45–65k | £65–90k | £90–125k |
| Tech Lead | — | — | £75–100k | £95–130k |
| Engineering Manager | — | £80–95k | £90–115k | — |
| VP of Engineering | — | — | £110–145k | £140–180k+ |
| CTO | — | £90–120k (Series A) | £120–160k (Series B) | £150–200k+ (Series C+) |
| DevOps / Platform Engineer | £30–45k | £50–65k | £65–88k | £88–115k |
| SRE | — | £55–70k | £70–95k | £95–125k |
| QA / SDET | £25–38k | £38–55k | £55–70k | £70–90k |
| Security Engineer | — | £55–72k | £72–95k | £95–130k |
| AI / LLM Engineer | — | £65–80k | £80–110k | £110–140k+ |
Note: Equity is not included in the above figures. At pre-seed and seed stage, equity compensation is a significant part of total remuneration for senior engineering hires — typically 0.5–2% for first engineering employees, 0.1–0.5% at Seed, and 0.05–0.2% at Series A. At Series B and beyond, EMI options schemes are standard for senior engineers and above. Also be sure to read our best SaaS management platforms
Common Structural Mistakes
- Hiring backend engineers before hiring a product lead. Engineers without clear product direction build technically interesting things that customers don’t want. Product clarity precedes engineering headcount.
- Delaying DevOps until after an incident. Every SaaS company that has delayed hiring its first DevOps engineer has eventually paid for it in a painful production incident. By the time you experience the incident, the hiring and onboarding delay means it takes 3–4 months to fix properly. Hire before you need to.
- Conflating Tech Lead and Engineering Manager. These are different careers, different skill sets, and different performance criteria. Treating them as the same role — or promoting into one without asking which track the person wants — consistently leads to attrition of strong engineers.
- Building a platform team too early. A platform team with two or three stream-aligned teams to serve has nothing to do except invent work. Build the platform when the duplication across stream-aligned teams is measurably slowing delivery — not before.
- Hiring for headcount targets rather than capability gaps. “We need to double engineering headcount this year” is not a hiring strategy. Every new hire should map to a specific capability gap in the roadmap. Headcount for its own sake increases coordination overhead without proportionately increasing output.
- Not hiring a Staff Engineer before the architectural debt compounds. At Series A with 3–4 squads, architectural decisions happen independently. Without a Staff Engineer setting cross-squad standards, you accumulate architectural debt that costs 10× more to resolve at Series B. This hire is often delayed because it’s not seen as “delivery capacity” — but it is.
- Hiring junior engineers before you have mentoring capacity. Junior engineers require 3–5 hours per week of senior engineer time for effective development. If you don’t have that senior capacity, juniors either stagnate or leave within 12 months — both are expensive outcomes.
Building Your SaaS Engineering Team?
Getting the structure right before you start hiring saves months of rework and significant cost. Live Digital specialises in placing engineers, tech leads, engineering managers and CTOs into SaaS companies at every stage — from Seed to Series C.
We can advise on the right hire for your stage before you go to market, not after you’ve made an expensive mistake. We work on permanent hires and contract placements across the full engineering function.
Talk to our engineering recruitment team →Frequently Asked Questions
How many engineers does a SaaS startup need?
A pre-PMF SaaS startup can build an MVP with 2–4 engineers. At Seed stage (£500k–£2M ARR), a typical engineering team is 5–12 people. Series A (£2–8M ARR) usually requires 12–30 engineers across 2–4 squads. The right number is determined by your roadmap, not headcount targets — hiring engineers before you have defined what they will build is one of the most expensive mistakes at early stage.
What is the first engineering hire a SaaS startup should make?
If you are a non-technical founder, your first hire should be a CTO or senior full-stack engineer who can set the technical foundation — not a junior developer. If you are a technical founder, your first hire is typically the role that complements your weakest area: a frontend engineer if you are backend-heavy, or a DevOps/infrastructure engineer if you are struggling with deployment. Hiring a mid-level specialist before you have the architecture defined usually creates rework.
When should a SaaS company hire an Engineering Manager?
The right time to hire an Engineering Manager is when you have 6–8 engineers who need coordination, and your most senior engineer (Tech Lead) is spending more than 30–40% of their time on people management instead of technical work. Hiring an EM too early — before you have enough engineers to manage — is an expensive mistake; hiring too late burns out your best technical people.
What is the difference between a Tech Lead and an Engineering Manager?
A Tech Lead is primarily a senior individual contributor who owns technical direction, architecture decisions and code quality — they typically spend 50–70% of their time coding. An Engineering Manager owns people management, team health, delivery processes, and career development — they typically spend less than 20% of their time coding. At early-stage SaaS companies, one person often covers both roles; as teams grow past 6–8 engineers, separating the roles produces better outcomes.
Should a SaaS startup outsource development or hire in-house?
Outsourcing works well for building an initial MVP, specific feature sprints, or expanding capacity during product-market fit validation. It becomes problematic when your product requires deep institutional knowledge, fast iteration cycles, or tight integration between engineering and product decisions. Most SaaS companies transition from outsourced to in-house engineering as they approach or exceed product-market fit — typically at Series A or when they have recurring revenue above £500k ARR.
How is AI changing SaaS development team structures in 2026?
AI coding tools (GitHub Copilot, Cursor, Claude Code) are increasing individual developer output by 30–50% for well-defined tasks. This is changing team composition rather than eliminating roles: fewer mid-level engineers doing routine implementation, more senior engineers and tech leads directing AI-assisted work, smaller QA teams using AI test generation, and growing demand for engineers who can build and integrate LLM-powered features. The net effect in 2026 is that SaaS companies are hiring slightly fewer engineers per £1M ARR than in 2022, but paying more per hire.
What does a SaaS development team look like at Series A?
A typical Series A SaaS development team (£2–8M ARR) has 12–25 engineers organised into 2–3 squads, each owning a product area or user journey. Roles usually include: a VP of Engineering or CTO, 1–2 Engineering Managers, 2–4 Tech Leads, 6–14 Software Engineers (mix of full-stack, backend-heavy), 2–3 DevOps/Platform Engineers, 2–3 QA Engineers, and a Data Engineer. Design typically sits with Product at this stage.