Launch Day Is the Start of the Work, Not the End of It
Apps do not sit still. Operating systems move, certificates expire, APIs change and store policies tighten. A monthly retainer keeps someone responsible for all of it — with clear limits on what that does and does not cover.
- Three bands, fixed monthly fee
- Written update at the end of every working day
- Apps we did not build are welcome
Nothing Broke. The World Moved.
The most common support ticket we get is some version of “it worked last week and nobody changed anything”. That is usually true. An app is not a static object; it sits on operating systems, cloud services, payment processors and app stores that all change on their own schedules, none of which are yours.
An unmaintained app does not fail all at once. It degrades: a payment method stops working for one card type, push notifications quietly stop arriving on newer phones, then one day an OS release makes it crash on launch and you find out from a one-star review. Maintenance is the work of catching those in the order they appear rather than all at once in an emergency.
See how we run a buildSix Things That Will Happen to Your App
Not hypotheticals. These are the recurring causes behind almost every support request on a live product.
OS releases, every year
iOS and Android ship a major version annually, plus point releases in between. Each one can change permissions, background behaviour, notification handling or layout. Apple and Google also enforce a minimum SDK version for new submissions, so an app that is not kept current eventually cannot be updated at all without a migration first.
Certificates and keys expire
TLS certificates, Apple distribution and push certificates, provisioning profiles, Google service account keys, API credentials on a rotation policy. Every one has a date on it, and the failure mode is total: the app stops connecting, or stops building, on a day nobody had in the calendar. We track the dates and renew ahead of them.
Third-party APIs change
Payment processors, maps, messaging, auth providers and analytics all deprecate versions and alter response shapes. The announcement usually arrives by email to whoever registered the account, which is frequently a developer who left. Someone has to read those notices and act on them before the cutoff date, not after it.
Store policies tighten
Privacy labels, data-deletion requirements, account-deletion flows, tracking disclosures, subscription rules, age ratings. Both stores add obligations regularly and enforce them at submission time. The practical effect is that a policy change can block an urgent bug fix release until unrelated compliance work is done first.
Dependencies get vulnerabilities
Your app depends on dozens of open-source packages, each of which depends on more. Advisories are published constantly. Most are irrelevant to you; a few are urgent. The work is triage — deciding which ones actually reach your code and patching those quickly, rather than upgrading everything blindly and breaking production.
Real usage finds the edges
Databases that were quick at a thousand rows slow down at a million. A screen that assumed one image per record meets a user with forty. Storage bills climb because nothing is ever deleted. These arrive gradually and are far cheaper to handle as they appear than as a single emergency at the worst possible moment.
What a Retainer Covers — and What It Does Not
The second half of this matters more than the first. Vague support agreements are how relationships sour in month four.
Always Covered
Uptime and error monitoring with alerting. Security patching of dependencies. Certificate and key renewals tracked ahead of expiry. Bug triage and diagnosis. Compatibility fixes for new OS releases. Store resubmissions when a policy change requires one. Backup verification. A written update at the end of every working day there is activity, and a monthly summary of what was done and what is coming.
Sized by Band
Development hours for fixes and small features. How quickly we start on a critical issue. How many scheduled calls per month. Depth of performance work. Whether a staging environment is maintained alongside production. Release frequency — monthly on the smallest band, every two weeks on the largest.
Available, Priced Separately
Cloud hosting costs, which we prefer you pay directly to the provider so you can see them. Paid third-party services and SDK licences. Design work beyond small adjustments. Penetration testing. Data migrations. Tier-one end-user support, meaning replying to your customers rather than to you. App store listing and creative refreshes.
A Separate Project
A new product, a new platform, or a redesign. Any feature that needs its own discovery and design phase. Replatforming or a framework migration. Rebuilds of an entire area of the app. None of these are refused — they are quoted as fixed-price projects so the retainer keeps doing its actual job instead of quietly being consumed.
Three Sizes, Fixed Monthly
Indicative monthly figures. The band you need depends on how much traffic the app carries and how much you want changed each month — we recommend one after looking at the product, and moving between bands takes 30 days notice.
Care
$1,200 / month
Around 10 development hours. For a stable app with modest traffic that mainly needs keeping current and watched.
- Monitoring, alerting and error tracking
- Security patching and dependency triage
- Certificate and key renewal tracking
- Bug fixes within the hour allocation
- Monthly release window
- One scheduled call per month
Standard
$2,750 / month
Around 25 development hours. For a product with real users where small improvements ship continuously.
- Everything in Care
- Small feature work inside the allocation
- Releases every two weeks
- Staging environment maintained
- Two scheduled calls per month
- Quarterly performance and cost review
Scale
$5,000 / month
Around 50 development hours. For revenue-carrying products where downtime costs money and the roadmap never stops.
- Everything in Standard
- Priority position for critical issues
- Named engineer who knows your codebase
- Performance and infrastructure cost tuning
- Roadmap planning session each month
- Incident write-up after anything serious
Figures are indicative starting points, not a quote. If your app needs more than the Scale band delivers month after month, you are past maintenance and into a dedicated team — which usually works out better value. Full pricing detail sits on the pricing page.
What We Will Actually Commit To
Written in terms we can honour every week, not in terms that look impressive on a page.
| Severity | What it means | We acknowledge | We aim to resolve |
|---|---|---|---|
| Critical | The app is down, payments are failing, or data is at risk. | Within one business day, and it goes to the front of the queue. | A fix or a working workaround inside the same or next working day. |
| High | A major feature is broken for many users, with no reasonable workaround. | Within one business day. | Typically within three business days. |
| Normal | A bug affecting some users, or something with a workaround. | Within one business day. | In the next scheduled release window. |
| Low | Cosmetic issues, copy changes, minor improvements. | Within one business day. | Scheduled into planned work and confirmed back to you. |
How communication works
- A written update at the end of every working day on which something moved
- Anything you raise gets a reply within one business day, including a reply that says we are still digging
- Calls are scheduled in your morning, US Eastern, at a fixed weekly or monthly slot
- A monthly summary of work done, hours used and what we recommend next
- Working days are Monday to Friday, excluding public holidays we tell you about in advance
What we will not claim
- We do not staff a round-the-clock on-call rotation, and we will not sell you one
- Automated monitoring runs continuously and records incidents whenever they happen
- A human picks up those alerts at the start of the next working day
- If your product genuinely needs cover at three in the morning, we will say so and help you plan for it properly
- We would rather lose the deal than miss a target we promised in writing
Monitoring, Patching and the Boring Work That Prevents Emergencies
Monitoring and error tracking
Crash reporting in the app, error tracking in the backend, uptime checks against the endpoints that matter, and alerts on the handful of signals that actually indicate trouble. Alert fatigue is a real failure mode: if everything pages, nothing does. We tune the thresholds until an alert means something.
Security patching
Dependency advisories are reviewed on a schedule, not when they make the news. Anything that genuinely reaches your code is patched and released quickly; anything that does not is logged with the reasoning so the decision is on record. Framework and runtime versions are kept inside their support windows rather than allowed to drift.
Backups that restore
A backup nobody has ever restored is a hope, not a backup. We check that they run, and we periodically restore one into a scratch environment to confirm it produces a working system. This is dull and it is the single thing most likely to save a business from a bad afternoon.
Yes, You Can Change Things Inside a Retainer
A retainer is not a freeze. Most months the majority of the hours go to improvements rather than repairs.
Fits comfortably inside a retainer
- A new field, filter, sort order or export on an existing screen
- Copy, labels, translations and small layout adjustments
- A new email or push notification on an existing trigger
- An additional report or chart on a dashboard you already have
- Swapping one third-party service for another of the same shape
- Admin-panel additions that save your team manual work
Needs its own quote instead
- A new user type or role with its own permissions and screens
- Adding a platform the product does not ship on today
- Anything requiring design discovery or user research first
- Payments or subscriptions where none exist yet
- A redesign, or a change that touches most screens at once
- A data migration with a rollback plan attached to it
We estimate every request before starting it. If something will not fit in the month, you hear that first and decide whether to defer it, split it, or take it out of the retainer and quote it properly. Nothing is started silently and billed later.
Maintenance Questions
What is the minimum commitment on a retainer?
Three months to start, because the first month is largely spent learning your system and setting up monitoring, and nobody gets value from that if it ends immediately. After the initial three months it runs month to month with 30 days notice on either side. There is no annual lock-in and no cancellation fee.
Do unused hours roll over?
One month, up to half your monthly allocation. So a 25 hour plan can carry at most 12.5 hours into the following month, and anything beyond that expires. A retainer buys reserved capacity in our schedule rather than a bank of hours, and allowing unlimited accumulation would mean holding capacity we can never actually deliver.
What counts as a bug fix and what counts as a new feature?
A bug is the software not doing what it was agreed it would do. A feature is the software doing something new. If we built it and it breaks within the warranty period, fixing it is free and does not touch your hours. Everything else comes out of the monthly allocation, and if a request is too large to fit we tell you before starting rather than silently consuming the month.
Will you support an app your team did not build?
Yes, and roughly half of the applications we maintain were built by somebody else. We start with a code audit so we know what we are agreeing to look after, and the first month is an onboarding month at the same rate: monitoring, error tracking, a repeatable build and documentation, before the ongoing retainer begins.
Do you provide 24/7 emergency cover?
Automated monitoring runs continuously and records incidents at any hour, but we do not staff a round-the-clock on-call rotation and we would rather say so than sell cover we cannot honour. A human picks up alerts at the start of the next working day. If your product genuinely needs someone awake at three in the morning, we will tell you that plainly and help you plan for it.
What happens to our app if we stop the retainer?
Nothing stops working. The code, the cloud accounts and the store listings are already in your name, so there is nothing for us to switch off. We hand over current documentation, the monitoring configuration and a short written list of what will need attention in the next six months, and we remove our access.
Put Someone Responsible Behind Your Live App
Tell us what is running, who built it and what has broken recently. We will recommend a band — including the smallest one, if that is the right answer.