01
Hardware got faster. Software didn’t.
A phone in your pocket today is faster than the servers that ran whole companies twenty years ago. Yet a chat app can take seconds to open, a web page can ship megabytes of code to show a few paragraphs of text, and a simple form can stutter while you type. The machines kept their side of the bargain. The software didn’t.
Nobody chose slow software. It’s what you get when nobody chooses fast.
We don’t think that is an accident, or the price of progress. It is the sum of thousands of small decisions that each looked reasonable on its own: one more framework, one more layer, one more dependency that saves an afternoon today and costs every user a little time, forever.
02
“Move fast” usually means “decide later.”
We have nothing against shipping quickly. We ship quickly. What we push back on is the habit of treating every hard question as something to sort out after launch: how the system behaves under load, what happens when it is attacked, who gets woken up when it breaks.
Those questions don’t go away when you skip them. They get answered anyway, by accident, and the accidental answer becomes the architecture. By the time it hurts, changing it costs many times what deciding it on day one would have. Most of the slow, fragile systems out there weren’t built by bad engineers. They were built by good engineers who were told to decide later.
03
Security is treated like the weather.
When a company leaks its users’ data, the statement usually reads as if a storm passed through: unforeseeable, nobody’s fault, deeply regretted. Look closer and it is almost always a decision. Data collected because it might be useful someday. Data kept for years after anyone needed it. An admin panel reachable from anywhere. A vendor nobody remembered was holding a copy.
A breach is rarely bad luck. It’s usually a decision nobody made.
We think the safest data is data you never collected, and the next safest is data you deleted on time. Everything else has to be designed on the assumption that someone is already trying to get in, because someone is.
04
Complexity gets sold as sophistication.
There is a version of our industry where a three-person team runs twenty services, a brochure site needs a container orchestrator, and every new project starts by picking whatever is trending. It looks impressive on a diagram. It is miserable to run, expensive to host, and slow to change.
Complexity is not a sign of seriousness. Every moving part is something that can fail, something someone has to understand, something that has to be patched in the middle of the night. We would rather build the simplest system that genuinely holds up, and add machinery when the problem demands it, not when a résumé does.
05
The people who build it should run it.
On a lot of projects, one team builds the system, hands it over, and moves on. Another team inherits it, along with every shortcut nobody wrote down. The builders never feel the consequences of their choices, so the choices never improve.
We think that loop is broken. When the engineer who wrote the code is also the one who gets the alert, they write different code: clearer logs, saner defaults, fewer clever tricks. Owning a system after launch isn’t extra work on top of engineering. It is what keeps the engineering honest.
06
People aren’t a growth metric.
Too much software is designed to be hard to leave rather than good to use: notifications engineered to pull you back, cancel buttons buried three menus deep, consent banners where “no” is the hard option. It looks great on a dashboard. It quietly teaches everyone to distrust the tools they use every day.
Respecting someone’s time isn’t a feature. It’s the job.
We want people to use what we build because it is fast and it works, and to be free to walk away whenever they like. Respecting someone’s time and attention isn’t a nice extra. It is the job.