Software Studio
We are a small studio with a strong point of view. We believe the best software disappears into the background — and what remains is a person, empowered to do something they couldn't do before.
These are not principles we display on walls. They are the things we actually argue about when deciding how to build something — refined over years of watching what works, and what quietly fails.
01
Most software announces its own existence constantly — notifications, modals, nudges, prompts. It treats the user as someone to be managed. We build the opposite. Software that knows when to step back, that earns its place on the screen, and that leaves the person using it feeling capable rather than interrupted. That takes restraint. Restraint is harder than features.
02
When software is confusing, people blame themselves. They feel stupid. They click around hoping something works. This is a failure of design — not a failure of the user. Our obligation is to absorb complexity internally so that none of it spills onto the person we're building for. Simple interfaces are not simpler to build. They require more thought, more iteration, and more willingness to cut what you spent weeks building because it made the whole thing harder to understand.
03
Speed is not a virtue in itself. The pressure to ship fast has given us a world full of brittle, half-considered products that solve yesterday's problem with tomorrow's deadline. We take time to understand what we are building and why — before we write a single line. Not because we are slow, but because the time spent understanding is exactly what makes the time spent building count for something.
04
It is easy to fall in love with a technical solution — an elegant architecture, a clever algorithm, a framework you have been wanting to try. We stay suspicious of that love. A grandmother opening a government portal. A first-generation entrepreneur tracking inventory. A nurse at the end of a twelve-hour shift. These are the people whose lives are changed — or wasted — by the quality of software. That responsibility is the reason we do this work.
We don't believe in service catalogues. But here, as honestly as we can say it, is what we spend our time on.
01 — Development
We write software that does what it is supposed to do — and stops there. No unnecessary abstractions, no over-engineered architecture, no features nobody asked for. We work across the stack: web, mobile, APIs, data. Our code is meant to be read by the next person who works on it, not just executed by a machine. Good software is maintainable software.
02 — Innovation
An idea that survives contact with real users is a rare thing. We help take ideas through that crucible — from rough concept to something a person can actually hold. We ask hard questions early, prototype fast, and don't fall in love with directions that don't serve the people at the end of the line. A good product is a hypothesis confirmed.
03 — Impact
We build software that travels — across languages, contexts, connection speeds, and expectations. We know what it means to design for users who don't look like early adopters. We have built for communities where the stakes of bad software are not inconvenience but access — to healthcare, to livelihoods, to participation in systems that matter.
We have more software than we have ever had. It is faster, shinier, more connected, more capable — and somehow, still, most of it gets in the way. We keep building more, hoping more will fix it. It won't. What is missing isn't quantity. It's care.
92%
of software projects fail to meet real user needs — not because of technology, but because of assumptions made before the first line was written
3.5B
people online who were never consulted when most of the software they depend on was designed for or around them
1 rule
if it doesn't make someone's life measurably better, we don't build it — simple to say, genuinely hard to hold, worth holding
Always
the first question before any project: who is this actually for, and do we understand them well enough to help without causing harm?
We start by listening — to you, to your users, to the context this will live in. We ask questions that seem obvious but usually aren't. We don't touch code until we understand what we're trying to do and, more importantly, why.
Every decision has a reason behind it. Interfaces are shaped by what people actually need to do — not by convention, not by what is fashionable. We argue productively about the small things, because the small things are where experience actually lives.
You're not waiting for a reveal at the end. You see the work as it takes shape — with context, not just screenshots. If something isn't working, we'd rather know early. We build incrementally and share frequently.
We don't hand off and disappear. Going live is the beginning of learning, not the end of the project. We watch how things land, stay close through the early days, and hold ourselves accountable to what was promised at the start.
Not aspirations. These are commitments we have made costly decisions to honour over the years.
I
We tell you what we actually think — about the idea, the timeline, the direction. Comfortable agreement is easy. Honest collaboration is what builds something worth building. We'd rather be trusted than liked.
II
Caring about the work means caring about the things most people skip. The loading state. The error message. The edge case at 2am. These are not extras — they are where the experience actually lives. Attention is the craft.
III
Removing something takes more courage than adding it. We are willing to do the harder work of taking things away — to protect the clarity of what remains. Simplicity is not a style choice. It is a moral one.
IV
We build things we would be willing to maintain. We make decisions we could explain to someone five years from now. We are not interested in impressing anyone in the short term at the cost of something that lasts.
We take on a small number of projects at a time. That's deliberate — it means we can give the work, and the people behind it, the attention they deserve. If what you're building sounds like something we'd care about, let's talk.