Beyond Digital Labs
The standard

What every release has to clear.

Most software pages tell you what the product does. This one tells you what must be true before it is allowed to reach you, because that is the part which determines whether the rest of it is worth anything.

No error without a way out of it

This is the rule we care about most. Software refuses people constantly and then abandons them there. Something failed, or you are not allowed, and that is the end of the message. No cause, no next step, nothing you can act on. It is everywhere and we are sick of it. Nothing we ship is permitted to stop you without telling you what happened, why it happened, and what you can do about it yourself. If we cannot write that third part, the feature is not finished and it does not ship.

A bug becomes a failing test before it becomes a fix

Nothing is repaired from a description. The reported behaviour is reproduced as a test that fails, the fix makes it pass, and that test stays in the suite permanently so the same defect cannot return quietly.

Every screen a person can reach gets walked, end to end

Not just checks on the machinery underneath that nobody ever clicks. If you can see it or click it, an automated test walks the whole path the way you would. Every screen you can land on has to offer you a way onward, or it counts as a dead end and fails.

A design change is global, or it is not done

When something shared changes, whether that is the header, a button, a page template or an email, every place it appears changes with it. We search the whole project for those places, fix the one shared piece they all use, and add a check that fails if any of them ever drifts out of line again.

One failure anywhere stops the release

A single script runs everything: every test, the build itself, and a fingerprint of the finished file. Anything left unresolved and it stops. There is no override switch and nobody can wave a release through. If it does not come back clean, there is no release.

Claims carry numbers

“Tested” is not a status. A release is described with numbers, how many checks ran and how many passed, or it is not described as finished. A failed run reported honestly is a perfectly good outcome. A confident sentence with nothing behind it is treated as a fault in its own right.

Installed, or it did not ship

Code that builds is not a release. It has to reach a real machine, start up properly, and match the file we published. Anything short of that is said plainly on the page: written, but not on anybody’s machine yet.

The refusal contract

Every error carries its own way out

When our software stops you, the message has to do three things. If we cannot write the third one, the feature is not finished.

What happened In plain words. Not a code, not a stack trace, not "an error occurred".
Why it happened The actual cause, including when the cause is a limit we imposed.
What you can do now A concrete next step you can take yourself. If the only honest answer is that you cannot fix it, then it says so and tells you who can.
Principles

What we will not trade away

It runs on your machine

The work happens on your own computer. An internet connection is something you use when you want it, not something the software needs before it will start.

Nothing watches you quietly

We do not collect anything about how you use the software. If a product ever needs to send us a report about a fault, it asks first, shows you exactly what it would send, and works the same if you say no.

Honest about where things stand

Every product page says whether it is out, in private beta or still in development, and it lists what it cannot do yet. You should never find out about a limit after paying for it.

Small, sharp tools

Each application does one job properly. We would rather ship four narrow tools than one that does eleven things adequately.

Build receipts

What we publish beside a download

When the first application opens, every version page carries the result of the run that let it out: how many checks there were and how many passed, the size of the file, and a reference code for the exact file we built. Not a badge. The actual numbers.

The point is not that you will check them. The point is that we cannot quietly skip a step when the receipt is published next to the button.

// published with every release

version ............ 1.2.1
checks ............. 21 of 21 passed
file ............... BeyondGpuManager-1.2.1-x64.exe
size ............... 118.4 MB
reference code ..... a3f1… (the full code sits on the release page)
came from us ....... verified

The values above show the format. Real ones appear on release pages once the first application is out.