Each time an incident passed, we drew a rule from it. Those rules became our internal doctrine. Here's the principle, and some of the most important ones.
A few years ago, after an incident we could have avoided, we started noting our rules. Not code rules, conduct rules. Not "how to do well": "what we re-do when things break." Today those rules form an internal document we re-read on every project and every hire. We call it "our 12 laws". The kind of document we don't usually show clients, because it exposes our weaknesses as much as our method. We've decided to show it, because that's what sets a serious agency apart from one that promises.
Why "laws" and not "best practices"
Best practices are what you do when all's well. Laws are what you do when you're tired, rushed, or tempted to cut a corner. The difference is fundamental: a best practice is a recommendation, a law is a constraint you impose on yourself to protect yourself from yourself. Each law comes from a real incident. We didn't invent them in a seminar. We paid for them, often at night or on weekends.
Some of the most important
"A backup never restored isn't a backup." We restore for real, regularly. If the restore fails, we fix before the next backup. No "we'll see if we need it." "A procedure never played is a hypothesis." Each critical procedure (failover, restore, version upgrade) is rehearsed by a human before being considered operational. "Silent success kills." A system running without alerting isn't healthy, it's mute. We want regular alerts saying "I'm working", not only alerts saying "I'm broken." "Measure before correcting." We don't change a behaviour in production before measuring what it was doing. Else we risk fixing a symptom and breaking an unseen function. "A named person answers." A client-reported bug is never handled by an anonymous ticket. A named person takes the lead, signs the response, follows through to close.
What this does for you
Three things. It gives you a verifiable frame: you can ask us how a law was applied to your project. It tells you what to expect: a provider who writes their rules is a provider who doesn't improvise them. It's portable: if you one day take over or move to another provider, you can take the document along: these rules aren't Yumea-specific, they hold anywhere.
What we've seen on the ground
The law "a backup never restored isn't a backup" was born in 2022 from an incident: a daily backup had worked for months, and the day we needed it, we discovered the export format was corrupted. We recovered the data another way, no client loss. But since that day, we test the restore every quarter.
FAQ
Can we see the full document? Yes, pre-contract on request, in anonymised form. We send it so you can read before signing.
Do you add laws? Yes, after each significant incident. Not set in stone, but a written law doesn't come off easily, because it's been paid for.
You want to see what our laws look like concretely before entrusting us with a project? We send an anonymised extract. Let's talk →