Why we verify everything before we call it done

There is a moment in almost every project where someone says the work is done. The demo runs. The page loads. The button does the thing it was supposed to do. Everyone exhales.

We have learned to be careful with that moment. Not because people are dishonest — they rarely are — but because "it worked when I tried it" and "it works" are two different claims, and the distance between them is where most trouble lives. Closing that distance is the whole point of how we build.

"It compiles" is not "it's done"

A build passing is good news. It means the code is internally consistent enough to run. It says nothing about whether the thing does what a real person needs it to do, on the device they actually use, in the state they'll actually be in.

So we treat compilation as the start of verification, not the end of it. A green build earns a piece of work the right to be checked — it doesn't certify anything on its own. The questions that matter come after: Does every route render? Does the form reject bad input and accept good input? Does it behave the same on a phone as on a laptop? Are there errors quietly stacking up in the console that no one thought to open?

None of those questions are answered by a successful build. They're answered by looking.

Spec, build, verify, remember

Everything we ship moves through the same four stages, and we try very hard not to skip any of them.

Specified. Before a line of code exists, we write down what the thing is for and how we'll know it works. A spec isn't bureaucracy; it's the definition of success you can check against later. If you can't say what "done" looks like in advance, you can't verify it afterward — you can only have opinions about it.

Built. The work gets assembled and tested as it comes together, not in one heroic push at the end. Small, checkable steps beat big, unverifiable leaps. When something breaks, you want to be looking at the last ten minutes of changes, not the last ten days.

Verified. This is the stage most teams shortchange, and it's the one we protect. Verification means someone — or something — other than the original author checks the work against the spec. Independent eyes catch what tired eyes miss. The goal isn't to assign blame; it's to make sure the claim "this works" is backed by evidence rather than hope.

Remembered. When we learn something — a bug pattern, a better approach, a decision and the reason behind it — we write it down where the next person will find it. The alternative is relearning the same lessons on every project, which is slow and quietly demoralizing.

The stages are simple. The discipline is in refusing to declare victory before the third one is actually finished.

What verification looks like in practice

Concretely, before we call a web build done, we walk every page a real visitor could reach. We open the browser console and read it — every warning, not just the errors. A hydration mismatch or a missing asset is a defect even if the page looks fine, because it's a sign the thing isn't behaving the way the framework expects, and those signs tend to grow into failures later.

We resize the window to a phone, a tablet, and a desktop, and we confirm the layout reflows correctly at each. We tab through the page with the keyboard to make sure someone who doesn't use a mouse can still get everywhere. We submit the forms with bad data and confirm they push back, then with good data and confirm they succeed. We check that images have meaningful alternative text, that headings are in order, that contrast is high enough to read.

Only when all of that holds do we assemble the evidence — the build log, the screenshots, the record of what was checked — and only then do we use the word "done."

Why the extra rigor is worth it

It would be faster, in the moment, to skip most of this. Verification costs time that doesn't produce anything visibly new. So why do it?

Because the cost of a defect grows the longer it survives. A problem caught during verification is cheap: you're already looking at the code, you understand the context, and nobody is depending on the broken thing yet. The same problem caught by a real user is expensive — it has damaged trust, it arrives without context, and fixing it means re-entering a project you'd mentally closed.

There's a quieter reason too. When a team knows that "done" is a real bar and not a polite fiction, it changes how people work. You stop performing progress and start producing it. You write specs you can actually check, because you know they'll be checked. Verification, done consistently, is less a gate at the end and more a standard that shapes everything upstream of it.

Proof over promises

We say we have a bias for proof over promises, and this is what we mean by it. A promise is a statement about the future: it'll work, it'll be ready, it'll do what you need. Proof is a statement about the present, backed by something you can inspect: here is the thing, here is how we checked it, here is what we found.

Promises are necessary — you can't build anything without making some. But they're cheap, and everyone makes them, so they don't tell you much. Proof is expensive and specific, which is exactly why it's worth more. When we hand something over, we want the person receiving it to be able to trust it without taking our word for it.

That's the standard. Verify honestly, keep what you learn, and don't call it done until it actually is. It's not glamorous, and it rarely makes a demo more exciting. But it's the difference between software you can lean on and software you have to keep an eye on — and over time, that difference is everything.