The Resourcing Question Nobody Is Asking
We're rebuilding Rapid Next with a team size that would have been impossible to justify two years ago. The math changed — but only if you ask the right question.
Six months ago I made a headcount decision for Rapid Next that I couldn't have made two years ago.
We're doing a complete platform rebuild — software used by 1,800+ businesses across DACH, 35+ years of product history, next-generation architecture. The traditional answer for a project like this: hire up. More engineers, more QA, more product managers. A project of this scope, under the old model, would have required a team significantly larger than the one we assembled.
We didn't build that team. We built a different one.
The Rapid Next team was designed around AI tooling from day one. Not as a cost-saving measure and not because talent was unavailable. Because the output rate per person, when the workflow is genuinely redesigned around AI, is fundamentally different from what it was before.
That's a specific claim. Let me be precise about what I mean.
Speed is not the point
When people talk about AI productivity, the conversation usually lands on speed. GitHub's research puts it at 55% faster task completion with AI assistance. That number is real and it matters, but speed is not what changed my headcount decision.
What changed is scope.
Speed means the same person does the same things faster. Scope means the same person can take on a category of work they previously couldn't — because the parts of that work that required either volume or specialized knowledge can now be handled differently.
When a product engineer can generate a comprehensive test suite in the time it used to take to write one test, the question isn't "how much faster is she working?" It's "what can she now take on that was previously outside her bandwidth?" That's a scope question, and the answer to it is what reshapes a headcount model.
For Rapid Next: specification work that used to require dedicated resources is now embedded in the product workflow. Documentation that lagged six weeks behind the build is now produced in parallel. Edge case analysis that historically got cut for time is now part of the standard process. The team isn't working faster — it's doing things that used to require additional headcount.
Why smaller companies have the structural advantage
There's a version of this argument that applies to large enterprises, but the leverage is genuinely higher for smaller organizations.
I call it the Leaner Stack Paradox: smaller companies have a structural AI advantage that larger ones can't easily replicate. Fewer legacy systems means fewer integration constraints. Faster decision-making means new workflows get adopted before the old ones calcify. Less coordination overhead means the time between "we should try this" and "this is now how we work" is measured in days, not quarters.
The companies that will feel this most acutely are mid-market software businesses — exactly the category where Rapid Data competes. They're large enough to have meaningful scale but small enough to redesign how they work without a multi-year change management program.
The window where this is a competitive advantage is finite. As tooling matures and adoption spreads, AI-native workflows will become table stakes rather than differentiators. The companies that redesign now will have a year or two of compounding before the gap closes.
The question that changes the answer
Most resourcing decisions for product teams follow the same process: scope the project, estimate velocity, calculate headcount needed to hit a timeline. The inputs to that calculation have changed, but most teams are still using the old inputs.
The question being asked: "How many people do we need?"
The question that should be asked first: "What does this team look like if AI is embedded in every step of the workflow?"
These questions produce different answers. The first question anchors on a historical baseline — here's how long things used to take, here's how many people we used to need. The second question starts from a different baseline and works forward.
For Rapid Next, asking the second question gave us a team model we wouldn't have reached through the first. And the output rate from that team is what I'd expected — not because we're working harder, but because the workflow is different.
What this means for the next hire
I'm not arguing against hiring. The Rapid Next team will grow as the product grows. But the next hire decision, for any product team, is worth pausing on before it becomes automatic.
Before adding headcount, one question: have you redesigned the workflow for the team size you already have?
If the workflow still assumes pre-AI baselines — if engineers are still writing tests manually, if documentation is still a separate workstream, if QA is still a bottleneck that a new hire would unblock — then the new hire will absorb into the old model. You'll get marginal additional output rather than a structural improvement.
The headcount answer changes when the baseline assumption changes. Get the baseline right first.
If you're making a resourcing decision right now: are you staffing for the workflow you have, or the workflow you should have?