How to keep a SaaS under 20 people as it grows

When revenue goes up, the default story says hire. More customers, more tickets, more features, more people. Soon you have titles, standups, and a chart that looks like a bigger company. You still have the same product. You just pay more for it.

Software is supposed to scale without a matching headcount. One person can serve thousands if the product is self-serve, the price is clear, and the work that used to need a human is done by code. Indiecity is for one person or a team under twenty. That line is the point of this guide: grow the business without pretending you need a fifty-person org.

Growth is not a hiring plan

Headcount is not a trophy. It is a fixed cost that shows up every month whether the month was good. VC-backed companies hire ahead of pain because the pitch deck needs a department for every fear. You are not running that game unless you chose it on purpose.

Busy is not the same as understaffed. Every company wants to do more than it can. Your backlog is not proof you need a new role. It is proof you have more ideas than time. That is normal.

The trap is acting like a bigger company. You hire a Head of X because other startups have one. Then you invent work so that person is busy. Jason Fried and David Heinemeier Hansson have said for years that hiring people you do not need, then giving them work that does not need to exist, is how small companies get slow.

Let software take the load first

Before you open a role, ask what the product should own. Billing changes. Cancellations. Password resets. Status. Onboarding. Feedback boards. If a human still does those by hand in 2026, you are paying someone to run a queue the product could clear.

Pieter Levels has described a solo setup built around that idea: one founder, zero employees on payroll, Stripe for money, self-serve billing and refunds, scripts on a schedule for work humans used to do, and a public board for bugs and feedback. His aim is extreme (full automation and very high margins). You do not have to copy the whole stack. You do have to stop hiring for tasks the product can finish.

In February 2026 he put the same rule in a short list: automate anything you do more than twice; cron jobs beat employees for that class of work. That still holds. If the same ticket arrives every day, ship a fix or a self-serve path before you interview for support.

Hire when it hurts, not when you are curious

REWORK’s rule is plain: hire when it hurts. Do the job with who you have. When you cannot get to the work the business truly needs, and that pain lasts, then hire. Do not hire because a spike of tickets felt bad for a week. Do not hire because a good resume appeared in your inbox.

We don’t hire in anticipation of pain. We hire when we feel the pain.

Fried also separates two fixes. Sometimes the answer is a person. Sometimes the answer is fewer projects. If quality is slipping because you are building three products at once, a new hire does not fix the choice. Double down on the product that pays. Cut the work that is optional.

David’s add-on matters for small teams: look at the moving average of hurt, not a hot afternoon. You are hiring someone for most of a year. Ask whether you have most of a year of real work for that seat. If not, you will invent process so they stay busy, and process is how under-twenty companies start to feel like fifty.

Cut scope before you add seats

Headcount pressure often comes from product ambition, not from customers. Every feature creates more support, more bugs, and more design work. Ship less, and fewer people can run the product.

Shape Up is how Basecamp keeps shipping without endless projects. Six-week cycles. Shape the work before a team builds it. Decide how much time the idea is worth, then stop when that time is up. When a project runs over, the default is not more people and more months. The default is stop and rethink.

Their build unit is tiny on purpose. On the 37signals podcast they describe the standard feature team as two people: one designer, one programmer, from pitch to live. You do not need that exact pair. You need the lesson. Small batches of work do not require a department. They require a time box and someone who will ship.

If you are solo or three people, Shape Up’s own appendix says throw out most of the ceremony. You still pick the work, time-box it, and ship. You do not need their full ritual to stay small.

When the big-team path fails

Sahil Lavingia built Gumroad, raised millions, and staffed for a unicorn path. Growth stalled. The Series B math did not work. In his public essay on that failure, he writes that he laid off 75 percent of the company, then shrank from twenty employees toward a skeleton crew so the product could stay alive for creators.

The money makes the point. In June 2015, monthly revenue was $89,000 with operating expenses of $364,000. A year later, revenue was $176,000 with operating expenses of $32,000 and a positive net profit. Same product family. Different headcount. Creators kept getting paid because the company stopped staffing for a story that was not true.

You do not need to live that crash to learn it. If your plan only works at fifty people and a big raise, you are not building an under-twenty SaaS. You are running someone else’s company.

What a team under twenty actually needs

Under twenty is not a magic org chart. It is a limit on how many people you have to keep in your head. Most of the seats that matter still look like this:

• Someone who can ship the product (you, a co-founder, or a strong generalist engineer).
• Someone who can talk to buyers and close (often the same person early on).
• Someone who can answer customers when the product fails them (often shared until volume forces a split).
• Specialists only when one skill is the bottleneck for months (design, infrastructure, compliance for a real buyer requirement).

What you usually do not need yet: a full marketing department, a sales ladder, a product manager for every squad, an in-house lawyer on payroll, or a manager whose job is meetings. If you hire someone before there is work, the empty hours fill with process. Process then taxes everyone else.

Prefer generalists who can finish a loop. A person who can ship a feature and write the help article beats two people who each own a slice and wait on each other. Communication cost grows faster than headcount. That is why twenty is already a lot if everyone is full-time on the same product.

How to absorb growth without a hiring spree

When usage rises, try these moves in order before you open a role.

1. Raise price or kill the free tier that creates support without revenue.
2. Ship the top three help articles your inbox already wrote for you.
3. Add self-serve billing, plan changes, and cancellation.
4. Delete features nobody pays for. Every screen you remove is a ticket you never answer.
5. Put hard limits on custom work. One-off projects force you to hire later.
6. Automate the task you repeated this week. Script first, person second.
7. If it still hurts for months on work the business must do, hire one person with one job.

Price is a staffing tool. Higher price usually means fewer low-fit customers and more room to serve the ones who stay. Cheap plans can force you to hire just to answer people who were never going to pay enough for the cost of their tickets.

A simple headcount test

Before any hire, write four lines:

1) The work that is failing: [specific job, not a feeling].
2) What we tried without a hire: [scope cut, automation, docs, price, stop saying yes].
3) How long the pain has lasted: [weeks or months, not days].
4) The one job the new person owns in their first 90 days: [outcome you can see].

If you cannot fill those lines, you are hiring because you are anxious. If you can fill them, hire slowly, pay well, and keep the rest of the team small so that person has real work, not a fake department to manage.

What to stop doing

• Hiring so the company looks serious on a landing page.
• Opening five roles because a competitor’s about page lists five departments.
• Keeping a free plan that costs more in support than it teaches you.
• Building a roadmap that assumes three new engineers next quarter.
• Adding managers before you have enough makers to need coordination.
• Saying yes to enterprise custom work that only works with a services team.
• Treating headcount as proof of progress instead of revenue and retention.

Stay under twenty on purpose

Under twenty is a ceiling you choose. It forces software to do the scaling. It forces you to cut work that does not pay. It keeps you out of meetings that exist only because the calendar is full of people who need meetings.

Levels shows the floor can be one person with automation. Gumroad’s rebuild shows a product can survive and profit after the unicorn staffing story dies. Fried and DHH show you can wait until it hurts, shape work so two people can ship, and refuse roles that invent complexity.

If you are running that kind of company and you will put your name on it, send us the story. When the product is real, put it on the map. You can join Indiecity while you stay small on purpose. Community is not a substitute for the hard call: do not hire the org chart you saw on someone else’s Series B announcement. If the first seat is still ahead of you, start with when to hire your first employee.

Grow the product. Keep the team a size you can still know by name.