Software we’ve written and managed is used by more than five million people worldwide, and across that portfolio we sustain 99.8% uptime. That number isn’t luck, and it isn’t a heroic on-call team putting out fires at 3 a.m. It’s the result of a few unglamorous habits applied consistently, on every project, from the first line of code.
Reliability starts in the architecture
Most outages are designed in long before they happen. When we plan a system, we ask the boring questions early: What happens when this dependency is down? What happens when traffic triples? What happens when a deployment goes wrong halfway through?
The answers shape the architecture — stateless services where possible, queues between systems that shouldn’t fail together, databases with tested (not just configured) backups, and deployments that can be rolled back in minutes. None of this is exotic. It just has to actually be done.
Boring technology, deliberately chosen
We pick technology the way an engineer picks a bridge material: by how well its failure modes are understood. Proven databases, managed cloud services, and frameworks with years of production history give us fewer surprises than whatever launched last quarter.
That doesn’t mean we’re behind the curve — we ship AI features and modern stacks every week. It means novelty has to earn its place in the critical path.
You can’t fix what you can’t see
Every system we operate ships with monitoring from day one: error rates, latency, queue depths, disk space, certificate expiry — the basics that cause most real-world incidents. Alerts go to humans only when a human needs to act. An alert channel full of noise is the same as no alert channel at all.
This visibility is the main reason our average time to resolve an issue is around four hours. Most problems are caught while they’re still small, often before users notice anything.
Operating across time zones helps
Our engineering teams are based in Germany and Malaysia. The time difference means there are very few hours in a day when nobody is at a keyboard. An issue that surfaces in the European evening is picked up in the Asian morning — without anyone sacrificing their sleep or their judgment.
Reliability is a relationship, not a milestone
The biggest difference between software that stays up and software that doesn’t is what happens after launch. We don’t hand over a repository and disappear; we monitor, patch, upgrade, and keep improving the systems we build. Uptime is something you maintain, not something you achieve.
If you have a system that needs to be dependable — whether we built it or someone else did — we should talk.