Annual review
Store policy pass
- — Permission prompt wording re-checked
- — Privacy manifest and data declarations reviewed
- — Listing screenshots and metadata re-read
Post-launch support · time-and-materials
Support that keeps the app working after launch
Most applications do not fail because of a bad build. They fail because the operating system moved, a store changed its rules, a dependency stopped being maintained, or nobody was watching the crash reports. This page explains what maintenance at Eclipse Holdings Group covers, how it is monitored, and how it is scoped.
Eclipse build · production
Watched window
Crash reports, OS versions and store requirements — held in one place while the rest of the bench moves.
The first weeks in production
See how triage works
What launch actually changes
Launch swaps one set of problems for another. During development, bugs come from code that was just written. After launch, they come from real users, unusual devices, network conditions and data that nobody anticipated. The first weeks in production are the most informative period of the project's life, which is why monitoring is connected before release rather than after something breaks.
Every app we ship
Sentry monitoring and error triage
Every app Eclipse Holdings Group builds connects to Sentry, which captures runtime errors with the stack trace, device, OS version and app version attached. That converts a vague report from a user into something a developer can locate in minutes. Triage works on a schedule, not on panic.
-
Attention
New errors
Something the last release introduced. Handled first: reproduced, patched, and put on the next release train.
immediate -
Attention
Frequent errors
Small things users hit often. Sometimes one line of code, sometimes a slow endpoint the app is waiting on.
same week -
Logged
Single occurrences
One crash on one unusual device. Logged with OS version and app version, and read again at the next release.
next release -
Context
Attached context
Stack trace, device model, OS version and app version ride with every report, so a ticket has a shape before a developer opens the editor.
per event -
Rhythm
Weekly read
The crash feed is read on a schedule — not only when someone complains. Silent failures get the loudest catch.
routine
The point is not the volume of alerts. It is that a report from a user becomes a specific line of code, with the device it happened on, in one place the team reads on a schedule. For teams without an in-house app maintainer in Belgium, that alone usually prevents the slow drift into a broken app.
Operating system and store updates
Apple and Google both move. Minimum OS versions rise, store policies change, permission prompts get redesigned, and submission requirements shift without much warning. Maintenance covers the review each year, plus the changes required to stay compliant. This is routine work that is invisible when handled and expensive when ignored, usually timed against the annual release cycles rather than discovered in an emergency.
Rise of the floor
Minimum OS version
- — Old OS support reviewed against real usage
- — Deprecated APIs replaced before they break
- — Compatibility code removed, not just carried
Second pipeline
Build and signing
- — Signing certificates and provisioning kept current
- — CI runner images updated with the SDKs
- — Release notes prepared with each submission
When required
Forced update
- — Store-required change shipped ahead of deadline
- — Users nudged to update where the app depends on it
- — Rollback path tested before the release goes out
None of this is glamorous. It is scheduled, budgeted and quiet — the annual cycle, the review that keeps the app inside store rules, and the small upgrades that stop the work from piling up into a rewrite. The alternative, on the years nobody looks, is a store rejection and a weekend nobody planned for.
Widening the test matrix
Device fragmentation over time
New handsets, new screen shapes and new Android versions keep arriving, and cross-platform code has to keep running on old devices your users still own. Over time we widen the test matrix rather than assuming the current one still represents reality. For clients with field staff on ruggedised hardware, the device list is often fixed for years, and the maintenance plan is built around that.
Three fronts that move together
Maintained quarterly-
Test matrix
Devices
A short, stable set of handsets covering the OS versions your users actually hold, replaced when the old set stops matching the field. Ruggedised devices kept longer on purpose.
-
Open source
Dependencies
Third-party libraries get updates, deprecations and replacements. Upgrades land in small, regular batches, so the project stays current without a rewrite. Where debt has already piled up, the first task is an honest assessment of what it will take.
-
Beneath the app
Backend
Database growth, storage limits, index performance, authentication changes in third-party providers, and the quiet work of keeping costs proportionate to usage. Supabase or Firebase — the set of tasks is the same shape.
Scoping and pricing a maintenance plan
A monthly allowance, an agreed response
Support is scoped as its own arrangement with a monthly allowance and a defined response expectation. It covers a set number of hours, which can go towards fixes, small changes or upgrade work depending on what the month needs. Larger features are quoted separately. You are not locked in: maintenance can be handed back to your own team with documentation and access at any point.
Where the work actually sits
Backend maintenance and infrastructure
Backend services need attention too: database growth, storage limits, index performance, authentication changes in third-party providers, and the quiet work of keeping costs proportionate to usage. Whether the backend runs on Supabase or Firebase, there is an ongoing set of administrative tasks that matters more as the user count grows.
Watched weekly
Monitoring
- Crash feed and error rate read on a schedule.
- API latency and failing endpoints checked in the same pass.
- Nothing reaches a user without a note in the log.
On a calendar
Security patches
- Dependency security advisories reviewed and applied.
- Authentication providers' changes tested before rollout.
- Store and OS security bulletins read alongside the code.
Agreed upfront
Release cadence
- Store submissions timed to the client's own calendar.
- Beta channel used for changes that touch paid features.
- Each release carries notes the client can forward.
Business hours
On-call
- Named contact for anything blocking a store release.
- Response inside business hours, Monday to Friday.
- Out-of-hours cover agreed separately when a release needs it.
A legitimate end
Handover and running maintenance in-house
Some clients build an internal team and take maintenance over. When that happens we do a proper handover, not a rushed one. It is a legitimate end to the engagement, and we plan for it rather than resist it.
Request a handoverThe handover pack
-
Architecture documentation
How the app is put together — screens, data flows, third-party services, and the reason each stack choice was made.
-
Environment access
Store accounts, backend projects, monitoring projects and CI credentials transferred to the client or to the incoming team.
-
Deployment instructions
How a build goes out, how signing works, and what to check before a store submission — written for the next maintainer.
-
Codebase walkthrough
A session with the people who will own the code, so the documentation is more than a folder of documents nobody opens.
Questions we hear before the first invoice
Maintenance questions, answered plainly
Can we take maintenance to another supplier?
Yes. The code is yours, and we provide documentation and access for whoever takes it on.
Do we need a maintenance contract?
Not necessarily. Some clients run upkeep in-house and call us for major work only. What matters is that somebody is watching error reports and OS updates, whoever that is.
How is maintenance billed?
A monthly allowance of hours covering fixes, small changes and upgrade work, with larger features quoted separately. The allowance is agreed in advance rather than discovered on an invoice.
A short call is usually enough
Tell us what shipped. We’ll tell you what it needs next.
Bring the app, the store listing and the last six months of crash reports if you have them. We will walk through what maintenance would actually cover and what can wait, in Studio Brussels working hours, Monday to Friday.