Introducing Veristria

Three products launched over the past year that look, on paper, unrelated. One reads JavaScript bundles. One tests database policies. One reconciles payment ledgers. Different stacks, different buyers, different failure modes.

They have the same parent, and they were built from the same observation.

Output outgrew review

For most of software's history, code was written and read at roughly the same rate, because the same people did both. Reviewing was slow, but so was writing, and the two stayed in proportion.

That proportion broke. A small team using AI tooling now produces more working code in a week than it can meaningfully review in a month. The important word there is working. The output compiles, the tests pass, the feature ships. Nothing announces that nobody read it.

What follows is not a wave of dramatic bugs. It is a specific, quiet category of failure: the kind where the system reports success and the problem is only visible if something goes and looks at the deployed result.

Three versions of the same failure

Take the three most expensive examples we kept running into.

A build-time environment variable inlines its value into the JavaScript bundle. The .env file is correctly git-ignored, the repository is clean, every secret scanner in CI passes — and the key is served to every visitor who loads the page. The repository was never where the leak was.

A row-level security policy is written correctly in April. In June the schema changes: a column is added, a table is split, a join gets a new path. The policy still exists, still parses, still runs. It no longer covers what it was written to cover, and nothing errors.

A refund lands on a marketplace platform. The charge is refunded, the customer is made whole, the connected account keeps the transfer it already received. The platform absorbs the difference. Stripe did exactly what it was asked to do. The money is simply gone, and it will not appear in any error log.

Three stacks, one shape: the system is behaving correctly according to its own instructions, and the instructions were wrong in a way nobody has looked at.

What verification means here

The tempting response is more analysis of the source — better linting, stricter types, more review gates. Useful, and not what these failures need. Every one of them is invisible in the source and obvious in the deployment.

So all three products start from the same three moves.

Observe what shipped. Not the repository, not the intent. The JavaScript your CDN is serving right now. The policies your database is currently enforcing. The transfers your platform actually made.

Prove the finding. A masked key prefix with a fingerprint. A query that returns a row it should not. A Stripe object id you can open in your own dashboard. If we cannot point at something you can check yourself, we do not report it.

Say what to change. One fix, in the vocabulary of the stack it belongs to. A finding you cannot act on is a notification, and notifications get muted.

That is the whole method. It is not sophisticated. It is just applied to the deployed artefact rather than to the plan.

Why they stay separate

A reasonable question: if the method is shared, why not one platform?

Because the surfaces are genuinely different problems with different buyers. A team on Supabase should not be paying for Stripe Connect reconciliation it will never use. A marketplace platform does not need bundle scanning to justify its invoice. Bundling them would mean selling everyone two products they did not want to reach the one they did.

There is also an operational reason. Three separate products means one product's incident is one product's incident. A verification tool that takes down two unrelated systems when it fails has misunderstood its own job.

So they stay separate: separate domains, separate pricing, separate roadmaps. What they share is a parent, a standard for what counts as a finding, and this blog.

What is here

Veristria is the company behind KeyDrift, VibeGuard and FeeGuard. Each product's own site carries its own technical writing. This one carries the things that span them: what we are learning about verification as a discipline, how AI-assisted engineering actually fails in production, and what we are building next.

Each product will tell you whether you have a problem before it asks you for anything. That part is not a promotion — it is the only honest way to sell verification. You should not have to take our word for it that something is wrong.

If you want the overview, start with the products. If you want to know who is behind it, the about page covers that.