Boring technology, done exceptionally well.
We don't chase the new thing. We pick proven, well-understood tools, keep the design as simple as the problem allows, measure instead of guessing, and design honesty in from the start. This page is what we believe about building software — and how we decide which tools earn a place in your project.
Most software problems are not new. We'd rather solve them well than novelly.
There's a strong pull in this industry toward the new — the framework released last month, the database that promises to change everything, the architecture from a blog post. Most of it is a way of paying for excitement with someone else's reliability. Our bias runs the other way: pick the dull, proven thing, understand it deeply, and spend the hard-won novelty budget only where the problem is genuinely new. It's a less impressive story to tell, and a much better system to inherit.
Eight convictions we build by.
- 01
Boring technology wins
We reach for proven, stable tools by default. Novelty is a cost paid in unknowns — we spend it deliberately, on the part of the problem that's genuinely new, and nowhere else.
- 02
Outcomes over output
The measure of a system isn't its cleverness or its line count. It's whether the number someone cared about actually moved. Everything else is just material.
- 03
Simple is harder — and worth it
The simplest design that solves the whole problem is the hardest one to find and the cheapest one to live with. We keep looking for it long after a working version exists.
- 04
The right tool, not the newest
We choose tools for the problem in front of us and the team that will inherit them — not for the changelog, the benchmark, or the conference talk.
- 05
Build to be changed
Requirements move; that's not a failure, it's the job. We design seams and boundaries so the next change is cheap, and we'd rather delete code than defend it.
- 06
Measure, don't guess
Is it fast enough? Is it even working? Is it worth the cost? Those are answered with numbers, not vibes. We instrument first and optimise second.
- 07
Own your core, rent the rest
The thing that makes you different, we build and understand deeply. The commodity around it, we buy — and we keep the option to walk away from any vendor.
- 08
Honesty is an architecture decision
Security, observability, and an honest “we don't know yet” are designed in from the first sketch — never bolted on later, when it's expensive and load-bearing.
Grown, not bolted together.
Good systems are tended over time — chosen carefully, kept simple, and given room to change.
A tool has to earn its place.
Every dependency is a long-term relationship — something to learn, patch, secure, and eventually live with at 3am. So before anything joins a project, it has to pass a few plain questions. “It's popular” isn't one of them.
- Does it solve a problem we actually have — today, not hypothetically?
- Will the team six months from now thank us, or curse us?
- What does it cost when it fails, not just when it works?
- If we needed to leave, how hard would it be to get out?
Defaults we trust — and break with a reason.
We start from a small set of defaults we've been burned into trusting. They're not rules — we deviate whenever a project earns it — but the deviation has to be written down, with the reason.
Typed by default
The compiler is the cheapest code reviewer we have. We reach for typed languages so whole classes of bug never reach a human.
Postgres until proven otherwise
Most “we need a special database” turns out to be a table and an index. We start boring and earn our way to anything exotic.
Managed infra, owned logic
We rent the undifferentiated heavy lifting — the servers, the queues, the patching — and own the part of the system that's actually yours.
The smallest model that clears the bar
For AI, capability you can't measure isn't capability. We reach for the cheapest, smallest model that passes the eval, and grow from there.
Few tools, clean surfaces, room to think.
Built by people who think this way.
If this is how you'd want your software built — proven tools, simple designs, honest trade-offs — tell us what you're working on. We'll be straight with you about whether we're the right team, and what we'd reach for.