The headcount trap: why I want my AI founders to stay small

A founder I backed last year called me in May, a little embarrassed, to tell me he had not hired the team we discussed at the seed round. The plan on the deck had him at fourteen people by mid-year. He was at five. Revenue was up four times over the same period. He apologised, as if the gap between the plan and reality was a confession.

I told him it was the best news he had given me all quarter.

This is a conversation I now have constantly, so here is the long version. I think most AI founders are about to make a mistake that the last decade of startup orthodoxy trained them to make, and the cost of that mistake has gone up sharply in the last eighteen months.

The old reflex

For fifteen years, the standard move after a raise was to convert the cash into headcount as fast as you responsibly could. The logic was sound for its time. Software took a lot of people to build and operate, and a growing company needed a growing org. Investors, mine included, treated a hiring plan as proof of ambition. A founder who raised €4M and stayed at six people looked like they lacked the nerve to scale.

That reflex is now actively dangerous, and the people who hold onto it are going to spend a lot of money learning why. The cost of building has collapsed. A competent team of three can stand up a usable product in six weeks, and that number keeps shrinking. The work that used to require a department now requires a person with the right tools and the discipline to use them. When the cost of the output drops by an order of magnitude and the org chart does not, you do not get a more ambitious company. You get a slower, more expensive, more confused one.

What a big team actually costs

Founders price headcount as salary. That is the small part of the bill.

The real cost of every hire is coordination. The fourth engineer does not just cost their salary, they cost the meetings, the context-sharing, the code review, the onboarding, the slack threads, and the slice of the founder's attention that now goes to managing instead of building. Add enough people and the founder stops being a builder and becomes a manager of builders, usually before they wanted to and before they were any good at it.

I watch this happen across the portfolio. A team of five that ships every day raises a round, hires to twenty over two quarters, and ships every two weeks instead. They added fifteen people and lost velocity. Nobody planned it. It is just what coordination overhead does when you scale a team faster than you scale the systems that let a team work.

There is a second cost that is harder to see. A big team early commits you to a shape. Twenty people is twenty sets of expectations, twenty career paths, twenty reasons not to kill the thing they were hired to build. Pivoting a company of five is a weekend conversation. Pivoting a company of twenty is a layoff. In a market moving this fast, the option to change your mind cheaply is worth more than almost anything those people would do.

Why this is sharper for AI companies

Two things make the headcount trap worse for AI-native companies specifically.

The first is that the leverage per person is genuinely higher here than anywhere I have seen. I run a fleet of agents that handles a real chunk of my own operating work. The point is not that I am clever. The point is that one person who builds the right tooling can now cover ground that used to need a small team, and the founders I back can do the same inside their own companies. The data pipeline, the internal reporting, the first layer of support: a lot of it can be run by a few people with good systems instead of a floor of hires. Founders who staff those functions the old way are paying for capacity they could have built once and run for the cost of inference.

The second is churn in what the company even is. AI products are still finding their shape. The thing you are building in June is often not the thing you build in December, because the model got better, or a category collapsed, or a customer pulled you somewhere you did not expect. A small team can follow that. A large team resists it, because every person you hired is, quietly, a vote for the company staying the way it was when they joined.

The questions I actually ask now

When a founder tells me they are about to hire, I ask three things, in this order.

Is this role doing work, or absorbing work the founders should still be doing themselves? The first salesperson, the first ops hire, the first support lead: these often get hired to take a job off the founder's plate that the founder has not finished learning yet. If you hand off customer conversations before you understand your customer, you are not delegating, you are going blind. Stay in the seat until you could write the manual. Then hire someone to run it.

Can a system do this instead of a person? Not always. People are not interchangeable with tooling, and pretending otherwise is how you end up with a brittle company and a burned-out founder. But the honest answer is "yes, partly" far more often than founders want to admit, and the partly is usually the boring, repetitive eighty percent that a hire would have spent their first year doing anyway.

What does this hire commit you to that you cannot easily undo? Every senior hire is a strategic bet with a human attached. If the bet is wrong, you have a person, a relationship, and a real cost to unwind. Hire when you are confident enough in the direction to take on that weight. Not before.

Small is not the same as understaffed

I want to be precise, because this argument gets misread. I am not telling founders to run themselves into the ground with too few people. I have watched that failure too, and it is just as expensive in a different currency. A team of four doing the work of twelve, with no slack, no rest, and no redundancy, breaks in month seven exactly the way an athlete who never takes a recovery week breaks. The point is not fewer people for its own sake. It is the right people, later than the deck says, with systems doing the work that systems can do, so that the people you do hire are working at the top of their judgment instead of the bottom.

Lean done well feels calm. Everyone knows what they own. Decisions are fast because there are few people to align, and the founder still touches the product. Lean done badly feels frantic, and the fix for frantic is not always another hire. Sometimes it is better systems. Sometimes it is saying no to a customer. Sometimes it is the founder finally building the tool they have been avoiding for three months.

The number on the deck

Here is what I tell founders to do with the hiring plan on their deck. Keep it. It was useful for the raise, it shows you have thought about the shape of the company. Then treat every line on it as a hypothesis to be disproven, not a commitment to be honoured.

For each role, before you open the search, ask whether the work is real yet, whether you have learned it yourself, and whether a system could carry the repetitive part. Most of the time you will hire anyway. But you will hire later, for a sharper reason, into a company that knows exactly why that person is there. And every quarter you stay smaller than the plan said, while the numbers go up, is a quarter of optionality that money cannot buy back.

The founder who called me in May, embarrassed to be at five people instead of fourteen, has the best margins in my portfolio and the fastest shipping cadence. He is not behind. He understood something most of his peers have not. The plan was never the point. It was a forcing function for thinking clearly about what the company actually needs. Hold yourself to that, and the headcount takes care of itself.