A Practical Testing Workflow for Solo Devs

The advice you read about testing was written for teams. Test pyramids, coverage gates, QA hand-offs, mutation testing — all reasonable when you have ten engineers and a mandate. When you're one person shipping a product between a day job and dinner, that advice doesn't just feel heavy; it actively talks you out of testing at all, because the version in your head is "write a thousand tests" and you correctly conclude you don't have time for that.

So you ship with no tests, get burned by a dumb regression, feel guilty, and the cycle repeats. There's a better middle path: a lean workflow that catches the bugs that actually matter and ignores the ones that don't. This is testing scaled for one person and a deadline.

The mindset: test where it hurts, skip where it doesn't

As a solo dev, your scarcest resource is time, so every test has to earn its place. The filter is simple: would a failure here cost me money, data, or the core value of my product? If yes, test it. If no, let it ride and fix it if it ever breaks.

This means you deliberately don't test most of your code, and that's correct. Exhaustive coverage is a luxury bought with team-sized time budgets. What you're buying instead is insurance on the few things where a failure is expensive. A bug in your settings page is annoying. A bug in your checkout is a refund email and a lost customer. Spend accordingly.

Step 1: Protect the critical path

Find the one or two flows that make your product worth using, plus anything that touches money or user data. That's your critical path. For a paid product it's the purchase flow. For a tool it's the core action — the thing people came to do. For anything that stores user work, it's save-and-load.

Write a small number of end-to-end tests that drive these flows the way a user would: sign up, add an item, pay, confirm it worked. These are slow and a little fragile, and you'll have very few of them — that's fine. Their job is to scream before a deploy if the most important thing in your product is broken. Three good critical-path tests catch more real damage than a hundred tests on code nobody depends on.

Run them automatically before every deploy. A critical-path test you have to remember to run is a critical-path test you'll skip the one time it mattered.

Step 2: Make every bug fix permanent

This is the single highest-leverage habit for a solo dev, and almost no one does it: every time you fix a bug, write a test that fails on the old behavior and passes on the fix.

The economics are unbeatable. The bug already happened, so you know it's real and you know exactly how to reproduce it — the expensive part of testing is already done. The test takes five minutes and guarantees that specific bug never silently comes back. Over a year, your test suite becomes a precise record of every way your product has actually broken, which is far more valuable than coverage of code that's never failed.

A bug that happens once will happen again — a refactor reintroduces it, a dependency changes behavior, you forget the edge case. The regression test is how you make a fix stick. (Log bugs as you go in the Bug Report Template so each one has clean reproduction steps; that report becomes the spec for the regression test you write.)

Step 3: Unit-test the parts you'd otherwise guess about

You don't need unit tests everywhere. You need them where the logic is tricky enough that you're not sure you got it right: date math, money calculations, parsing, state machines, anything with edge cases you keep having to think hard about.

These are the places bugs hide and the places unit tests pay off fastest, because a unit test runs in milliseconds and tells you precisely what broke. When you catch yourself opening the app to manually check whether some fiddly calculation is right, that's the signal — write the unit test instead. You'll check it a hundred times over the project's life; let the machine do it.

Step 4: Let production tell you what you missed

You will miss things. One person cannot anticipate every way real users will break a product, and pretending otherwise just means your users become your bug tracker — and most won't bother to report; they'll just leave.

So instrument production. Add error monitoring that emails or pings you when something throws. This is the solo dev's substitute for a QA team: real users exercise paths you never imagined, and monitoring turns their failures into a quiet alert instead of a churned customer and a mystery. The first time it catches a crash you'd never have found, it pays for the hour you spent setting it up.

Step 5: Review your own change like a stranger wrote it

Before you ship, read your own diff as if reviewing someone else's pull request. It feels silly solo, but the shift in perspective is real: you catch the off-by-one, the forgotten error case, the debug line you left in. Five minutes of cold-eyed self-review is the cheapest quality check there is, and it requires no tooling at all.

A quick checklist helps here, because your tired Friday-evening brain won't remember to check everything. Even a short list — did I handle the error path, did I test the critical flow, did I remove debug code — turns self-review from "vibes" into something repeatable.

Putting it together

The whole workflow, for one person:

1. A few end-to-end tests on the critical path, run before every deploy.

2. A regression test for every bug you fix — non-negotiable, five minutes each.

3. Unit tests on the tricky logic you'd otherwise re-check by hand.

4. Error monitoring in production so users aren't your bug tracker.

5. A cold-eyed self-review of every change before it ships.

That's it. No QA team, no coverage mandate, no test pyramid to agonize over. It's a handful of habits that, together, catch the overwhelming majority of bugs that would actually hurt you — while leaving you the time to keep building. (Track your critical-path cases in the Test Case Tracker so you can see at a glance what's covered before you ship; it's built for exactly this lean, one-person workflow.)

Testing as a solo dev isn't about doing what teams do with less. It's about doing the small, specific things that protect what matters — and refusing to feel guilty about skipping the rest.