Build and run: why we do not hand over the keys and vanish
Our tagline is four words: we build software, then we run it. The second half is the part most people skip when they think about what a software project costs. So this is the piece where we make the case for it.
Software is not a deliverable
The agency model treats software like a building. You agree a scope, they build it, you sign it off, they hand you the keys, and everyone moves on. That works for a building because a building mostly stays where you left it. Software does not.
The day your app goes live is the day the clock starts, not the day it stops. Apple ships a new iOS and something that worked yesterday now crashes on launch. Google changes a Play Store policy and your listing gets pulled until you comply. A library you depend on gets a security advisory and you have a window to patch it. A payment provider deprecates the API you built on and gives you ninety days. None of this is in the original scope. All of it is now your problem.
So when a studio hands over a finished app and disappears, what they have actually handed you is a maintenance job you did not ask for and are not set up to do. The invoice says “delivered”. Reality says “your turn”.
The year after launch is the hard part
Building the first version is the fun bit and, honestly, the easy bit. You have a clean slate, a clear idea, and no users yet to break anything. Anyone competent can get an app into the store.
The hard part starts once it is out there and has to keep working while the ground moves under it. Dependencies rot. Certificates expire. The server that hummed along at ten users behaves differently at ten thousand. A tiny edge case you never saw in testing turns out to be how half your users actually hold the phone. And somewhere in there is the 3am fix, the one where a scraper you rely on changes its markup, or a webhook stops firing, and the app is quietly broken for everyone until someone who understands it goes and sorts it out.
That someone has to know the codebase, have the keys, and care. A studio that vanished at handover is none of those things. You are left ringing round for a freelancer to reverse-engineer a system they have never seen, under pressure, while it is down.
We feel the cost ourselves
This is not a theory we sell. It is how we run our own products.
Kerbnow reads UK parking signs with a phone camera and tells you whether you can stop. RHUL Mobile runs the bus times and campus life for a university. We built both, and we run both: the decode pipeline, the billing, the scrapers behind the timetables, the servers, the store listings, the lot. When a term-date changes or a bus operator quietly reshapes their API, that is our 3am, not a client’s.
That matters for one honest reason. We pay the maintenance bill on our own work, so we have every incentive to build things that do not generate 3am calls in the first place. A studio that ships and leaves has the opposite incentive. Their cost ends at handover, so nothing pushes them to build for the long haul. Boring, well-chosen dependencies, sensible logging, the thing that pages us before the user notices, the piece you can actually understand at 3am when you are half asleep. We build that way because we are the ones who get paged.
What it means for a client
We take a handful of client projects a year, not because we are precious about it, but because running software properly takes real ongoing attention and there is only so much of it. When we take one on, we build it the way we build our own, and then we keep running it for as long as you need us to. Updates, monitoring, store submissions, the fix when something breaks.
The point is not that you are locked in. You are not. The point is that the person who knows how the thing works is still around, still holds the keys, and is on the hook when it matters. That is worth more than a lower build quote and a phone that goes to voicemail the first time the app falls over.
Anyone can build you an app. Fewer people will still be there in a year to make sure it is still working. We would rather be the second kind.