The solo developer — wearing every hat
Key takeaways Every hat — alone you are product, design, code, test, release and support. Speed vs safety — no coordination cost, but no review and a bus factor of one. Self-imposed structure — give yourself the discipline a team would force on you.
Most of this path has quietly assumed a team — code reviewers, a CI server someone else set up, a designer who handed you mockups. This final module strips that away. Here you are the whole company: the only person who decides what to build, builds it, checks it works, ships it, and answers the email when it breaks. That is both the most freeing and the most dangerous way to make software, and by the end of this module you will have three concrete things to tame it — a stack you can maintain alone, a workflow that keeps you fast, and a distribution strategy that gets your program into other people’s hands. This first lesson is about the mindset that makes the rest possible.
You are now the entire org chart
On a team, a software product is split across specialists. Solo, all of those roles collapse into one person who switches between them many times a day:
- Product manager — deciding what is worth building and, more importantly, what is not.
- Designer — shaping how the thing looks, reads and feels to use.
- Programmer — actually writing and structuring the code.
- Tester / QA — proving it works and finding where it breaks.
- Release engineer — packaging, versioning and publishing a build people can run.
- Support & community — fielding bug reports, questions and feature requests.
The skill of the solo developer is not being world-class at all six — nobody is. It is noticing which hat you are wearing and not letting the fun ones crowd out the boring ones. The trap is spending every hour as Programmer (the part most of us enjoy) while Tester, Release Engineer and Support quietly go unstaffed. A program that is 95% coded and never released helps no one.
The real advantages of going solo
Working alone is not a consolation prize. It has genuine, hard-to-replicate strengths that big teams spend a fortune trying to recreate:
- Speed. There is no coordination cost — no standups, no sign-off, no waiting on another team’s queue. You can have an idea at breakfast and ship it by dinner.
- Full context. The entire system fits in one head. You wrote every line, so you know exactly why a decision was made and what will break if you change it. Teams lose this constantly; you have it for free.
- Coherence. A single author tends to produce a more consistent product — one voice, one set of conventions, one taste running through the whole thing.
- No politics. You answer to the users and to yourself. Priorities do not get hijacked by someone else’s roadmap.
These advantages are why a single motivated person can build something genuinely useful — a focused utility, a niche tool, a hobby project that thousands come to rely on. Many beloved open-source projects started as one person scratching an itch.
The traps that come with it
The same forces that make solo work fast also make it fragile. The four big ones:
- No review. Nobody catches the off-by-one, the leaked secret, the design that made sense at 2am and not at 9am. The team’s safety net is gone, so you have to rebuild it out of tools (we get to that in keeping quality high alone).
- Tunnel vision. With no second opinion you can chase the wrong feature for weeks, convinced it matters, because there is no one to ask “does anyone actually want this?”
- Burnout. Unbounded scope plus “if I don’t do it, no one will” is a recipe for exhaustion. Solo projects die far more often from the maintainer running out of energy than from a technical failure.
- Bus factor of one. If you get sick, distracted, or simply move on, the project stops dead. There is no redundancy. Good documentation and automation are partly an insurance policy against your own absence.
Naming these traps is half the defence. None of them are reasons not to build solo — they are reasons to build solo deliberately.
Quick check: what does a "bus factor of one" describe?
Be the structure you no longer have
A good team is, in large part, a machine for imposing helpful constraints: code review forces a second look, a sprint forces a stopping point, a definition of done forces you to actually finish. Alone, those constraints vanish unless you deliberately recreate them. That is the central discipline of solo development — giving yourself the structure a team would have given you.
In practice that looks like:
- A defined scope and a stopping point — a written idea of what “version 1” is, so you know when you are done rather than polishing forever. We build this in from idea to project.
- Automated guardrails — tests, linters and CI that review your work when no human can, so quality does not depend on you being sharp at midnight.
- Notes to your future self — a README, comments, and commit messages, because in six months you are the new contributor with no context.
- A small ritual — a tight, repeatable daily loop (covered next) so progress does not depend on motivation alone.
This is not bureaucracy. It is the minimum scaffolding that lets a single person ship reliable software without burning out — just enough process, and no more.
A solo example: one person, one radio tool
Consider a project like GopherTrunk itself — radio software a hobbyist downloads and runs. Even imagined as a one-person effort, every hat is in play: someone decided which radios to support (product), designed how scanning feels (design), wrote the signal handling (code), confirmed it decodes real transmissions (test), built installers for each operating system (release), and answered “why won’t my dongle work?” on the forum (support). The reason a non-technical scanner enthusiast can just visit the downloads page and run the program is that one disciplined developer wore all of those hats in turn — and crucially, did not skip the unglamorous ones. That is the whole game, and the rest of this module shows you how to play it.
Recap
- You are the whole team — product, design, code, test, release and support all land on one person who switches hats all day.
- Real advantages — speed, full context, coherence and no politics make a single motivated person genuinely powerful.
- Real traps — no review, tunnel vision, burnout and a bus factor of one are the fragilities to defend against.
- Self-imposed structure — alone, you must deliberately recreate the constraints a team would have forced on you.
- Don’t skip the boring hats — testing, releasing and supporting are where most solo projects quietly fail.
- The module’s promise — by the end you will have a stack, a workflow, and a way to ship real software.
Next up: turning Module 6’s theory into a concrete, maintainable toolkit in choosing your stack.
Frequently asked questions
What does it mean to be a solo developer?
A solo developer owns every role on a project at once — product manager deciding what to build, designer shaping how it feels, programmer writing it, tester checking it, release engineer shipping it, and support answering users. There is no one to hand work to, so the same person carries the idea from first sketch to last bug report.
What is the biggest risk of working alone?
The honest answer is you — there is no second set of eyes to catch your mistakes, no one to tell you a feature is over-engineered, and no one to share the load when you burn out. The single biggest structural risk is a bus factor of one — if you stop, everything stops — which is why solo devs lean hard on automation and good notes.
How do solo developers avoid burning out?
By giving themselves the structure a team would impose — a defined scope, a stopping point, automated checks instead of heroics, and permission to say no. Burnout among solo devs usually comes from unbounded scope and no recovery time, not from the coding itself. Sustainable pace beats sprints you cannot repeat.