What "Production-Ready" Means When We Say It

“Production-ready” is the most inflated phrase in software. It costs nothing to say, so everyone says it — about the demo that worked once, about the site that’s never been loaded by more than three people at a time, about the AI feature that hasn’t met its first weird user. For a business owner buying software, the phrase carries exactly zero information.

So instead of saying it, let me show you what our bar looks like, with receipts. Not because our projects are precious, but because you should demand this specificity from anyone who builds for you — and the follow-up questions at the end are yours to keep.

Fifteen hundred tests for one app

One of the products we ship — a desktop AI app, the code is public — carries over 1,500 automated tests. Every time the code changes, all of them run. If one fails, the change doesn’t ship.

Here’s what a test actually is, stripped of jargon: a promise, written down, checked by a machine, forever. “When the user does X, Y happens” — proven again every single day, for free, at a scale no human QA pass can touch. The alternative is what most small software actually runs on: the developer clicked around, it seemed fine, it shipped. That works until the first change six months later quietly breaks something nobody thought to re-click.

Tests are why software can keep changing without decaying. When we hand a client a system, the tests are in the box — which means the next developer, whoever that is, inherits the promises too, machine-checked. That’s also why we’re comfortable selling you the asset instead of renting it to you: the discipline travels with the code.

Testing asks “did it work?” — verification asks “can it fail?”

Tests check the cases someone thought of. The bugs that hurt live in the cases nobody thought of. So on top of testing, we run our code through formal verification — I’ve written about the system before — dozens of analysis engines that read the code and hunt for whole categories of failure: the input nobody sanitized, the edge case that corrupts data, the security hole that only shows up when two features interact.

The distinction matters more than it sounds. A test is “I tried the door, it was locked.” Verification is walking the building checking every door, including the ones nobody uses. For client work — where the code handles leads, payments, patient inquiries — I want both: the promises checked daily, and the doors checked before anything ships.

Almost no small-business software gets this treatment. It’s cheap to run once you’ve built the habit, and the habit is the point.

Code you can actually read

Some of what we build is open source — Engram, our screen-memory system, and G-Rump both sit in public repositories on GitHub, commit history and all.

For a business owner, here’s why that’s relevant even if you never read a line of it: it removes the trust-me. Anyone — including a developer you hire to check our work — can open those repositories and see how we build when nobody’s making us: how it’s organized, how it’s tested, what the history looks like. Most agencies can’t show you that. Their work is private, so their standards are whatever they tell you their standards are. Ours are inspectable, which keeps us honest on the private work too, because it’s built by the same hands with the same habits.

The questions you should ask anyone building for you

You don’t need to know software to buy it well. You need this list:

1. “How many automated tests does it ship with, and can I watch them run?” Any real answer includes a number. “We test thoroughly” is not a number.
2. “What happens when a change breaks something — how would you know before I do?” The answer should involve machines, not vigilance.
3. “Has anything you’ve built been checked for security problems, and by what?” Listen for a process, not an assurance.
4. “Can I see something you’ve built — the actual code?” Open source makes this trivially answerable. If nothing is showable, ask why.
5. “If we part ways, what exactly do I own, and can another developer pick it up?” Tests and clean structure are what make the honest answer “everything, and yes.”

A builder with real standards will enjoy these questions — they’re the rare chance to show off the invisible work. A builder without them will get vague, and the vagueness is your answer.

That’s what production-ready means when we say it: promises checked by machines, failure hunted before launch, and work we’re willing to show. The phrase is free. The receipts aren’t — ask for them.