When you go solo, quality assurance is entirely your problem. Building ReportForge — a Windows desktop tool that automates Excel report generation — has taught me more about testing in the last few months than years of working in larger teams. Here are five lessons that actually stuck.
01 — Unit tests tell you the code works. They don't tell you the product works.
Unit tests passing across license validation, CSV parsing, and placeholder mapping. Green board. Sat down and pretended to be a first-time user — no dev environment, no elevated permissions, just the installer and a blank machine. Three things broke immediately:
- A file path that worked fine in dev was hardcoded to my machine
- The first-run wizard assumed a config file that didn't exist yet
- An error message referenced a log file the user would never find
Unit tests validate logic. End-to-end tests validate reality. Both are needed, but start with the test that tells you whether a real person can use the thing.
02 — You are not your user. You will never be your user.
You know the app inside out — what order to do things in, which menu has which option, the full mental model. Users have none of that. They open cold, don't read tooltips, don't follow the happy path. They drag things in the wrong order, skip steps, click buttons you assumed nobody would click.
Most useful exercise: follow a new-user script with zero developer shortcuts. Within ten minutes, seven friction points that were completely invisible before.
If you can get a real person instead: watch them use it without saying anything. Don't help. The places where they pause, squint, or go silent are the places to fix.
03 — Test the edges your users will actually hit, not the ones you think they will.
Developers test null values, empty arrays, boundary conditions. Users create usage edge cases: filenames with spaces, CSVs from different software with different delimiters, Excel templates built in 2009 with legacy formatting.
Started keeping a list of “weird inputs a real office worker would have”:
- A CSV with a BOM character at the start — common from certain accounting software exports
- An Excel template with merged cells in the header row
- A filename with parentheses, commas, or ampersands in it
These generate the first support tickets. Write the tests before the tickets arrive.
04 — A staging environment only matters if you test it the way users experience production.
Full staging environment set up — Azure Static Web Apps, Azure Functions, Azure SQL. Felt professional.
Then realised: still testing by running scripts from dev machine with admin permissions, hitting endpoints directly, bypassing the UI. That is not staging testing. That is running production in a different hat.
The discipline is to test staging the same way a user experiences production: through the UI, with a real account, going through the actual purchase and activation flow. Inconvenient, and worth it.
05 — The gap between ‘I think I know what's broken’ and ‘I actually know what's broken’ requires good logging.
When something breaks in the wild, you won't be there. Need to reconstruct from a user report with no repro steps.
Bracketed log prefixes across Azure Functions, filterable in Application Insights: [LicenseActivation], [WebhookProcessor], [TelemetryIngest]. Small thing that becomes the difference between a twenty-minute fix and a two-hour nightmare at 11pm.
Log everything that crosses a boundary. Log inputs, outputs, and decisions in between. No regrets on verbosity.
Still learning
The hardest part of solo development is that you cannot review your own blindspots — by definition, you don't know they're there. Everything above is a lesson learned because something broke in a way that wasn't anticipated.
The goal is not a perfect process. It is a process that catches more things than it misses, and gets better over time.
If you are building solo and have QA approaches that have worked for you, we'd genuinely like to hear them. The problems in this space are more shared than they appear. Reply on X →
ReportForge is coming soon
A Windows desktop tool that automates Excel report generation from templates and CSV data. No macros. No code. No IT sign-off required.
Join the Waitlist