How to tell whether your app is maintainable, without being a developer
When you commission an app you can check everything: the schedule, the budget, the screens. Everything except one thing, and it is the one that decides whether the app lives three years or six months.
It is called maintainability. It appears on no mockup and is invisible on delivery day. There is still a simple way to assess it, with no technical skill at all.
Why it is invisible
Take gravity. You cannot see it, you would struggle to explain it properly, and yet you know for certain it is there: you drop something, it falls.
You never observe it directly. You read it through its consequences.
Maintainability works the same way. You only need to know which consequence to watch.
The test is one question
Every app gets bugs. An operating system updates, a third-party service changes a rule. The bug is not the signal. The signal is what happens right after.
At the next bug: is it fixed quickly, and without creating others elsewhere?
You can ask this of a contractor, an agency, an in-house developer, and it applies to code written with an assistant like Claude Code. It depends on no technology.
The three possible answers
| What you observe | The decision |
|---|---|
| Fixed in hours, nothing else moves | Carry on. Your contractor is an asset |
| Fixed fast, but something else breaks right after | Audit before committing to any new feature |
| Slow to fix, and the fix brings more | Get a takeover quoted. See taking over a failed app |
The second case is the dangerous one: it looks like the first for months.
The symptom that always comes second
Nobody dares ship an update anymore. The improvement is ready, it has been waiting for weeks, and it does not go out because the last time somebody touched something, something else fell over.
An app does not die at once. It dies when the cost of touching it exceeds the expected gain. If your last update is more than six months old with no commercial reason, the test has already answered.
Seven words so nobody can talk over your head
You do not need to code. You need to recognise whether the person in front of you genuinely maintains the app.
| The word | What it means | The question that goes with it |
|---|---|---|
| Regression | Something that worked before and stopped working after a change | ”How do you catch a regression before I do?” |
| Unit test | Checking one rule on its own, without launching the app: the price calculation, the cancellation rule | ”Do your tests cover the screens, or the business rules?” |
| End to end test | Replaying a full journey, from opening the app to paying, like a real user | ”How many journeys are replayed before each release?” |
| Continuous integration | The chain that builds and tests on its own, on every change | ”What happens when it fails?” |
| Coupling | Two parts of the app tied together, so touching one breaks the other | ”If we change the payment screen, what else can move?” |
| Clean architecture | Business rules kept apart from the screens and the database | ”Can changing a screen alter a calculation?” |
| Technical debt | What was not done properly and will be repaid later, with interest | ”What did you leave aside to hit the deadline?” |
If the answers come back within a minute and contain numbers, that is a good sign. If they come back as jargon, that is not maintainability, that is presentation.
How we hold this on our own apps
Maintenance depends on nobody’s availability. It is scheduled and runs by itself, every week, on every repository.
| When | What runs |
|---|---|
| Monday | Architecture patrol: one feature checked per run against the project’s reference kit |
| Wednesday | Code health: static analysis, a tool that reads the code without running it and flags what will break |
| Thursday | Continuous integration watch, with automatic repair when it breaks |
| Before every release | 30 to 50 end to end tests replayed, looping until zero failures |
What makes a clean fix possible
Three things, and they hold together.
Business rules are tested one by one. These are the unit tests. We put them where being wrong is expensive: the price calculation, the cancellation rule, access rights. Not on buttons, which change all the time.
Full journeys are replayed on builds close to the ones that ship. An end to end test run on a development build proves very little: that is not what your users will install. This is the detail that separates a reassuring test suite from a useful one.
The code is split feature by feature, with the business rules kept apart from the screens and the database. That is clean architecture. For you it translates into one sentence: changing the design of a screen cannot alter a calculation, and a fix stays local.
This is not an aesthetic choice. It is exactly what lets you answer “yes” to the test repeatedly, rather than once by luck.
The products on this routine: UpDrive (more than 1,000 drivers, 4.9 on iOS), BeeDone (Product Hunt Top 5, first revenue on day nineteen, 18 languages), Muse Otter and Mindowl. The last two are not fully in production yet, and they follow the same routine: it does not depend on the product’s commercial success.
What to require at the quote stage
- The test, written into the contract: a fix deadline for a blocking defect, and a commitment that a fix does not degrade the rest.
- Accounts and code in your name. A contractor who refuses is one you will not be able to leave.
- The ability for a third party to take over. The only objective proof that an architecture is clean.
- The number of automated tests, given as a figure.
These four cost nothing to ask and filter a large part of the market before signature. The scoping questionnaire covers them, and the scope of a delivered app is on the mobile app page.
In short
- Maintainability is invisible like gravity: you read it through its consequences.
- The test is one question, at the next bug: is it fixed fast, and without creating others elsewhere?
- The second-order symptom is updates stopping. More than six months without moving, with no commercial reason, and the answer is known.
- Seven words are enough to hold the conversation: regression, unit test, end to end test, continuous integration, coupling, clean architecture, technical debt.
- Three things make a clean fix possible: unit tests on the business rules, end to end tests replayed on builds close to production, and code split feature by feature.
- On our side maintenance is scheduled and automatic, and 30 to 50 end to end tests run to zero failures before every release.
- Four requirements for the quote: fix deadline, ownership of accounts and code, third-party takeover, number of automated tests.