ViewSynapse Digital
A row of workstations at the far end of a product team's desk bank in cold early morning daylight, screens turned away
After launch

Maintenance and Support After Launch

A live product keeps changing underneath you: operating systems update, dependencies age, and users ask for things nobody planned for. Here is what the ongoing work usually covers, and how to budget for it before you launch.

Read how projects get built See what routine work covers
Recurring work Updates, patches and small fixes Runs continuously Store pressure Mobile apps age faster than websites iOS and Android Planning line A recurring cost, not a one-off fee Set before launch
Routine maintenance

What routine maintenance covers

Routine work is the part you can plan around: dependency updates, security patches, small bug fixes, and monitoring of the hosting or cloud environment. For a mobile app it also includes rebuilding against new iOS and Android versions, which is what keeps the app installable at all.

None of this is optional in the long run. A product left untouched for a year usually needs a period of catch-up work before it can be updated safely again, because the update paths themselves have moved. That catch-up is slower and riskier than the steady version would have been.

What the routine covers
  • Dependency and library updates
  • Security patches applied on a schedule
  • Small bug fixes reported by users
  • Monitoring of hosting and cloud services
  • Rebuilds against new mobile OS releases
A mobile handset lying face-down on a desk beside a cable while a hand works nearby in cool daylight
Websites and mobile apps

Why mobile apps need more attention than websites

Web products can be patched on the server without the user doing anything. Mobile apps cannot. Each platform sets minimum target versions, and an app that falls too far behind may be removed from the store or refuse to run on a new OS release.

Store policies move as well. Privacy disclosures, data-collection declarations and account-deletion requirements have all shifted in recent years, and each change has to be answered inside the app. A support arrangement that only covers bug fixes will not keep an app in the store.

  • Web: patch on the server No user action
  • App: rebuild and resubmit Store review
  • Policy declarations Reviewed often
Support tiers

Support tiers and response times

Support is usually sold in tiers defined by how fast someone answers and when they are available. A basic tier might cover business hours in Singapore with next-day response for non-urgent issues. A higher tier adds monitoring, faster response and weekend coverage.

The tier should match how the product is actually used. A consumer app that takes bookings around the clock needs different coverage from an internal tool used Monday to Friday. Two questions worth asking before you sign: what counts as urgent, and who decides.

Worth confirming in writing

Which failures count as urgent, who makes that call at 2am, and how the response clock is measured.

Monitoring and backups

Monitoring, backups and recovery

Monitoring tells you the product is down before your users do. Backups give you a way back if data is lost or corrupted. Both need to be set up deliberately, with a stated retention period and a restore process that someone has actually run.

A backup that has never been restored is a hypothesis, not a safeguard. For products handling bookings or payments, the recovery time objective should be written into the support agreement rather than assumed.

Change requests

Handling feature requests after launch

Real usage produces change requests. Some are small: a new field, a wording change, an extra report. Others are effectively new projects. An agreement should separate maintenance, minor changes included in the retainer, and larger work quoted separately.

Without that boundary both sides end up frustrated: the client feels nickel-and-dimed, the vendor absorbs unpaid scope. Write it down while everyone is still friendly.

Security work

Security updates and compliance drift

Security work is continuous. Libraries that were current at launch accumulate known vulnerabilities, and frameworks publish advisories that require action rather than reading. For Singapore businesses handling personal data, the obligations under the Personal Data Protection Act also apply to how the product stores and transmits information.

A maintenance plan should include a periodic dependency review and a clear owner for applying security patches. That means one named person or team, not a shared assumption. This is unglamorous work that prevents very public problems.

What a plan should name

A review cadence, the owner who applies patches, and how the team is told when an advisory affects something already in production.

A hand seating a patch cable connector into a dark rack port under cool daylight
In frame Patch work on live infrastructure
Handover

What handover should include

If you are moving from a build to an in-house team, handover should include repository access, environment configuration, deployment instructions and documentation of the architecture. If you are staying with the same vendor, the equivalent is a written record of what was built and why.

Access Repository access, hosting, domain registration and app store listings sit with the business Under your accounts
Environment Configuration notes and deployment steps someone else can follow without a call Written down
Architecture A record of what was built and why, including the decisions that were argued over Reasoning, not just diagrams
Continuity Who to call for each service, and what the vendor still holds if you leave Before the split, not after

An example of a studio whose scope depends on that record existing: SleekDigital, founded in 2017 according to a 2026 Singapore listing, lists enterprise app modernisation alongside mobile app development and custom software development. Modernisation work reads the original decisions before it changes anything.

See how to work with a team UX, UI and backend integration
Budget

Planning the budget line

Maintenance is a recurring cost, not a one-time fee. What matters is that the line exists in your budget before launch.

A common planning figure is a percentage of the original build cost per year, though the right number depends on how much the product changes and how critical downtime is to the business. A booking tool that stops taking reservations on a Saturday night carries a different weight from a brochure site that can wait until Monday.

Products that skip maintenance planning often pay more later, in emergency fixes and rushed rebuilds. The cheaper path is the boring one: a steady retainer that keeps the product current so nothing has to be rescued in a hurry.

Three things to settle before launch
  • Which tier matches how the product is really used, including weekends.
  • What is included in the retainer and what gets quoted separately.
  • Who owns the accounts, and where the documentation lives.
Questions

Common questions before signing a support agreement

Stability Do I need a maintenance contract if the product is stable?

Stability does not stop platform updates. Mobile apps must be rebuilt against new OS versions to stay installable, and web dependencies need security patches regardless of how little the product changes. A lighter contract that covers updates and monitoring is usually enough for a stable product, but doing nothing is not a real option.

Ownership Who owns the code and accounts after launch?

You should. Repository access, hosting, domain registration and app store listings should all sit with the business. If any of those are under the vendor's account, resolve it during handover. This is a common issue and it is much easier to fix before a relationship changes.

Coverage How do I choose between support tiers?

Start from when the product earns money or carries risk. If customers book, pay or check status outside office hours, weekend coverage belongs in the agreement from day one. If the product is an internal tool used Monday to Friday, business-hours response is usually the honest choice. The mistake is buying coverage you will not use and then treating the tier as a substitute for monitoring.

Scope Where does maintenance end and new work begin?

A workable line is this: keeping the product working as designed is maintenance; changing what it does is a project. A field label, a broken report or a failed payment flow belongs in maintenance. A new user role, a new integration or a redesigned checkout is new work with its own estimate. Write the examples into the agreement so the boundary is concrete rather than a matter of opinion.

Next step

Plan the period after launch before you sign off the build

If you are comparing approaches, it helps to know which questions get answered in writing and which stay vague until something breaks. Ask about coverage hours, what counts as urgent, who applies security patches, and where the documentation will live. Those four answers tell you more about a support arrangement than any summary of services.

ViewSynapse Digital is an editorial resource for teams weighing custom websites and mobile applications. We publish what the work involves so you can ask better questions of whichever team you hire. Reach us Monday to Friday, 9:00 AM to 6:00 PM, at [email protected] or on +65 6218 1116.

Support arrangements

Questions about coverage, handover or what a retainer should include are welcome. Write to us and we will answer plainly.

Ask about support arrangements Compare build approaches