◆ SIMNETIQ / 03 / W-04MONITORING · MAINTENANCE · ITERATIONENGAGEMENT TERM
W-04

We staypast launch

Monitoring, maintenance and the next iteration are planned in, not bolted on.

Shipping is the middle of the job. An app that went live and then broke quietly three weeks later was not delivered — it was abandoned on schedule. Observability and deployment automation go in from day one, and what happens after launch is agreed while there is still time to build for it.

In practice

What this means

At a glance

Ships with every buildMonitoring · CI/CD
Support scopeDefined and time-boxed
If support lapsesNothing switches off
01

What ships on day one

Every project goes live with error tracking, uptime monitoring and a CI/CD pipeline already wired in, because retrofitting observability after an incident means finding out what broke by guessing. These are not upsells added at the end of the SOW. They are part of the build, for the same reason tests are.

02

What maintenance actually covers

Defect fixes in what we built. Dependency and security updates. Platform churn — an iOS or Android release that deprecates something you depend on, an API version a vendor retires, a certificate that expires. Reacting to alerts from the monitoring that shipped with the project. This is the unglamorous work that decides whether software is still running in two years.

03

What ends when an engagement ends

Support is scoped and priced like everything else, so it has an end date and you can see it. It is not an automatic monthly charge that continues until someone notices. When a support period ends, the software keeps running — you hold the source, the infrastructure and the documentation, so nothing switches off and nothing needs renewing to stay live. New features are quoted as new work rather than absorbed into a maintenance line.

04

App Store and Play review

Store review is not a one-time event. Apple and Google change requirements, reject builds for reasons that did not exist last year, and periodically remove apps that have not been updated for a current SDK. If we submitted your app, we handle the resubmission cycle during the support period rather than sending you the rejection email to interpret.

05

The next iteration

Most useful software changes after real users touch it. We would rather scope a second phase against what actually happened — the monitoring data, the support tickets, the features nobody used — than build everything anyone imagined in phase one. Launch is the point where you finally have evidence, and it is the cheapest moment to change direction.

Questions

Common questions

What does support cost after launch?

It is quoted per engagement against a defined scope, in the same SOW or a short follow-on one, because the honest answer depends on what was built and what it runs on. What it is not is an open-ended retainer with no stated deliverable.

What is covered by maintenance and what is a new project?

Maintenance covers defects in what we built, dependency and security updates, platform and OS changes, and responding to monitoring alerts. A new feature, a new integration or a redesign is quoted as new work — it gets its own scope and price rather than being absorbed silently.

What happens if I stop paying for support?

Nothing switches off. You hold the source, the infrastructure accounts and the documentation, so the software keeps running exactly as it did. You would be responsible for updates and incidents from that point, and you can come back for a specific fix without a standing arrangement.

Do you monitor the app, or do I have to tell you when it breaks?

Error tracking and uptime monitoring ship with the project, so during a support period the alert usually reaches us before you notice. Outside a support period the monitoring still runs and still alerts — it is in your account — it just alerts you.

Who handles App Store rejections and OS updates?

We do, during the support period, if we submitted the app. Store requirements and SDK minimums change on Apple's and Google's schedule rather than yours, so this is treated as ongoing work rather than a one-off submission.

How fast do you respond to a production incident?

Same working day for anything taking a live system down. Routine issues are handled within one working day. Response expectations are written into the support scope rather than left as an understanding.

Contact Us

Still have a question?

Ask it before you commit to anything. Briefs and questions are answered within one working day, by the engineer who would do the work.