Maintenance & evolution
The part of a product life that decides whether it lasts. Monitoring, fixes, dependency upgrades and the steady stream of small improvements that keep software from rotting.
What the work covers
Whether we built it or somebody else did, the job is the same: keep it running, keep it current, and keep it possible to change.
Monitoring and alerts
Crash reports, error tracking and uptime checks that reach a person — before a customer writes the first message.
Dependency upgrades
Libraries, runtimes and SDK deadlines handled on a schedule, so a store policy change is routine instead of an emergency.
Fixes with tests
Every bug fix comes with the test that would have caught it, so the same defect does not come back in six months.
Continuous delivery
A pipeline that builds, tests and ships, so a small fix takes minutes instead of an afternoon of ceremony.
Performance over time
Query times, bundle sizes and startup measured across releases, because slow arrives gradually and nobody notices the day it happened.
Taking over someone else code
A read of the codebase and a written note on what is solid, what is risky and what it would cost to move forward — before any commitment.
What you end up with
- Monitoring and alerting configured, pointed at people rather than at an inbox nobody reads.
- A release pipeline anyone on the team can run, documented in a page rather than in someone head.
- A regular written summary: what broke, what was fixed, what changed and what is coming.
- A dependency and deadline calendar, so platform requirements stop arriving as surprises.
The stack we reach for
- GitHub Actions
- Vercel
- Sentry
- Firebase Crashlytics
- Playwright
- Renovate
How it runs
Read what exists
A short assessment of the codebase, the infrastructure and the deploy process, written down and shared before anything else.
Stop the bleeding
Whatever is actively breaking gets fixed first, with monitoring added so we can see it happening.
Make change cheap
Tests, pipeline and the refactors that make the next change take hours instead of weeks.
Steady cadence
A predictable rhythm of fixes, upgrades and improvements, reported in writing.
Questions we get asked
Will you take on a project you did not build?
Yes, and often. We start with a paid assessment so both sides know what they are agreeing to — including the case where our honest advice is to rewrite rather than maintain.
How fast do you respond?
That is set in the agreement, and it depends on what the product does. A payment flow and an internal report do not deserve the same clock, and we would rather write that down than leave it to goodwill.
What if we want to bring it in-house later?
Then we plan the handover properly: documentation, a walkthrough and a period where your team leads and we answer questions. That is a success, not a loss.