Somewhere between teaching and product management, I spent a stretch of my career building and running a QA department from close to nothing. That sentence tends to get skipped over in a portfolio, but it's the part of my background I lean on the most when I talk to prospective clients — because it's also the part almost nobody else offering freelance development work can credibly claim.
"I tested it" usually means one thing
For most solo developers, testing means running the happy path once, maybe twice, and shipping. That's not a criticism — it's just what's achievable without a process behind it. A real QA pass is different in kind, not just degree: it means deliberately trying to break the thing before a client does, documenting what you find, and having a repeatable way to check it again after the next change.
What a QA process actually buys you
A few concrete things changed once QA stopped being a courtesy and started being a department:
- Regressions got caught before launch, not after. The cost of a bug found in review is a comment. The cost of the same bug found by a client is an apology and a rebuild of trust.
- Edge cases stopped being surprises. What happens when a form field is empty, a network call times out, or two people submit at once — these stop being "we'll deal with it if it happens" and become a checklist.
- Handover got easier. A tested, documented feature set is something the next person (or the client's own team) can pick up. An untested one is a black box only the original author can safely touch.
Why this matters for a website or a line-of-business tool
None of this is exotic — it's standard practice at any organisation that takes software seriously. What's unusual is finding it attached to freelance or small-agency work, where the incentive is almost always to ship fast and move to the next client. I'd rather ship slightly slower and have the client never think about the QA process again, because it never surfaces a problem for them to think about.
More posts
The three-day budget bottleneck that became a few-hour task
A look at the actual mechanics behind the GOCD Budget Web Application — why importing completed ministry budgets took three days, and what specifically closed the gap.
Why I don't build your site on a website builder
Drag-and-drop builders sell speed today at the cost of speed, control, and ownership later. Here's the trade-off, stated plainly.