The Solo Dev's Guide to Industry Problem-Solving Processes

Companion to problem-solving-processes-industry-leaders.md (2026-10-18). All quotes are copied verbatim from that document's primary-source-verified quotes, or marked as paraphrase.

You don't need a team, a budget, or a committee to run the processes that built Toyota, Amazon, Pixar, and Google SRE. Underneath all of them is one skeleton, the Toyota/Deming loop: look at reality → form a hypothesis → run the smallest possible experiment → study the result against the theory → standardize what worked, revert what didn't. Amazon's Working Backwards is that loop pointed at the customer before any code exists; the Double Diamond is it pointed at an ambiguous problem; the 5 Whys and the SRE postmortem are it pointed backwards at a failure. This guide applies that loop to the three moments where solo developers need a process: starting a project (A), adding a feature (B), and fixing bugs (C). Every ritual runs alone, takes 5–60 minutes, and needs only a notes file, version control, and a calendar slot.

PART A — Starting a new project from scratch

Do all of this in one two-hour "Day 0" session, before writing application code.

A1. Write the PR/FAQ first (~60 min)

Write the press release announcing your finished product, then the FAQ an honest journalist would ask. The practice is from Bryar & Carr's Working Backwards (paraphrased — book text not fetched), but the thinking is verbatim from Amazon's Leadership Principles: "Leaders start with the customer and work backwards." Solo: make yourself the customer, and make "why not just use <existing tool>?" FAQ question #1. No honest answer? You just saved three weekends.

When to stop deliberating, Bezos's 2016 letter, verbatim: "most decisions should probably be made with somewhere around 70% of the information you wish you had." A PR/FAQ that's 70% honest is ready; waiting for 90% is how personal projects die in planning.

A2. Classify stack choices: one-way vs two-way doors (~15 min)

Bezos's 2015 letter, verbatim:

"Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation... But most decisions aren't like that – they are changeable, reversible – they're two-way doors... Type 2 decisions can and should be made quickly by high judgment individuals or small groups."

Two-column list in your notes file. Two-way doors — pick in minutes: libraries, minor dependencies, CSS framework, code style; all swappable in an afternoon. Bezos warns (same letter, verbatim) "there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions" — solo devs agonize over logging libraries too. One-way doors — a slow hour each: data model/schema and file-layout decisions, the choices your future code encases. Sketch both on paper and put one justification paragraph in the A3.

A3. Musk's Algorithm as a requirements checklist (~10 min)

From the Everyday Astronaut Starbase interview write-up, verbatim: "The requirements are definitely dumb; it does not matter who gave them to you." On a personal project the requirement-giver is you, so you can't hide behind authority — which makes Musk's fix land harder: each requirement must come "from a name, not a department" — solo version, from a user named me. Write the concrete moment you'd use each feature, then delete ~10% of the v1 list ("Try very hard to delete the part or process"). Only after deletion: "Simplify and optimize the design" — "the most common error of a smart engineer is to optimize something that should not exist." ("Accelerate cycle time" and "Automate" come last — see C5.)

A4. The A3 one-pager as project charter (~30 min)

LEI's A3 lexicon, verbatim:

"An A3 Report is a Toyota-pioneered practice of getting the problem, the analysis, the corrective actions, and the action plan down on a single sheet of large (A3) paper, often with the use of graphics... But it is much more than a sheet of paper with facts and figures. It is a management process learned through dialogue about concrete problems."

Your dialogue partner is you-in-three-months. Create notes/a3-<project>.md, your name top-right (A3's ownership move — you're accountable to the sheet). Blocks: problem, current condition, target condition (measurable) — e.g. "it builds, deploys, and posts results by <date>" — countermeasures considered, plan, follow-up. Two rules: the target condition has a number and a date; and "countermeasures considered" includes a genuinely-argued "don't build it — use <existing tool>" option.

A5. TOC: your constraint is focus, not compute (~5 min)

The Goldratt Group, verbatim:

"Doing more and starting earlier are the intuitive ways we try to protect flow, but these actions typically achieve the opposite... Too much Work In Process (WIP) increases the internal friction."

For one person the constraint is uninterrupted attention; WIP is the number of half-thought-about projects in your head. Rule: one project at a time — a second project adds reload time, not throughput. This is the Five Focusing Steps (TOC Institute, paraphrase): exploit the constraint by serializing work; subordinate everything else until the A3's target condition is met.

A6. MVP = smallest build–measure–learn loop

theleanstartup.com/principles, verbatim: "A core component of Lean Startup methodology is the build-measure-learn feedback loop. The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible." Progress means: "The unit of progress for Lean Startups is validated learning — a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty." Write one learning question into the A3's follow-up block before building ("do I actually open this weekly?"), and score it honestly after.

Part A sources: Amazon 2015 letter, 2016 letter, Leadership Principles; LEI A3; Everyday Astronaut; Goldratt Group; TOC Institute; theleanstartup.com; Bryar & Carr (paraphrase).

PART B — Adding a new feature to an existing project

The solo failure mode is assumed problems: building what was fun to imagine, not what evidence points to.

B1. Discover before any ticket (~20 min)

The Design Council's Framework for Innovation, verbatim: "The first diamond helps people understand, rather than simply assume, what the problem is." Solo Discover = reading evidence you already own: analytics, support tickets, your own usage logs, the last three times you cursed at the app. Then state the problem in one sentence. No evidence anywhere — including your own behavior? Don't build it. That rejection is free progress.

B2. Five Whys before building (~5 min)

A feature request is usually the proposed solution, not the problem (per LEI's 5 Whys). Ask why until you hit the underlying need. If the chain lands on "because it would be cool" — allowed, but label it and size it accordingly.

B3. The hypothesis line (~2 min)

"We believe <change> will move <metric> by <N>% for <audience> because <reason>." — the Lean Startup loop (theleanstartup.com) in one sentence. No users? The metric is your own usage: "We believe offline caching will move repeat-session rate from ~40% to ~70% for me-on-the-subway, because my last two trips had no signal." Still testable.

B4. Six-block A3 feature doc instead of an RFC (~20 min)

Non-trivial features get a one-pager in notes/ with the A3 blocks (per LEI): problem with evidence (B1), current condition, target condition (B3's metric), countermeasures considered (≥2 alternatives + genuinely-argued "do nothing"), plan (flagged experiment, rollback), follow-up (check date). Better than the wiki RFC nobody reviews, and better than "just start coding," where the design lives only in your head.

B5. Two-way door → feature flag + smallest experiment

Most features are two-way doors (Bezos's 2015 letter, quoted in A2): ship behind a feature flag on a branch, run the smallest honest experiment — even one week of dogfooding with the flag on — then look at the metric. Version control is the solo safety net: branch, flag, and a git revert path you've proven works before you need it.

B6. Review your own diff as your own Braintrust (~10 min)

Before merging, write 3–5 notes on your own diff. Catmull's rule — from the Fast Company excerpt of Creativity, Inc. — is candor: "Candor is the key to collaborating effectively." Solo translation: notes as observations, not commands ("these 40 lines repeat the same shape — load-bearing?" not "make it a loop"). You are director and candid peer at once, which only works if the two hats take separate passes. Verbatim premise: "Put smart, passionate people in a room together, charge them with identifying and solving problems, and encourage them to be candid." For one person that's one room, two hats, written notes.

B7. Definition of done = the metric moved

Deming's distinction, deming.org PDSA, verbatim: "Dr. Deming found that the focus on Check is more about the implementation of a change, with success or failure. His focus was on predicting the results of an improvement effort, studying the actual results, and comparing them to possibly revise the theory." Done is not "pipeline green" (Check); it's: metric moved → keep it and log the learning in the A3; didn't → revert and log what the falsified hypothesis taught — which Ries counts as validated learning either way.

Part B sources: Design Council; LEI 5 Whys and A3; theleanstartup.com; Amazon 2015 letter; Catmull, Fast Company; deming.org PDSA.

PART C — Fixing bugs

C1. Two lanes of fixes (~2 min triage)

Lane 1, standard: understand, fix, regression-test, move on. Lane 2: the same bug or class of bug bites twice in a week — trigger for real root-cause work. LEI's 5 Whys, verbatim:

"Without repeatedly asking why, managers would simply replace the fuse or pump and the failure would recur. The specific number five is not the point. Rather it is to keep asking until the root cause is reached and eliminated."

Solo, the deepest why is usually a missing guard in your own workflow: why was bad code committed? No test covered it. Why? Quick experiments skip test-writing. Why? There's no cheap habit for it. That last whys — a missing habit — is the fix that holds.

C2. Jidoka: your CI is your andon cord

Toyota's TPS page, verbatim: "when an abnormality occurs... the machine or equipment can detect the abnormality and stop automatically, or the operator can stop the line by pulling the stop cord themselves." Solo rules, stated once and kept forever: red build → stop starting anything new until green (merging over a failed build is shipping a defective part downstream); any lost-data bug → full stop, preserve the broken state on a branch — it's your forensic evidence.

C3. A personal bug log: the SRE postmortem, scaled to one file

SRE book ch. 15, verbatim: "A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring." Solo: running notes/bug-log.md, one entry for anything in Lane 2 or any lost-data scare, ~15–20 min:

Incident:  <one line>                  Date: <date>
Impact:    <in numbers: minutes lost / data lost>
Timeline:  noticed → diagnosed → mitigated → fixed
5 Whys:    1..5 chain (one rope per symptom; branch if real)
Fix:       <commit / revert>
Process item: <the habit/guard that would have prevented it>

The blameless rule survives at one person, aimed at your future self. Verbatim from the same chapter: "You can't 'fix' people, but you can fix systems and processes to better support people making the right choices." For a solo dev, "people" = you-today and you-in-six-months; the process item is the apology you pre-write for them. And the chapter's epigraph, verbatim: "The cost of failure is education."

C4. TOC: when everything feels slow, audit time-in-queue

The constraint is rarely your debugging skill; it's work waiting in queues you can't see. Track for one week: where do your tasks wait, and where does unplanned work (every "quick fix" that hijacked the day) come from — the four types of work from The Phoenix Project (paraphrase): business projects, internal projects, changes, unplanned work. The longest queue is your constraint; the fix is WIP discipline — "Too much Work In Process (WIP) increases the internal friction" (Goldratt Group, verbatim). A task list capped at 3 open items beats a 40-item backlog in throughput, measurably.

C5. Accelerate cycle time — deliberately last

From the Everyday Astronaut write-up, verbatim: "you're moving too slowly, go faster! But don't go faster until you've worked on the other three things first." For bugs, cycle time = how fast reality talks back. High-yield solo upgrades: one-command tests, minutes-not-hours deploys, one-step repros — only after deleting what shouldn't exist. Automating around an un-understood bug is step 5 impersonating step 4.

C6. Kata-lite: one standing 20-minute slot per week

Rother's Toyota Kata site, verbatim (you-now coaching you-next-week makes "your team" a party of two):

"Toyota Kata is a skill-building process that shifts you and your team from a natural tendency to jump to conclusions ... to thinking, working and reacting more scientifically. Best of all, you only need to practice 20 minutes a day, under the guidance of your coach."

Calendar it — same 20-minute slot weekly (Friday closing works). Open your A3/storyboard and ask yourself the five Coaching Kata questions (canonical wording lives in a card the parent doc couldn't extract — paraphrase): What's the target condition? What's the actual condition? What obstacle am I addressing? What's the next experiment and expected result? When do I check what I learned? What's written down is next week's first move.

Part C sources: LEI 5 Whys; Toyota TPS; SRE ch. 15; TOC Institute; Goldratt Group; The Phoenix Project (paraphrase); Everyday Astronaut; Rother's Toyota Kata

The cheat sheet

Attribution: every verbatim quote is copied from the parent document (primary sources fetched 2026-10-18); this guide fetched no new sources. Paraphrases: PR/FAQ (Bryar & Carr), TOC Five Focusing Steps, The Phoenix Project's four types of work, the five Coaching Kata questions.