The Build Finished and Nobody Is On Call: Software Maintenance After Launch

Key Takeaways

What actually arrives after launch, the published deadlines that become your work, and the clauses that put someone on call before you need one.

• The cliff at launch is contractual, not technical. The build contract ends and the obligations do not.
• Post-launch work is four separate queues. Calling all four “maintenance” is why three of them get dropped.
• Google Play required apps to target Android 16 from 31 August 2026, with extensions available only to 1 November 2026.
• PostgreSQL supports a major version for five years, then releases a final minor version and stops.
• Google’s SRE team states that “100% is probably never the right reliability target,” which makes your uptime number a budget decision.

“The agency crushes one project, then disappears for a month.” That line comes from a published list of startup complaints about development agencies, and it is the most accurate description of the problem available.

Nothing broke. The build shipped, the invoice cleared, and the team moved to the next client. Then a certificate expired, or a platform changed a requirement, and the question of who fixes it had never been answered in writing.

Here is the frame that fixes it. Launch is a handover, and the obligations that start at launch belong to four different queues with four different urgencies. Name the owner of each queue in the contract, before the first incident, because the first incident is when you discover nobody has the answer.

Treat launch as a handover, not a finish line

The cliff is in the contract, not the code. Most build agreements define completion as delivery and say nothing about the week after.

Quick Verdict: Decide who is on call before you launch, and put it in writing with a response time attached. Velcod covers this as part of web application development, and the ongoing side of it looks like mobile app maintenance whatever platform you shipped on.

Call it THE HANDOVER CLIFF. A build contract has a scope, a price and an end. The obligations that begin at launch have no end, which means they cannot be covered by the same document.

That gap is where founders lose weeks. The build team is contractually finished and professionally willing, which produces a response time of whenever they are free. A willing vendor with no obligation is not an on-call arrangement.

The fix is small and almost nobody does it. Write the post-launch arrangement as a separate agreement with its own start date, so launch day is a transition between two documents rather than the end of one.

Do this: Open your build contract and find the sentence that defines completion. Whatever comes after that date is currently nobody’s job.

Name the on-call owner before you need one

One named human, one phone number, one response time. Everything else is detail.

A rota with three names and no hours is not a rota. The question an on-call arrangement answers is narrow: if the product is down at 2am on a Saturday, who gets woken, and how long until they answer. Write the answer down and test it once.

Test it by paging the rota on a quiet Tuesday. You are not checking whether the system works. You are checking whether the person who is supposedly on call knows they are on call, which is a different question and fails more often.

The second thing to write down is what they are allowed to do. An on-call engineer who can see the problem but cannot deploy a fix is a monitoring service. Our case studies name the escalation path because it is the part clients ask about after the first incident, not before.

Do this: Write one sentence naming who is on call this week and how fast they answer. If you cannot write it, you have no cover.

Split maintenance into four queues

Four queues, four urgencies, four owners. The word “maintenance” hides all of that, which is why the invisible three go unfunded.

Call it THE FOUR QUEUES. Incidents are the only one most founders plan for. The other three arrive on schedules set by other people and are the ones that cause the outage you then treat as an incident.

Queue	What arrives	Urgency	Usually owned by
Incidents	Outages, errors, data problems	Hours	Someone, if you named them
Platform deadlines	Store requirements, API changes	Months of notice, hard dates	Nobody
Dependency expiry	Runtime, database and library end of life	Years of notice, hard dates	Nobody
Product changes	New features, copy, pricing	Your roadmap	You

The pattern is consistent and slightly absurd. The queues with the most warning get the least attention, because warning with no owner is the same as no warning.

A quarterly hour spent reading the middle two columns is the cheapest work in this article. It is also the work that gets skipped, because nothing is currently broken.

Do this: Put the four queue names in a document and write a person’s name next to each. Blanks are your actual maintenance risk.

Your roadmap is not the only calendar

Other people publish dates that become your work. They do not ask, and they do not wait.

Google Play’s target API level requirements page, last updated 16 October 2026, states that starting 31 August 2026 “New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play.” It adds that “Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app’s target API level.”

Note the consequence Google states plainly: “Out-of-date apps are unavailable to new users of devices that run newer versions of Android.” Your app is not removed. It quietly stops reaching new customers, which is harder to notice and worse for a startup.

Apple runs the same pattern on its own calendar. Since 28 April 2026, Apple requires that “Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26.” If you shipped cross platform, that requirement lands on your framework version first, which is why the choice between FlutterFlow or React Native keeps mattering long after launch.

Do this: Check your app’s target API level and build SDK today. The Google Play extension window closes on 1 November 2026.

Dependencies expire on a published schedule

Every layer under your product has an end of life date, and most of them are public.

PostgreSQL’s versioning policy is explicit: “The PostgreSQL Global Development Group supports a major version for 5 years after its initial release. After this, a final minor version will be released and the software will then be unsupported (end-of-life).” Minor fixes land “at least once every three months,” and the project recommends “that users always run the current minor release associated with their major version.”

Runtimes run shorter. Node.js states that major versions “enter Current release status for six months” and that LTS status “typically guarantees that critical bugs will be fixed for a total of 30 months.” The project is direct about what to run in production: “Production applications should only use Active LTS or Maintenance LTS releases.”

Certificates are tightening faster than either. The CA/Browser Forum’s Ballot SC081v3 describes an “Eventual reduction of maximum validity period from 398 days to 47 days,” with reductions “proposed to occur starting in March 2026 and concluding in March 2029.” A 47 day certificate cannot be renewed by a person who remembers.

Layer	Published window	What happens at the end
PostgreSQL major version	5 years from initial release	A final minor release, then unsupported
Node.js LTS	About 30 months of critical bug fixes	No further fixes, production use discouraged
TLS certificate	398 days today, 47 days proposed by March 2029	The site stops being trusted
Google Play target API	Annual, with a dated extension window	Out of date apps stop reaching new users
Apple build SDK	Annual, tied to the current Xcode	Uploads are rejected

Do this: Write down the end of life date for your runtime and your database, and whether certificate renewal is automated. Three facts, one afternoon.

The bill that keeps arriving

Running costs are a maintenance queue too, and they move without anyone shipping anything.

Usage grows, so metered services grow with it. The founders who get surprised are the ones who budgeted the build and treated hosting as a rounding error, then watched it stop being one as the product worked.

AI features change the shape of this most. A model call is a per-request cost that scales with success rather than with engineering effort, so a feature that works harder costs more every month it works. That is a maintenance obligation rather than a build cost, and cutting LLM costs is ongoing work rather than a one-time optimization.

The honest version of this is a monthly number you look at. Not a dashboard nobody opens, and not an alert threshold set at a figure that would already be a problem.

Do this: Open last month’s bill and the bill from four months ago. If you cannot name what changed, that is the finding.

Decide what down means before it is down

Pick the number first. Arguing about whether an incident counts, during the incident, is the expensive way to do this.

Google’s SRE team is blunt about the target. Their guidance states that “100% is probably never the right reliability target,” and that “past a certain point, however, increasing reliability is worse for a service (and its users) rather than better!” The reason is cost: “cost does not increase linearly as reliability increments,” and “an incremental improvement in reliability may cost 100x more than the previous increment.”

What you promise	What it costs you	Who needs it
Best effort, business hours	Almost nothing	Internal tools, early products
99% monthly	A rota and alerting	Most consumer products
99.9% monthly	Redundancy and real on-call	Products customers run their work on
Higher	A team, not a contract	Rarely a startup

The useful mechanism is the error budget. Google defines it as a quarterly figure derived from the objective, where “The difference between these two numbers is the ‘budget’ of how much ‘unreliability’ is remaining.” Its real function is political: “An error budget aligns incentives and emphasizes joint ownership.”

Enterprise buyers force this conversation whether or not you have had it. Procurement asks for an uptime commitment in the contract, which is why anyone selling a B2B SaaS MVP ends up picking a number under time pressure rather than at leisure.

Do this: Write down your monthly uptime target and what counts as down. One paragraph, before anyone asks you for it.

Write the support agreement around the four queues

A support agreement that says “maintenance” buys you the first queue and none of the others. Name all four.

Five clauses carry it. A response time per severity level, with a named on-call owner. Platform deadline work included by name, so store requirements are covered rather than quoted. A quarterly dependency review with a written output. A stated monthly hour allowance for changes, with overflow priced in advance. And the handover terms, so ending the agreement does not repeat the original problem.

The second clause is the one to argue for. Platform deadline work is predictable, dated and non-optional, so a vendor who scopes it as a separate project each time has an incentive you do not share.

Price the agreement as a monthly figure rather than an hourly rate wherever you can. Hourly billing makes every call a decision, and the calls people avoid making are the ones that turn into incidents. A good mobile app development company will quote this before you ask, because the ones who have done it know the first incident is the moment the relationship is tested.

Do this: Take the five clauses to your current vendor and ask which ones they already cover. Their answer is the quote.

What this will not fix

An agreement buys you a response. It does not buy you a product that needs fewer responses.

A fragile build generates incidents faster than any rota can absorb, and no support contract converts that into a stable one. If your incident rate is high, the work is in the product, not in the agreement.

Published dates also change. Google’s own page carries an extension path to 1 November 2026, and the CA/Browser Forum ballot describes its reductions as “proposed,” which means the calendar you write down this quarter needs rereading next quarter.

And none of this tells you the right uptime number. Google’s guidance deliberately refuses to name one, because the answer depends on what your customers do with your product. Anyone selling you 99.99% without asking that question is selling you redundancy you may not need.

The handover checklist

Eight items, all answerable in an afternoon. Do them before launch if you can, and this week if you already launched.

• Name the person who is on call, and the response time they owe you.
• Confirm that person can deploy a fix, not just see the problem.
• Write down the four queues with an owner against each.
• Check your app’s target API level and build SDK against the current requirement.
• Record the end of life date for your runtime and your database.
• Confirm certificate renewal is automated, not calendared.
• Compare this month’s metered bill against four months ago.
• Write your monthly uptime target and what counts as down.

We hand this list over at the end of every project, including the three-week MVP builds where the temptation to treat launch as the finish line is strongest.

Where we fit

We build, and we also run what we build, which means we have an interest in selling you a support agreement. Worth saying before anything else.

What we do about it is quote the four queues separately, so you can buy the ones you need and decline the rest. Most clients take incidents and platform deadlines, handle product changes themselves, and ask us for a quarterly dependency review. That is a reasonable shape and it is cheaper than the full version.

This is not always the right purchase. If you have a technical cofounder, you need alerting and a runbook rather than a retainer. If your product is internal and a day of downtime costs nothing, best effort during business hours is the honest answer.

If you want the eight-item list filled in for your product this week, book a call with us and bring whatever access you have.

Frequently Asked Questions

How much should software maintenance cost per year?

It is usually quoted as a monthly retainer tied to response time and included hours, not as a percentage of the build. Ask for the four queues priced separately so you can see what you are actually buying. A figure quoted with no response time attached is a guess, because response time is the cost driver.

What is the difference between maintenance and support?

In practice, support means answering incidents and maintenance means keeping the software current. Most agreements blur them, which is how platform deadlines and dependency upgrades fall out of scope. Ask for both words to be defined in the contract, with the four queues named individually rather than bundled.

Do I need a support agreement if nothing is broken?

Nothing being broken is the normal state before a published deadline arrives. Google Play required Android 16 targeting from 31 August 2026 and PostgreSQL stops supporting a major version after five years, and neither waits for your product to break first. The agreement covers dated obligations, not just failures.

Can my original build team handle maintenance?

Often yes, and the question is whether they have an obligation rather than goodwill. A willing vendor with no contractual response time will help you when they are free, which is not the same as being on call. Put a response time and a named owner in writing, with the same team if they will sign it.

What uptime should a startup promise?

Lower than you think, and deliberately. Google’s SRE guidance states that “100% is probably never the right reliability target” and that each additional increment can cost far more than the last. Most early products are well served by 99% monthly with a clear definition of down. Enterprise contracts are what move the number.

Resources

• Embracing Risk, Google SRE. The reliability target argument, the error budget mechanism, and the statement that each increment of reliability can cost 100 times the previous one.
• Meet Google Play’s target API level requirement, Android Developers, page last updated 16 October 2026. The 31 August 2026 requirement, the API level thresholds, and the 1 November 2026 extension window.
• SDK minimum requirements, Apple Developer, in force since 28 April 2026. The Xcode 26 and OS 26 SDK requirement for anything uploaded to App Store Connect.
• Node.js Releases, OpenJS Foundation. The six-month Current phase, the 30-month LTS guarantee, and the instruction to run only Active or Maintenance LTS in production.
• Versioning Policy, PostgreSQL Global Development Group. The five-year major version support window, the quarterly minor release cadence, and the upgrade requirements.
• Ballot SC081v3, CA/Browser Forum. The proposed reduction of maximum certificate validity from 398 days to 47 days between March 2026 and March 2029.