Ongoing engineering
We look after software that nobody else is looking after.
Most companies with an app don't have anyone whose job it is. It got built, it shipped, and whoever built it moved on.
Nothing breaks straight away. It drifts. Dependencies age, the operating system moves underneath it, small failures collect in crash logs nobody reads. By the time it's obviously broken it has been broken for a while.
We take that on. Monthly, ongoing, as the people responsible for it rather than the people you call when it's already gone wrong.
Concretely, here's what someone is doing every month once we're on it.
- Crashes and errors
- Someone reads the crash reporting every week. Most of what we fix, we find there before anyone opens a support ticket about it.
- OS releases
- iOS and Android betas get tested against your app while they're still betas, so the things that break get fixed before your users are the ones finding them.
- Dependencies and security
- Libraries age whether or not anyone touches the app. Patches get applied, and the ones that need a real migration get flagged early instead of at the point they're urgent.
- The stores
- Submissions, policy changes, deadline notices from Apple and Google. The emails that sit in someone's inbox until they become a problem.
- Bugs
- Ranked by how many people actually hit them, not by who complained loudest. Sometimes the answer is that a bug isn't worth fixing, and we'll say so.
- Backend and API
- Where the app depends on it, it's in scope. Plenty of what looks like an app problem isn't one.
- Small features
- The changes that are too small to be a project and never get done because of it. Copy, a setting, a screen that should have been there.
- A written record
- What changed, why, and what we decided against. It lives in your repo. If we stopped tomorrow, nothing about your software would only exist in our heads.
Same people either way. The difference is how much of the product we take on.
Maintenance
Everything above. We watch it, fix what breaks, keep it current with the platforms, and work through the backlog of small things nobody got to. Anything larger gets scoped and quoted on its own.
Full engineering
Everything above, and we're the ones building too. Features, changes, removals, a rebrand if that's what the product needs. Releases, and the smaller web work around the app. Nothing gets quoted separately unless it's a genuinely large piece of work outside the product.
Which one you need is usually obvious once we've read the codebase, which is the other thing the audit is for.
You shouldn't have to manage us.
This is the part that makes it work, and it's the part most arrangements get wrong. If you have to decide what we work on, brief it, and chase it, then you haven't got an engineering team. You've got another thing to manage.
So we run it the other way round. We tell you what we're picking up before we start. If you disagree, you say so and we don't. Anything larger gets a short note first setting out what it touches, so you can read it in two minutes instead of working it out yourself.
The audit, before anything else
We won't quote ongoing work on a codebase we haven't read. The audit is free and it exists so both of us know what we're agreeing to. Some of them end with us telling a company they don't need us yet.
The first month is the heavy one
Getting access, getting builds running, reading the code properly, and clearing whatever's actually on fire. Expect more noise from us in month one than in month four.
Then it settles into a rhythm
Work gets picked up, shipped, and written down. Once a month you get a plain summary of what changed and what we think is coming.
Not a helpdesk
If what you want is somewhere to send bug reports and get a ticket number, there are cheaper options and you should take one.
Not hours in a bucket
We don't sell a block of hours and count them down. It turns every conversation into a negotiation about whether something is worth spending them on.
Not firmware
We work up to the edge of the hardware, not past it. Embedded and real-time work on a device needs a lab we don't have, and we'll say so rather than learn on your money.
We already have a developer. Does this still make sense?
Sometimes. If you have someone who is actively in the codebase every week, probably not, and we'll tell you that. What we see more often is a company with technical people whose attention is somewhere else, and one piece of software that isn't anybody's job. That's the gap we fill.
What if the app was built badly?
Then we'd rather know before we quote, which is what the audit is for. A bad codebase isn't disqualifying. It changes what the first few months look like and it changes the price, and both of those are better discussed up front.
How fast do you respond when something is actually broken?
If it's broken for your users, the same working day. Everything else, the next working day. We don't offer 24/7 and we'd be lying if we did.
Do we have to hand over the whole codebase?
For ongoing work, yes, we need real access. For the audit, no. We can tell you a lot from the outside, and plenty of clients start there before deciding whether to give us anything.
Is this mobile only?
No. Mobile is where most of our work has been, but web apps, customer portals and the services behind them are the same job. If it's customer-facing and nobody's looking after it, it's the same problem.
What if we want to stop?
You give us a month's notice and we stop. There's no lock-in, and the handover documentation is written as we go rather than assembled on the way out.
What does it cost?
It depends on which of the two arrangements above you need and what state the software is in, which is why the audit comes first. We won't put a number on a codebase we haven't read, and we don't sell hours. Once we've been through it we'll tell you which one fits and what it costs.
Send us the app and we'll tell you what we find.
The audit is free and it's the honest way into this. You get a real read on the state of your software whether or not you ever hire us.
Reply within one business day.