Practice

Nothing ships here because it looked fine.

Software built by agents is easy to produce and hard to trust. This is the method that closes the gap — the checks, what runs them, and what happens when one of them says no.

The first thing checked is the brief.

Most bad software is built correctly, to a wrong instruction.

So before work starts, the load-bearing claims in a brief get tested against the live system — the price, the state of the file, the thing described as broken. A premise that fails is the first finding, and it goes back rather than getting quietly corrected on the way past.

A brief that reads plausibly is exactly the one worth checking. Plausible is what a stale fact looks like from the inside, and work built on one arrives neat, confident, and aimed at the wrong thing.

What every build goes through.

Item 1

One job, one refusal

The work is split across agent specialists, each with a single job and a single thing it will not do. The reviewer cannot edit. The builder does not sign off on its own release. The security pass tests with the wrong credential, never the right one.

The refusals are the point. A specialist that will do anything produces work nobody can check.

Item 2

Failure gets forced, not awaited

The updater that passed ten clean runs and still left the old program on disk failed on the very first run once the file was held open on purpose.

No amount of ordinary testing was going to find that, because the fault needs a locked file and a clean machine never produces one.

Waiting for a failure means shipping until a customer finds it for you.

Item 3

Review comes from outside the build

Every finished piece of work is read by a reviewer that had no part in making it, running on a different model family from the one that built it. A reviewer that shares the builder’s assumptions will confirm them.

That pass caught a licence page asking for legal consent to a document that did not exist. The file behind it held seventy-two bytes of marketing copy. Every earlier check had walked straight past it.

Item 4

A command settles it, or it is not a claim

“It works” is not a result. An exit code is. A status code is. A hash checked again on a second machine is.

If nothing can settle a claim, the claim does not get made.

A no-go means it does not ship.

Read the build record

The desktop application was finished and still not published, because one link in the chain, from a published download through to verifying its update signature, had never been run end to end.

It would almost certainly have been fine. Almost certainly is not checked, so it waited. On 8 September the check ran and passed.

The case study is the full account: what was built, the four faults that got caught, and the one check it waited on.

After it ships.

Recurring work runs on its own schedule and reports only when there is something worth reading. When something is found broken, the fix arrives attached to the finding rather than as a list to get to later.

The measure is simple: you should not be the person who discovers your own outage.

Who is behind this.

vDesktop, LLC is a Texas company, founder-owned and operated. It owns and runs markdalton.com and adpanda.com.

It is small on purpose. The leverage here is the method and the tooling rather than headcount — which is exactly why the checks above are written down and enforced, instead of left to whoever happens to be paying attention that day.

If you want to know precisely what was checked on your software, and by what, this page is the whole answer.

Then tell us what you need built.

If this is the way you want your software made, say what you want and what it has to do. You will get a straight answer about whether it is something we should build.

Tell us what you want built Read the build record

We own and operate markdalton.com and adpanda.com.

Corrected 1 October 2026: the release that was held has passed its last check. Everything else on this page was true on 30 August 2026. If that date is old, treat this as old.