App Maintenance Plan

Why does an app need a maintenance plan?

An app is not finished at launch. Frameworks release security patches, third-party APIs change their authentication and deprecate endpoints, Apple and Google change what the stores accept, and browsers change what they allow. An app that nobody maintains does not stay the same; it slowly stops working, and the first anyone hears of it is a customer who cannot log in.

Annual maintenance runs from 15% of the build cost. That is a fact about software, not a fee we invented, and the only question is whether it appears in the quote or arrives as a surprise. We quote it as a line item with every build we scope, next to the build price, so the total cost of ownership is on the page before you commit.

How is the plan priced?

The plan is priced from 15% of the build cost per year and billed as a monthly fee. On a $30,000 build that is from $4,500 a year + GST. A web app or client portal from $12,000 + GST, an internal tool from $8,000 + GST and an iOS and Android app from $18,000 + GST each carry the plan at the same percentage, scaled to what was built.

The figure depends on what the app depends on. An internal tool with one read-only connection and no public surface is the starting price. A portal with two integrations, customer financial data and Privacy Act obligations, or a mobile app that must track two operating systems and two store review processes, sits above it. The figure is fixed in the build quote and reviewed only when the app changes materially.

What does the plan include?

Every inclusion is named in writing. The plan is structured the same way as the website care plan and the integration support retainer: a monthly fee, a list of what is covered, and nothing that is vaguely implied. The standard inclusions are:

• Updates. Framework, dependency and security updates applied monthly, each one run through the handover test suite before it is deployed. The CI pipeline refuses a release that fails a test, so an update never ships on hope.
• Monitoring. Uptime and error monitoring with a named response window, so you hear about a failure from us and not from a customer.
• API change response. When a system you integrate with rotates credentials, changes an endpoint or alters a rate limit, the contract tests catch it and the fix is covered.
• Store compliance. For iOS and Android apps, the operating system and store policy updates that Apple and Google require, and the release builds that follow them.
• Backups. Backup verification and a restore test on a fixed schedule, because a backup that has never been restored is a guess.
• Small changes. A named monthly allowance of small changes: a field added to a form, a report column, a wording fix. The allowance is stated in the plan, and unused allowance does not accrue.
• Reporting. A monthly note of what changed, what was tested, and what the third-party APIs billed, so usage costs are visible as they grow.

New features, redesigns and new integrations are not maintenance. They are scoped and quoted separately, built against the existing test suite, and they extend it.

Why is the test suite the point?

Every build above the discovery and prototype sprint ships with an automated end-to-end suite, contract tests against every integrated service, and a CI pipeline that gates deployment on them. Test automation and release assurance are included in every build price, never an optional line, and the maintenance plan is where that decision pays back.

A dependency update on an app without tests is a risk someone has to take by hand, screen by screen, and it is why maintenance on untested apps is expensive and irregular. With the suite in place, an update is run through the pipeline, the failures are specific, and the fix is small. That is what lets the plan be priced as a predictable monthly fee rather than as open-ended billing for whatever broke.

What about lock-in and ownership?

There is none. The plan is month-to-month, cancellable with a month of notice, and there is no initial term. Because the repository, the test suite, the CI configuration, the hosting and the store accounts are in your name from the day the build starts, cancelling changes nothing about what you hold. Another developer can pick up the runbook and the tests and continue; that is what the handover documentation is written for.

Third-party costs stay separate and visible. Hosting, API usage and app store developer programs are billed by those providers, named in the plan, and who pays is settled in writing before it begins. The monthly report shows what the APIs billed, so a quiet app that starts to grow does not surprise you with a four-figure usage bill.

Next step

If we built your app, the plan is already on your quote.