We look after software that nobody else is looking after.
Most companies with software in people's hands 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, and 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.
- If it's broken
- Same working day
- To stop
- A month's notice, no lock-in
- Where we are
- Canada
- To start
- A free audit
If it's already breaking, we fix that first.
- Crashes and freezes
- The failures that show up in your crash reporter and the ones that never do, because the app hangs instead of crashing and people just close it.
- Hardware and connectivity
- Companion apps that lose the device, Bluetooth that reconnects badly, and state that goes stale when the app comes back to the foreground.
- Performance under real use
- Software that tests fine and degrades once there is a year of somebody's data in it. We reproduce it at that size rather than on an empty account.
- The bugs in your reviews
- Store reviews and support threads name the same faults over and over. We read them, reproduce what they describe, and fix the ones that keep recurring.
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 your software depends on it, it's in scope. Plenty of what looks like an app problem is really a server 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
We keep it working.
- We read the crash reporting and fix what it turns up
- Kept current with iOS, Android, and the libraries underneath
- Store submissions, policy changes, and the deadline emails
- The backlog of small things nobody got to
- Anything larger gets scoped and quoted on its own
Full engineering
We keep it working, and we build.
- Everything in maintenance
- Features, changes, removals, a rebrand if that's what the product needs
- Releases, and the smaller web work around it
- Nothing quoted separately unless it's genuinely large and 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.
There are things we don't do.
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.
Questions we get.
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 it 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 often answer outside those hours too, evenings and weekends included, though the same working day is what we commit to.
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.
Where are you based?
We're in Canada and we work with companies across Canada and the United States. The engineering is done by us, and we don't pass it to another company.
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 software 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.