Maintenance and support
Keep a live app secure, current and fast
We look after software that's already in production, whether we built it or someone else did. Dependency upgrades, bug fixes, performance work and incident response, handled on a predictable schedule.
Who it's for
Clients usually come to us for maintenance and support in one of these situations.
Your developer or agency has moved on
The app still runs, but nobody on your side knows how to deploy it, where the credentials are, or what will break if a library is updated.
Updates have been put off for years
Framework and runtime versions are past end of life, security alerts pile up in the repository, and every upgrade looks like a project.
Customers find outages before you do
Problems surface through support tickets or social media because there's no monitoring, alerting or on-call routine in place.
What we build
Maintenance work is easy to postpone until it becomes urgent. A subscription makes it routine: a set amount of capacity goes to keeping the app healthy every week.
- Dependency and framework upgrades
- Regular updates to libraries, frameworks and runtimes, including major versions, tested before they reach production.
- Security patching
- Monitoring for disclosed vulnerabilities in your dependencies and patching them on a defined schedule based on severity.
- Bug fixes
- Reproduce, fix and add a test so the same bug doesn't come back. Fixes ship in the weekly release or sooner if urgent.
- Performance work
- Slow pages, heavy queries and memory leaks found through monitoring, then fixed with before and after measurements.
- Incident response
- When something breaks in production, we investigate, restore service and write a short report on cause and prevention.
- Takeovers from other vendors
- A structured handover for apps built elsewhere: access, documentation, a risk review and a plan for the first month.
How we approach it
Every request moves through the same steps, inside your weekly release cycle.
- 01
Health review
In the first two weeks we review the codebase, dependencies, infrastructure and monitoring, and give you a prioritized list of risks.
- 02
Monitoring in place
Uptime checks, error tracking and alerts are set up or connected so problems reach us before your customers report them.
- 03
Routine upkeep
Upgrades and patches go into the queue on a regular schedule alongside any feature work you want.
- 04
Monthly report
A short written summary of what was updated, what broke, what was fixed and what we recommend next.
Typical timeline
Engagement timeline
A typical first two months when we take over a live app. After that, maintenance runs as a steady part of each week.
The first two months
Week 1
Access and inventory
Repositories, hosting, domains, app store and third-party accounts listed and moved into your control.
Weeks 1 to 2
Health review
Codebase, dependencies, infrastructure and backups reviewed, with a prioritized list of risks.
Weeks 2 to 3
Monitoring and alerting
Uptime checks, error tracking and alert routes set up or connected.
Weeks 2 to 4
Urgent fixes and patches
The highest-risk items from the review: broken builds, critical vulnerabilities, missing backups.
Week 4
First monthly report
What was found, fixed and updated, and the upgrade plan for the months ahead.
Weeks 5 to 8
Planned upgrades
Framework and runtime upgrades in tested stages, alongside any feature work you queue.
Typical for a live app of moderate size on a Starter or Growth plan. Very old stacks may need a longer stabilization phase, which the health review will show.
What you get every week
Releases happen on a fixed day each week. Monday starts with a queue check; Friday ends with these in your inbox and your shared channel.
Patch and upgrade log
Which dependencies changed this week and why, with links to the advisories or release notes behind each update.
Fixes in the release
Bugs fixed and shipped in the weekly release, each with a note on cause and the test added to prevent a repeat.
Alert and incident summary
What monitoring caught, how it was handled, and whether anything needs a follow-up request.
Queue proposal
What we suggest doing next with spare capacity, such as test coverage or a slow page. You set the order.
Quality standards
The targets we hold this work to, and how we check them. These are our commitments for how the work is done, not certifications.
- Vulnerability triage
- Our targetNew critical and high severity advisories affecting your dependencies are triaged within one business day and fixed by severity.
- How we checkAutomated dependency alerts in your repository, reviewed as part of the weekly queue check.
- Supported versions
- Our targetRuntimes and frameworks kept on supported versions, with major upgrades planned before end-of-life dates.
- How we checkAn upgrade calendar maintained in the monthly report.
- Bug fixes
- Our targetEvery fix ships with a regression test where practical.
- How we checkPart of the code review checklist.
- Incidents
- Our targetRestore service first, then write up the cause, timeline and follow-up actions after every production incident.
- How we checkFollow-up actions are added to the queue and tracked to completion.
- Response times
- Our targetFirst responses within the targets in our Service Level Agreement for your plan and the issue's severity.
- How we checkResponse times are logged against each support request.
- Access hygiene
- Our targetAn access inventory kept current, and staff access removed when it's no longer needed.
- How we checkReviewed monthly and included in the maintenance summary.
Typical deliverables
What you can expect to have in hand, in accounts and repositories you own.
- Initial health review with prioritized risks
- Dependency and vulnerability tracking
- Uptime monitoring and error alerts
- Incident reports with cause and follow-up actions
- Monthly maintenance summary
- Up-to-date runbook and access inventory
Illustrative example, not a client case study
Example engagement
A company takes over its booking app after its agency closes
Imagine a business whose customer booking app was built by an agency that has shut down. The app works, but the build pipeline is broken, nobody has the hosting credentials, and the framework is several major versions behind.
Week 1
Recover access
We help the company regain control of its domain, hosting, repositories and app store accounts, and list every credential in a shared inventory it owns.
Weeks 1 to 2
Health review
The review finds the broken build, a backup job that silently stopped, unmonitored scheduled tasks and dozens of outdated dependencies, ranked by risk.
Weeks 2 to 4
Stabilize
The build is fixed, backups are restored and tested, monitoring is connected, and the critical security patches ship.
Weeks 4 to 8
Upgrade in stages
The framework is upgraded one major version at a time behind the test suite, with the first monthly report setting out the plan for the rest of the year.
Where it ends up
The company holds every account and credential itself, the app builds and deploys from CI again, alerts reach an engineer before customers notice, and there's a written upgrade calendar for the year ahead.
Technologies we use
A short, well-known list. We'd rather know a few tools deeply than list every framework we've touched.
| Area | Tools |
|---|---|
| Monitoring | Papel Monitor, Sentry, Amazon CloudWatch |
| Security | Dependabot, GitHub code scanning, npm audit |
| Stacks we maintain | Next.js and React, Node.js, React Native, Ruby on Rails, Laravel |
Which development plan fits
Maintenance and support is delivered under a development subscription. These are the plans that suit this work best.
Starter
$390 per month, best fit
Steady upkeep for one app, with one request in progress at a time.
Start with StarterGrowth
$790 per month
Maintenance and new features in parallel, with Papel Monitor included for uptime and error tracking.
Start with GrowthScale
$1,490 per month
Priority incident response with a 1-hour target and a 99.9% uptime SLA on hosted apps.
Start with Scale
Common questions
If yours isn't here, ask us on a call or by email.
Will you maintain an app you didn't build?
Yes. We start with a health review so you know what you're dealing with. If the app is in a stack we don't support well, we'll tell you during the review rather than after you've subscribed.
How fast do you respond to an outage?
Response targets depend on your plan. Scale includes a 1-hour target for priority incidents, and Enterprise plans can set custom support hours. Details are in our Service Level Agreement.
What if there's nothing to fix this week?
Unused capacity goes to the next items in your queue: smaller improvements, test coverage, documentation or features. You decide the order.
Do we need a long-term contract?
No. Maintenance runs on the same monthly development subscription as other work, and you can cancel at the end of any billing period.
What does the monthly report include?
Dependencies updated, vulnerabilities patched, incidents and their causes, bugs fixed, current risks and upcoming end-of-life dates, and what we recommend next. It's short enough to read in ten minutes.
Which stacks do you maintain?
The stacks listed above are the ones we know well. For anything else, the health review tells both of us whether we're the right team before you commit to more than the first month.
Talk to an engineer about maintenance and support.
A 30-minute call with an engineer, not a sales script. You'll leave with a scope, a plan recommendation and a start date.