Why one developer is sometimes the wrong hire
When a business decides it needs software built, the default move is to hire a developer. Singular. It’s the obvious budget decision, and sometimes it’s the right one — we’ll be specific about when. But a lot of the rescue and takeover work we do starts the same way: a good person, hired alone, into a job that was never one person’s shape.
“Build our software” is at least four jobs
A production system needs architecture decisions, frontend and backend construction, infrastructure and deployment, and security judgment. These are different skills that happen to share a job title. Most developers are genuinely strong in one or two. Hire one person and you get their strong suits done well, their weak suits done quietly badly — and no one positioned to tell you which was which until something breaks.
That last clause is the structural problem, and it has a name in engineering culture: nobody reviews the work. In any functioning software team, code gets a second set of eyes before it ships. A solo developer embedded in a non-technical business has no second set of eyes. Not because they’re careless — because review requires a reviewer, and you didn’t hire one. The business finds out about the weak suits eighteen months later, as an audit finding or an outage.
What it looks like when the shape fails
- The bus factor is one. One resignation, illness, or burnout away from nobody on earth understanding your system. This isn’t hypothetical: our project takeover work exists because it happens constantly.
- Knowledge lives in one head. Documentation loses to deadline pressure every time when no colleague needs it. The system works; nobody can say quite why; and every year the gap between the system and anyone else’s ability to maintain it widens.
- Custody drifts toward the developer. Domains registered under personal emails, servers on personal accounts, repositories in personal spaces. Rarely malicious — usually just expedient — but the business slowly stops owning its own software. (What clean custody looks like: a proper audit enumerates it.)
- Verification falls to the person least equipped to do it. With no technical counterweight, “how’s the project going?” gets answered by the only person who knows — the person being evaluated. Most solo developers are honest. The problem is you have no way to know.
When one developer is exactly the right hire
This argument oversold would be its own kind of hype, so here’s the other side. One developer is a fine shape when the scope is genuinely bounded — a defined internal tool, an integration, an automation with a clear finish line. It works when there’s technical judgment somewhere on your side of the table to review and verify. And it works when the stakes of a quiet failure are tolerable: an internal report being wrong for a month is an annoyance; a customer-facing system leaking data is not.
The pattern to avoid is specific: one person, alone, building and operating a system your business depends on, reviewed by no one, for years. It’s not that any given developer can’t do it. It’s that when it goes wrong, it goes wrong invisibly, and the invoice for finding out arrives all at once.
Buy the outcome, not the headcount
The fix isn’t hiring five developers instead of one — for most operational businesses that’s the wrong spend entirely. The fix is buying accountability for an outcome instead of hours from an individual: a senior team that brings its own architecture, review, and deployment discipline, sized to the engagement rather than to a org chart. That’s what managed software delivery means here — one accountable team from discovery through production support, with the fit and anti-fit stated plainly. If you already have developers and what’s missing is the judgment layer, the fractional technical leadership variant covers exactly that.
And if you’re here because the solo-developer shape already failed — the developer left, the code is a mystery, the accounts are scattered — that’s a takeover, and the first move is access recovery, not judgment about the code. Related reading: whether you should be building custom software at all.
Not sure what shape your project needs?
Describe it in your own words. Joseph reads every note and replies himself — and if one good developer is genuinely all you need, he’ll tell you that.
Start a Project