55 Features a Month: How a 4-Person Team Ships Like a 40-Person One

Last February, our 4-person engineering team shipped 55 features in a single month.

I know how that sounds. At iBanFirst, building a core banking system took me 2.5 years. At Qonto, I built equivalent scope in 9 months. Even at Qonto's pace, four people shipping 55 features monthly would have been fantasy.

What changed: the economics of building software shifted, and most companies haven't noticed.

The Numbers

We classify everything we ship:

• Kaizen. Small improvements. A button moved, a query optimized. Hours, not days.
• Feature. Net-new functionality. Something users couldn't do before.
• Improvement. Refactors and infrastructure. Work that makes next month's features cheaper. November 2025: 27. December: 33. January: 41. February: 55.

That's not a spike. It's compounding. Each improvement lowers the cost of the next feature. Each Kaizen removes friction. The system accelerates because it was designed to.

The Coordination Tax

I've managed engineering teams from 5 to 50 people. Most headcount is coordination cost. Standups, alignment meetings, Slack threads about Slack threads, PRs queued behind reviewers stuck in other PRs.

A 40-person engineering org often has the effective output of 8 people actually building.

With four engineers, there's nowhere to hide. You ship or you don't, and everyone knows by Friday.

The New Build-vs-Buy Equation

AI doesn't write our code. It collapses the gap between knowing what to build and having it built. That distance used to be days. Now it's hours.

The deeper shift: things we would have bought, we now build. A third-party integration that meant a week of evaluation and implementation? We build our own in a day. It fits our architecture, we own the code, and we carry one fewer vendor.

This changes the calculus on team size. Four engineers at 5x output on the right tasks don't need 36 colleagues. The multiplier isn't uniform. AI doesn't help with system design or debugging race conditions at 3 AM. But for the 60% of work that's translating clear intent into code, it's a genuine force multiplier.

What Breaks

I'd be dishonest not to say what this pace costs.

Documentation falls behind. Fifty-five features a month creates documentation debt nobody has time to repay. We're behind on this. QA surface area grows faster than coverage. No QA team means engineers test their own work, and at this velocity, things slip through. Nothing catastrophic, but the tension is real.

Sustainability is a knife's edge. This pace holds because the work itself is efficient, not because people grind 80-hour weeks. The moment it tips from "effective" to "overworked," the engine seizes. I watch for that constantly.

Velocity as Moat

In fintech, everyone accesses the same banking partners, the same regulators, the same market data. The differentiator is learning speed. And learning requires shipping.

Every feature is a hypothesis tested. At 55 per month versus a competitor's 5, that's 660 experiments a year against 60. The gap doesn't close. It compounds.

I built iBanFirst's core banking in 2.5 years, then Qonto's in 9 months. The difference wasn't just experience. It was having strong opinions on every architectural decision because I'd already made each one wrong. Velocity accumulates from reps. Reps come from shipping.

The Classification System

Most teams count "features shipped" as one number, no texture. We track Kaizen, Features, and Improvements separately because they serve fundamentally different functions.

Kaizen keeps the product sharp. Without it, small annoyances compound until users leave. Features drive growth, the reason someone signs up or upgrades. Improvements invest in future speed. Skip them and you decelerate gradually, then suddenly.

We target roughly 40% Kaizen, 35% Features, 25% Improvements. All Features and no Improvements means building on a crumbling foundation. All Improvements and no Features means admiring your architecture while the market moves on.

9 Months vs. 2.5 Years

People ask how Qonto's core banking took 9 months when iBanFirst's took 2.5 years.

I'd already made every mistake. I knew which abstractions would hold under load and which would crack. The team was four people who'd each built something comparable. And we said no to everything outside the core. No nice-to-haves, no "while we're at it." Just the engine.

That same discipline defines what we're building at Well. Small team, strong opinions, high velocity. The constraint isn't headcount. It's clarity.

The Widening Gap

The divide between teams using AI-augmented development and those that aren't will define the next five years of software. Not because AI is magic. Because velocity compounds, and compounding is unforgiving to latecomers.

At Well, we're 12 people. Four engineers. We ship more than teams ten times our size, and the rate is still accelerating.

The question isn't whether small teams can outship large ones. They already do. The question is whether large teams will adapt before the gap becomes irreversible.