The short version up front, because I hate articles that make you scroll for the payoff.
We are not a company of one. There are several of us, and I say "we" about all three of the things we're currently working on. What we are is small on purpose, and the purpose is narrow and specific: the company runs alone. No outside capital, no board, no investor who gets a quarterly opinion about headcount, no growth mandate handed down from anybody. That's what "run alone" means here. Not one person doing everything — one company answering to nobody but its customers.
People keep asking when we're going to hire, which is a reasonable question asked at the wrong altitude. The answer isn't a principle. It's a ledger, and the ledger has a credit column and a debit column, and the debit column is longer than people who write about this generally admit. So here's both sides, with the costs stated at the same volume as the case.
What "small" actually buys, and what it is actually for
Right now there are three lines of work running at once.
The first is lab-grown gemstones: a deep partnership with growing factories in China, where our side handles the export trade. That demands real specialist knowledge — not "we also sell gems" knowledge, but the kind where you can say exactly what a certificate proves and, more importantly, what it doesn't. Attached to it is our own-brand storefront, which looked like the simple part and wasn't: product structure and SKUs, a pricing and quoting system, and the part that mattered most and took the longest, which was the writing around the catalogue. Terms. Plain-language explainers of what a lab-grown stone actually is. That storefront is maybe a third engineering and two-thirds explaining things honestly to people who have been told a lot of nonsense.
The second is iHomePage CMS, nine years old. This site runs on it.
The third is a B2B knowledge base on LLMs and RAG — a few months of thinking, now sitting between engineering and being ready to sell, with several customers who have pre-ordered it.
Three businesses at once in a small company is the real ledger entry that "when are you going to hire" is reaching for, and it isn't about headcount. The scarce resource is attention. You can buy hours. You cannot buy an uninterrupted afternoon, because what destroys an afternoon is almost never a shortage of people — it's the arrival of a new person's question.
So the arrangement is unglamorous and mechanical. Mornings go to other people: mail, suppliers, customers, anything that runs on someone else's clock. Afternoons are kept entirely free of meetings, for work that needs a long uninterrupted run. It holds about four days in five. That ratio is the whole argument, and it's also the first thing to break when a company grows — not because anyone decides to break it, but because the calendar fills with things that are each individually defensible.
Staying small is what that afternoon costs.
The strongest argument against my own position
Nine years on a CMS. It started as a drag-and-drop site builder, got rewritten several times as the technology underneath it changed, and only now is the positioning finally getting sharp. Most of that decade went into working out what the product *isn't*.
I'm not going to dress that up. A bigger company would have been forced to answer that question years earlier, and the forcing function would have been exactly the thing we don't have: a board asking what the thesis is, or a burn rate that made nine years of ambiguity financially impossible. Staying small bought the time to be slow. It also permitted nine years of not deciding. Both of those sentences are true about the same nine years, and anybody who tells you only the first one is selling something.
Nobody made me kill it. There was no quarter in which somebody with a spreadsheet said *this line of business has had its run*. The discipline a burn rate imposes on a funded company is real discipline, and it isn't free to go without.
What I'd say in defence is narrower than "patience is a virtue." It's that the product survived long enough for the technology to arrive. Several of the rewrites were only possible because the tooling underneath got good enough, and a company that killed the product in year four to satisfy a board would have been right on the numbers and wrong on the outcome. But I notice this is exactly the argument every founder of every nine-year project makes, including all the ones who turned out to be wrong, and that I can't distinguish myself from them from the inside is the point.
There's a piece of evidence here from the other direction. Calm Company Fund — formerly Earnest Capital, Tyler Tringas's fund, built specifically to finance calm, small, non-venture-scale businesses with a revenue-share instrument instead of equity — paused new investments. Tringas's own public framing was that the thesis absolutely works but the business model does not: management fees on small funds couldn't support the operation. The fund whose entire purpose was financing businesses like mine couldn't finance itself on the same terms. I don't read that as proof the thesis is wrong. I read it as a reminder that structural constraints don't care about your preferences, and no configuration of this escapes arithmetic.
What the people who write about this actually disagree about
There's a whole literature on staying small, and it's much less unanimous than its fans suggest. The disagreements are where the useful information is.
Paul Jarvis wrote *Company of One*, the book most often handed to anybody asking this question, whose argument is that growth should be a decision rather than a default. Worth noting what happened next: Jarvis stopped his *Sunday Dispatches* newsletter after eight years and roughly 35,000 subscribers, deleted his social accounts, and removed the articles from his own site, saying he didn't want to be a personal brand or a known dude on the internet — he just wanted to exist and do his work privately. He's co-founder of Fathom Analytics, which is a company of more than one. The author of the canonical text on companies of one ended up at a small partnership and withdrew from the discourse entirely. I find that more instructive than the book.
37signals is the loudest institutional voice for refusing growth, and the example that most rewards checking. Recent figures put them around 75 to 80 people with roughly ten Ruby programmers; Jason Fried has said their highest headcount ever was 74. And there is one outside owner on the cap table: Jeff Bezos took a minority, no-control stake through Bezos Expeditions in 2006. No venture firms, but not "no outside investors" either. That doesn't make them hypocrites — it makes "stay small" a different claim than it sounds. For them, small means small *ambition about market share*: don't chase every segment, don't take money that comes with a mandate. It does not mean a small team. If you read them as a licence to stay at five people, you are reading a company of 75.
Patrick McKenzie made the most influential case to developers that a small software business is a viable life, and then gave the most useful testimony against it. Writing up 2016, he described selling Appointment Reminder and said he "never felt like I was operating the business to the best of my ability, and was very, very bored with it," that selling brought "an enormous sense of relief," that he was coming off "ten years of being ultimately responsible for literally everything in my companies," and that he hadn't felt as effective as a husband and father as he wanted to. Then he went to work at Stripe. The strongest advocate took a job, and said plainly why. I don't think that invalidates his earlier writing. I think it means the small-business case and the small-business cost were always both true, and he lived long enough to publish the second half.
Pieter Levels represents the genuinely solo end of the genre: a portfolio of products, no venture money, and a consistent preference for automating a problem rather than hiring for it — at one point reportedly moderating a 40,000-member community with bots rather than staff. He's also the clearest case of why this isn't generalisable advice. That model needs products whose operations can be automated nearly to zero. Most businesses aren't that. The export trade isn't that.
Put those together and the real axis of disagreement isn't small versus big. It's *who you are accountable to*, and the honest reading is that everybody is accountable to something. Take venture money and you're accountable to a board. Hire ten people and you're accountable to ten mortgages. Stay small and you're accountable to your own capacity, which is the one creditor that cannot be refinanced.
The costs, at full strength
This is the part most writing in this genre skips or softens, so I want to do it with the same force as the case.
If I'm not there, the thing doesn't run
The bus factor question gets asked dismissively and deserves better. Michael Bromley, who maintains the Vendure e-commerce framework alone, wrote the most honest thing I've read about it: he has around 3,000 commits on the project while the next-highest contributors have about fifteen each, and a 2016 study found ten of the top thirty GitHub projects had a bus factor of one. His point was that the risk is normal and usually just invisible, buried in a dependency graph.
But look at how his example aged. Bromley's illustration was that Express, then at roughly 17 million npm downloads a week, also had a bus factor of one. Express now runs around 87 million downloads a week, and the way it stopped being a bus-factor-one project was not that a second person turned up. It became an OpenJS Foundation Impact Project, stood up a security working group and a triage team, got an external audit done by Ada Logics via OSTIF, and now issues CVEs through OpenJS as a numbering authority. The cure was institutional, not personal. A small company has no institution to hand itself to.
And the obvious fix doesn't fix it. In a Hacker News thread asking companies of one how they ensure business continuity, one commenter proposed the sensible answer — close enough deals to afford an employee — and got the correct rebuttal from a user called jerrre: what if the employee quits, what if you're unavailable and the employee gets stuck, what about the plethora of tasks you can't expect an employee to do, all while adding the complexity of hiring and managing someone. Hiring converts one continuity risk into three and a management job. That isn't an argument against hiring; it's an argument against pretending hiring answers this particular question.
The best answer in that thread came from a commenter called pengo, who ran a one-person shop supplying research-funding software and had a standing backup agreement with an experienced former colleague who could step in if needed — and who, having since sold the business, now provides that same backup for the new owner. That's a real succession plan: a named person, pre-arranged, competent on your stack. It costs almost nothing and it's the one structural answer available at this size.
The worst answer, and the most common, came from a commenter called welder on the retirement version of the question: "My plan is for my company to become obsolete before I want to retire due to the fast-changing tech landscape." That isn't a plan. That's a hope that the problem dies first.
The non-hypothetical versions are in the thread about Bromley's post. One commenter, ZuLuuuuuu, opened with "I am the developer which literally got hit by a bus, AMA!" — survived with many broken bones, three months before he was back at work, and he was the company's only software engineer. Another, GauntletWizard, described joining a company just before its lead engineer was struck and killed by a truck driving to a holiday, after which recovering access to the AWS account took two weeks because it required a paper letter. And jacquesm listed the ways this risk actually materialises, in order: burnout first, then being poached because you were underpaid and undervalued, then chronic illness, then accidents, then death — which he'd seen twice across 200-plus companies in fifteen years.
Burnout first. The thing most likely to take out the single point of failure isn't a bus, it's the workload.
You cannot insure your own absence
If this were an insurable risk, the honest move would be to buy the policy and stop arguing. It mostly isn't.
Business overhead expense insurance exists and will reimburse a disabled owner's fixed business costs — rent, utilities, the lease. Then read the exclusions. One carrier's list rules out "any salaries, fees, drawing accounts or other remuneration" for you, for a close relative, or for any person who is employed to be your replacement. Another common term excludes salaries for anyone hired after you became sick or injured. Benefits typically start after a 30-to-90-day waiting period and run for a capped term, often 12, 18 or 24 months.
The market's position is clear and, on reflection, perfectly rational: it will keep paying your landlord while you're ill, and it will explicitly not pay for someone to do your work. Key person insurance is a separate product, it pays the business rather than the customer, and it doesn't trigger on resignation or burnout at all. No policy anywhere compensates a customer for the thing you didn't ship because you were in hospital. That risk doesn't get transferred. It stays with you — and a portion of it sits with your customers whether or not anybody has mentioned it to them.
There is a ceiling, and it's lower than it looks
The straightforward cost: there are jobs we can't take. Not "wouldn't" — can't. Anything with a staffing floor, anything whose delivery schedule assumes parallel work, anything where the client's real requirement is a team that can absorb one person being out. That's a whole category of revenue that isn't addressable, and no amount of efficiency changes it, because the constraint isn't productivity. It's simultaneity.
The compensating move is to choose work that fits. A commenter in that continuity thread who develops HashBackup alone put it well: a big part of planning a solo venture is choosing something doable by a single person, where a day or two of downtime wouldn't badly hurt customers. Another, who described himself as a company of one for twenty years, said he designs products to be low-maintenance from the start, weighs future maintenance cost into every feature decision, sometimes reinvents a wheel to drop a dependency, and avoids user-generated content because moderation and spam will eat his time. One more, buro9, set the operational bar: "Sometimes you lose motivation for 6 months... and that business should be able to tick along just fine."
That's a real constraint on the product, not just on the calendar. It also happens to produce better software, which is convenient enough that I distrust how pleased I am about it.
Procurement will raise all of this before you do
This one isn't theoretical for us, because the knowledge base is a B2B product. We will be selling to companies, and small-vendor risk is precisely what their procurement function exists to catch.
Past a certain customer size you get a security questionnaire. An Ask HN thread on exactly this opens with a founder describing 100-plus-question assessments arriving from every client above roughly 100 headcount, with no capacity to hire anyone to handle them. The replies are the education. One commenter, the_bear, named the dynamic: people have an unlimited appetite for wasting your time if it's free for them to do so, so publish a standing security document and make them come back with gaps. Another, temikus, warned against believing "the baseless 'SOC 2 equals enterprise customers' spiel" and noted how many startups spend enormous sums on compliance programmes that never unlock proportional revenue. A third, leros, said the unwelcome thing: as a very small company you may not want these customers at all, because they'll also want custom contracts, legal review and 24-hour bug-fix guarantees.
And the buyer's case against us is better than small-company people like to admit. In the thread about refusing to grow into an agency, a commenter called benjaminwootton laid out why he'd rather buy from an agency given the budget: he doesn't have to source and manage individual contractors, a bad team member gets swapped out quickly, there's one throat to choke, and there's at least some institutional knowledge that doesn't live in one head. Every one of those is something a buyer genuinely gets that we cannot offer. A procurement reviewer who flags vendor financial viability and key-person dependency isn't being bureaucratic. They are naming, correctly, the structural weakness of buying from us.
The answerable version is narrow: name the successor, put it in writing, and offer escrow for anything whose failure would strand the customer. That converts "trust him" into a contract term. It doesn't make the risk go away, and a buyer who decides it's too much risk has made a defensible decision, not an insulting one.
What the refusals cost
No ads. No sponsored posts. No affiliate links. No third-party trackers. No comment section. Email is the only way to reach me, because I like quiet.
Every one of those is only available to a company at this size, and I'd rather say that than pretend it's purely a matter of ethics. Each is a revenue line not taken or a channel left shut. A company with payroll to meet and an investor expecting a curve does not get to decline advertising revenue on the grounds that it would make the site worse to read. Not because those people have weaker principles — because they have obligations, and obligations convert principles into negotiations.
That's the clearest thing smallness buys, and the reason the trade is worth making with the debit column as long as it is: the choices stay choices. The refusals aren't a reward for staying small. They're the same decision seen from the other side.
What I'd actually do
If you're weighing this, in this order:
- Decide what you're refusing, not what size you want. Headcount is a symptom. "I will not take money that comes with a mandate" and "I will not fill my afternoons" are decisions you can actually hold; "stay small" is a mood.
- Pick work that survives you being gone for a week. This is a product decision made early and nearly impossible to retrofit. Downtime tolerance, dependency count, whether you've signed up to moderate anything.
- Name your successor in writing. One competent person who knows your stack and has agreed to step in. It's the single highest-value, lowest-cost thing on this list, and the overwhelming majority of small operations haven't done it.
- Assume burnout, not the bus. It's the failure mode that actually fires. Protect the schedule as infrastructure, not as a perk, and notice that four days in five is a number you can check rather than a feeling.
- Read the insurance exclusions before you rely on insurance. Overhead expense cover will pay your rent and will not pay your replacement. Know that before you need it.
- Tell B2B buyers the truth about key-person risk, early, with the mitigation attached. Named successor, escrow where it matters, and a standing security document so the questionnaires cost you once instead of every time. Buyers who then walk away were going to walk away later and more expensively.
- Re-make the decision, out loud, about once a year. The failure mode of staying small isn't that it's wrong. It's that it stops being a decision and becomes a habit, and a habit can run nine years without anyone asking it to justify itself.
After close to thirty years of this, what strikes me isn't that small is better. It's how much of the public argument about it is conducted by people who are either selling the idea or have quietly stopped doing it. The case for staying small is real, and the bill is also real, and it arrives as a single point of failure you can't insure, a ceiling you can't lift by working harder, a procurement objection you can only partly answer, and the absence of anyone whose job it is to tell you that nine years is long enough.
I'd still rather pay it than owe someone a curve. That's a preference, not a prescription — and it's one I think you should only hold if you can recite the price without flinching.