I hear this often. I think it is wrong — and I think the reasons it is wrong are about to become obvious to a lot of people.
The objection assumes that the work of running a service is mostly volume: lines of code, tickets, deployments, documents. Volume needs headcount. But the hard part of running a service has never been volume. It is coherence — knowing why the system is shaped the way it is, what depends on what, and which of today's decisions will still be correct in two years. Volume can be added. Coherence cannot; it can only be preserved, and every additional person you add to a system makes it a little harder to preserve.
Most of the conversation about AI is about substitution: which people it replaces, which tasks disappear. I find the more interesting property to be the other one. AI extends what a single mind can hold and act on. It reads the whole codebase with me. It remembers the decision I made eleven months ago and why. It drafts the migration, the test, the note to a customer, and hands each back for judgment that is still mine.
That is not a smaller version of a team. It is a different shape entirely — one where the constraint moves from how much can be produced to how good the judgment is, which is exactly where I want the constraint to sit.
Which is also why this is not a trick anyone can run. Amplification works on whatever judgment it is given; applied to inexperience it produces confident, plausible, wrong systems faster than anyone can review them. What is in this codebase is thirty-five years of systems development — the accumulated sense of which abstractions hold under load, which shortcuts return as incidents, and what failure looks like in production rather than in theory — with that amplification laid on top. The experience is not nostalgia and it is not credentials. It is the thing that makes the amplified output worth trusting.
One context, undivided. There is no handover, no onboarding, no tribal knowledge held by someone who left. Architecture, operations, pricing, support, and roadmap sit in one head, which means a support ticket can become a design decision in the same hour.
Decisions that cost minutes, not weeks. No alignment meetings, no committee, no negotiated compromise that satisfies everyone and serves no one. When something is right, it ships. When it is wrong, it is reversed before it has calcified into a process.
Infrastructure that grows with the load. I add capacity when demand asks for it, not when a plan from last year says to. The system stays as small as it can be, which is also the cheapest it can be.
A small attack surface, deliberately. Fewer services, fewer integrations, fewer credentials, fewer people holding them. Most breaches are not exotic; they are an unused door someone forgot about. If I have unused doors, I built them.
A company built with investors' money carries an obligation to grow revenue without limit, because the capital that built it expects a return proportional to the risk it took. I carry no such obligation. This service was built with my own time, and it answers to the people who pay for it.
That changes where the money goes. The income this business needs to produce is a number, not a direction. Revenue above that number is not extracted — it returns to the product, as capability customers did not have to ask for and as prices lower than the market would tolerate. The structure points the same way: money spent making the service better is spent before tax, while money taken out is taxed as personal income. Reinvestment here is not a virtue I am performing. It is the arithmetic.
The parts of this system that are hard to copy are hard to copy deliberately. They are what lets a one-person business hold ground against organizations with a hundred times its resources, and for now they stay closed.
They will not stay closed forever. Defensibility exists to fund the work; the work does not exist to protect the defensibility. Once this service reliably covers what it needs to cover, holding the hard parts back stops being self-preservation and becomes hoarding — and I would rather hand them to whoever is building the next thing.
A promise attached to no date is worth nothing, so I will not dress this up as one. It is an intention, not a commitment, and the work stays mine until I decide otherwise. I state it here because it tells you what the defensibility is for: it is a tool, not a purpose, and I do not intend to confuse the two.
A structure this concentrated has one honest weakness, and I would rather name it than have it discovered: everything depends on one person remaining available and competent. I take that seriously. The service is built to be understood by someone who is not me — documented architecture, no undocumented magic, no dependency on knowledge that exists only in my head. Three and a half decades of inheriting other people's systems is a thorough education in what makes a system inheritable. The concentration is a design choice, not an accident, and it is reversible by design.