The neighborhood shop
Why this stays small on purpose, and what that means for the people who work with it.
A reasonable skepticism about a one-person software practice is structural. If everything depends on one person, what happens when that person is on vacation, oversubscribed, or simply not interested in the kind of work the relationship was built around? What happens in year three, when the practice has either grown into an agency the buyer didn’t sign up for or stayed small enough that it can’t keep up? Is this even the kind of thing that lasts?
The right frame for the answer is not a software company. It is a neighborhood auto shop.
The auto shop
The mechanic owns the shop. Does the work. Has twenty years of judgment. Stakes a reputation on every job. Customers come from word-of-mouth and proximity, not national ad campaigns. Pricing is fair — not cheapest, not fanciest. The shop stays small on purpose: two bays, three mechanics, a front-of-house. That modesty is a feature, not a failure. Some shops specialize — European cars, fleet, motorcycles — and the specialization deepens trust rather than narrowing it.
The map onto a software practice is close. Owner-operator with deep craft. Personal accountability. Honest pricing. Sustainable scale. Room for specialization. The same posture transfers cleanly because the underlying offer is the same: a real person accountable for a specific kind of work, working at a scale where the relationship and the work can both hold up over years.
Where the analogy breaks down — in the buyer’s favor
There are four ways the analogy is wrong, and all four make the software version structurally more durable than the auto shop it borrows from.
- No geography ceiling. The auto shop is bounded by who can drive there. A software practice is not. The neighborhood is cultural and relational rather than physical. The internet is the zip code.
- No physical capacity ceiling. A shop is gated by bays and lifts. A software practice is gated by attention. Adding a second mechanic doubles rent and tools. Adding a second engineer mostly just adds salary. The unit economics are dramatically better.
- No depreciation, no consumables. A shop’s value lives in physical assets that wear out. A software practice’s value lives in code, relationships, and reputation — which compound. A retainer client is more valuable in year three than in year one, because the practice understands the business better and has accumulated history with its infrastructure.
- Recurring revenue is structurally easier. The auto shop’s recurring revenue is “come back when something breaks.” A software retainer is small, scheduled, and aligned. The incentive runs in the right direction — keeping things running smoothly rather than waiting for them to fail.
The posture is borrowed from the shop. The economics are better than the shop’s. That is the version of this practice that survives.
Two failure modes
Getting the trajectory wrong is the easiest mistake to make, and there are two ways to get it wrong. They pull in opposite directions.
Built around the person too tightly. Everything is “the engineer personally touches your code.” The practice is an income, not a business. Bus factor of one. No real vacation. A retainer client who bought “this specific person” rejects “this person’s employee” the first time it matters. The ceiling is whatever capacity one person can sustain, and there is no path to leverage. That is a job, not a business — and it is fragile in exactly the way a buyer should worry about.
Built like an agency from day one. The practice brands as a studio, implies a team and a process before either exists, and starts competing with actual agencies on a dimension where it has no structural advantage. The wedge — an experienced senior engineer who personally builds the thing — gets thrown away to chase a category that already has incumbents. That is a worse version of the agency the buyer was already priced out of.
Both are real failure modes. The right shape is the path between them.
Joe’s Garage
Think of “Joe’s Garage.” Named after Joe. Joe is probably there. But Joe can hire Mike, and the customer doesn’t feel betrayed when Mike works on their car — because the brand was about quality and relationship, not literally about Joe’s hands.
The practical version, applied to a software practice:
- Brand around the offer, with the operator prominent in the early version. First-person language now, without promising to stay solo forever. When the work shape changes, the language changes. A website is not a charter.
- The offer shape transfers. Discovery, build, operate. That structure works for one person. It works for three. The package isn’t “this specific engineer.” It is custom software, built fast, kept running, with a real person accountable. That framing scales without becoming an agency.
- Accountability stays with one person; execution can distribute. The customer’s relationship is with the operator. Over time, the operator may sit alongside another engineer who handles part of the execution. The promise — quality, continuity, a real person who knows the system — doesn’t change with that.
The transition from solo to small team should feel unremarkable to clients, because the promise was never one specific pair of hands. It was quality, accountability, and continuity.
What this means in practice
In the early version of this practice, the person who runs the engagement is the same person who builds the system. That is the wedge. It is what differentiates the work from an agency at five times the price and from a freelance platform at half the quality.
In a later version — year three, year five — the practice may be a few people. The accountability relationship, the person on the hook for the system and available when it matters, doesn’t transfer to a different shape just because the team has grown. Hiring a second engineer changes who types. It doesn’t change who answers the phone.
That is the structural answer to the bus-factor question, and it is the structural answer to the will-this-still-exist-in-three-years question. The shop is small on purpose. It intends to stay small. Small here means a handful of people, not a single point of failure.
The realistic shape
The realistic, scaled version of this practice is not an agency and not a single freelancer. It is a real small business with real margins, run sustainably from one city. Roughly: one to two additional engineers, twenty to forty retainer clients on modest recurring engagements, a handful of active build engagements at any given time, with occasional larger projects layered on. That is enough to be durable, enough to take a vacation, enough to have colleagues rather than just clients — and small enough to preserve the thing the buyer was hiring in the first place.
The version of this practice that gets to that shape is the version of this practice the original buyer keeps choosing. The version that doesn’t is the version that collapses one of the two failure modes — either because the operator could not sustain it solo, or because scaling traded the wedge for incumbency on someone else’s terms.
The auto shop analogy is not a marketing flourish. It is a deliberate posture about what this is for, what it will and will not become, and how the relationship is supposed to hold up over years.
The point
The skepticism a buyer has about a one-person practice is correct: it is fragile if it is built fragile. The structural answer is not a promise to stay solo forever. It is a commitment to a specific shape — a small shop, branded around the offer, with accountability that does not move when the team grows. The shop stays small on purpose. That is the feature.