The instinct when a SaaS is moving slowly is to add people. Sometimes that’s right. Often it makes things slower, for a reason that’s arithmetic rather than cultural: communication paths grow faster than headcount does. Three people have three; eight people have twenty-eight. Every one of those is a place where context has to be transferred, and transferring context is expensive.
That’s the case for staying small. It isn’t the whole case.
What small teams are genuinely better at
- Deciding. Two people can change direction over lunch. Eight people need a meeting, and the meeting needs a document.
- Holding the whole thing in their heads. When one person understands the product, the code, and the customers at once, connections happen that would otherwise need three meetings to discover.
- Iterating during uncertainty. Before product-market fit you’re mostly running experiments and discarding them. A large team turns discarded experiments into wasted salaries and sunk-cost arguments.
- Surviving. A team of two needs a fraction of the revenue a team of ten does, which buys the most valuable resource a startup has: more attempts.
- Not needing process. Every coordination mechanism — standups, sprint planning, RFCs — is overhead that exists to compensate for people not sharing context. Small teams get that for free.
What small teams are genuinely worse at
Being honest about this matters, because “stay small” has become an ideology:
- Breadth. Someone has to do support, sales, infrastructure, design, and content. All of it will be done adequately and none of it excellently, and the founder becomes the bottleneck on everything.
- Depth in specialised areas. Security, compliance, data engineering, complex design systems — genuine expertise you can’t improvise past.
- Resilience. One person leaving, burning out, or getting sick can stop a two-person company entirely.
- Parallel work. Some things genuinely can be done simultaneously, and a small team simply can’t.
- Enterprise motion. If your buyers demand SOC 2, procurement processes, and a named account manager, that’s headcount, not hustle.
The real variable isn’t size — it’s stage
The question “small or large?” has a different answer depending on what you’re doing:
Searching for product-market fit → stay small. You’re running experiments, and most will fail. Extra people multiply the cost of each failed direction and add inertia exactly when you need to turn quickly. One or two people who can build and talk to customers is close to optimal.
Scaling something that works → add people deliberately. Once you know what to build and who buys it, parallel work has real value and the coordination cost is worth paying. This is when the constraint genuinely becomes hands rather than clarity.
The failure mode is doing these in the wrong order: hiring to find product-market fit, which mostly buys you more expensive uncertainty.
Where to add the first people
For a SaaS moving from one founder to a small team, the highest-leverage additions are usually:
- A second builder who overlaps with you enough to review and disagree, and differs enough to cover your weak areas.
- Someone who owns distribution. The most common gap in technical founding teams, and the one that most often decides the outcome. Building isn’t usually the constraint — being found is.
- Support, earlier than feels justified. It’s the first thing to consume all your time and the first place customer truth accumulates.
Notice what’s not on the list: a manager, or a specialist for something you do once a quarter.
The alternative to headcount
Before adding a person, it’s worth asking whether the work can be done without one. Three options that often beat a hire at small scale:
- Buy it. A tool that solves the problem costs a fraction of a salary. Most early-stage “we need someone for X” is really “we need a system for X” (the marketing stack every SaaS needs).
- Contract it. Specialised, bounded work — a security review, a design system, a migration — is often better bought as a project than as a person.
- Get other people to do it on commission. This is the underrated one. Distribution in particular can be extended without headcount: affiliates, creators, consultants, and agency partners each carry your product into rooms you’d otherwise need salespeople for, and they’re paid from revenue they generate rather than from runway.
That last option is genuinely a staffing decision, not just a marketing one. A partner program lets a two-person company have a distribution footprint that would otherwise require several hires — and with usage-based pricing the operating cost doesn’t climb as the channel succeeds (the comparison). When to start one is earlier than most founders assume.
Signs you’re too small
- The founder is the bottleneck on every decision, and things queue behind them.
- Support consumes so much time that nothing ships.
- You keep deferring a whole category of work — security, design, marketing — indefinitely.
- Everyone is at capacity, has been for months, and the product is working.
Signs you’re too large
- More time coordinating than building.
- Roadmap decisions need a meeting to make and a document to explain.
- People are busy on work nobody can trace to a customer.
- You added process to fix a communication problem created by adding people.
The practical answer
For most SaaS before real traction: stay as small as you can stand, and buy or partner your way out of the gaps rather than hiring into them. After traction, add people deliberately against a specific constraint you can name — not against a general feeling of slowness.
And be honest about which problem you actually have. Slowness caused by unclear direction gets worse with more people; slowness caused by genuine capacity limits gets better. Those look identical from the inside and have opposite fixes. If you’re not sure, the development mistakes post covers how to tell.
FAQ
Is a small team better for building a SaaS?
Before product-market fit, usually yes — small teams decide faster, need less revenue, and waste less on directions they abandon. After you know what works, added headcount starts paying off.
How many people do you need to build a SaaS?
One or two can build and launch a SaaS. The practical constraint is usually distribution rather than development, which is why a second person who owns getting customers often matters more than a second engineer.
When should a SaaS startup start hiring?
When you can name the specific constraint the hire removes and the product direction is stable. Hiring to find product-market fit generally buys more expensive uncertainty rather than speed.
More team and growth strategy is in the growth & pricing hub.