A brand launch, and a checkout nobody had tested end to end
Start here: this one is mine. Goldmark Craft Beers and Draft Pick Brewing Company are businesses I own, and I built both storefronts myself. Read this as a worked example rather than an independent reference. What you get in exchange is the version nobody usually publishes: real defects, named, in my own work, including the ones that were embarrassing.
The challenge
Goldmark had outgrown Squarespace. Moving off it meant rebuilding the storefront rather than restyling it, and at the same time Draft Pick was going to market as a new brand and needed a store of its own.
Two storefronts, one launch window, and a build that worked perfectly every time I clicked through it.
That is the state most small business websites launch in. Somebody builds it, somebody checks the page loads, somebody puts a test item in a basket and watches the payment page appear, and everyone agrees it is finished. The parts that only fail under real conditions stay broken until a real customer finds them. The failure mode is not a crash. It is a customer who pays and then hears nothing.
What I did
So before either store took a real order, I ran the Build Standard over my own work.
That is a less comfortable exercise than it sounds. A standard finds defects you were not looking for, which by definition includes the ones you were confident were not there. A snag list only finds what you already suspected.
What it turned up, all of it in a build I had made myself and was ready to launch:
The checkout was not recording orders. No webhook endpoint had ever been registered, so a payment could complete without the application ever learning it had happened. Compounding it, the platform was intercepting the payment provider's signature header before the function code could read it, which is why earlier attempts to connect it had failed. Two gates, both invisible from the front end, and both invisible from the happy path I had been testing.
Diagnosed, fixed, and then proven with an order recorded end to end rather than assumed.
Nobody could sign in. The login, register, forgot-password and reset pages all existed and had all been written. None of them had ever been routed, so /login returned a 404. Nobody had reported it because nobody could get far enough in to notice it was missing. I found the same thing on this site, running the same standard over it. That is how I know it is a property of the platform rather than a lapse on one project.
An open redirect in the checkout. A security defect in the code that creates the payment session, patched before launch. That class of defect is what turns a legitimate checkout link into a phishing vector.
The consumer terms did not properly exist. Written from scratch: cancellation rights, who pays return postage on a change of mind and who pays when the item is faulty, the exemptions that apply to perishable goods, and a commitment on how quickly complaints are answered. Postage built as a weight-banded data model rather than a flat rate guessed at launch and argued about afterwards.
What those four have in common is that none of them shows up on the happy path. You can click through a basket, reach a payment page and see a confirmation screen with every one of them still in place. That is why a written standard finds them and a careful look does not.
Alongside the build, the workflows behind it changed: how an order is picked up, fulfilled and closed off, and who does what at each step. That part is not software, and it is half of what made the launch work.
None of this is glamorous. All of it is the difference between a site that looks finished and a site that is.
What changed
Both storefronts went live on 8 August 2026 with a checkout that had been walked end to end, a sign-in that worked, and terms that would survive a customer reading them.
The wider point, and the reason this is the first case study on the site: every one of those defects was found by running a written standard over the build, not by being clever about it. The checkout fault had already survived repeated attempts to fix it by someone looking straight at it. The standard found it because the standard asks whether an order was recorded, not whether the payment page loads.
The uncomfortable part is whose build it was. I wrote the standard, and it still caught four things in my own work that I was ready to ship. That is the argument for having one, and it is easier to make with my own business than with a client's, because I can tell you exactly what was broken.
By the numbers
Want the same standard run over yours
Four questions, about a minute, no email needed. The first call is free.