Software Maintenance Services: What They Cover and Cost

Software maintenance services cost $100 to $300 a month with us, depending on what you run. A plan should cover dependency and framework updates, security fixes, monitoring with alerts, hosting and domain upkeep, app store requirements for mobile apps, tested backups, and an agreed number of hours for small changes, all written down before it starts.

TL;DR: Maintenance keeps software working as everything around it changes. Expect updates, security fixes, monitoring, backups, store compliance, and a few hours of small changes. A website sits near $100 a month, a web app with a backend and a store app nearer $300. Larger features are quoted separately.

Software doesn't stay finished. Frameworks ship new versions, app stores raise their minimums, a payment gateway changes its API, and a dependency gets a security advisory. Meanwhile your team wants a new field on a form. If nobody owns the software after launch, these pile up until something breaks in front of a customer. This post explains what a plan should include and what changes the price.

What does a software maintenance plan cover?

A plan covers everything that keeps the software working without new features: updates, security fixes, monitoring, hosting and account upkeep, store compliance for mobile apps, backups, releases, and a capped number of small changes each month. The list should be written down, so the invoice holds no surprises.

Area	What it means in practice
Updates	Framework, library, and SDK upgrades on a schedule
Security fixes	Dependency alerts handled before they become incidents
Monitoring	Error tracking, uptime checks, and alerts on jobs and queues
Hosting and accounts	Hosting, domains, analytics, and store accounts kept current, in your name
Mobile store requirements	New OS versions, SDK minimums, and policy changes
Backups	Automatic, off-account, and restored on a schedule
Small changes	The new page, the extra field, the changed price

What does software maintenance cost?

Our plans run $100 to $300 a month. Where you land depends on how many systems you run, whether one of them is a mobile app in the stores, whether the software takes payments, how much monitoring it needs, and how many hours of small changes you want each month.

Here's how scope maps onto that band. These are shapes, not price tags; the written plan sets the number.

Plan shape	What it covers	Where it sits in $100 to $300
Website only	Hosting, domain, CMS and framework updates, uptime check, a few small edits	Toward the low end
Web app with a backend	The above, plus database backups, error tracking, job and queue alerts, dependency updates	The middle
Web app, backend, and a store app	The above, plus OS and SDK updates, store policy changes, crash fixes, releases	Toward the high end

Larger work, such as a new feature or a major framework upgrade, is quoted separately so the monthly cost stays predictable. A Django 4.2 to 5.2 move, for instance, is a project of its own; we walk through one in our Django upgrade guide.

How often should dependencies be updated?

A little at a time, on a schedule. Apply security patches as soon as they're tested on staging, take minor updates monthly or quarterly, and plan major upgrades as separate pieces of work with their own estimate. Skipping updates for two years turns many small, cheap changes into one large, risky one.

Automation does the noticing. GitHub describes Dependabot security updates as a way to fix vulnerable dependencies in your repository: when it raises an alert, it tries to open a pull request that moves the dependency to the minimum version with the fix (GitHub Docs). Renovate does a similar job. Either way, a person still reviews, tests, and ships the change. That's the part you're paying for.

Why do mobile apps need more maintenance?

Because the stores keep moving the floor. Apple and Google raise minimum SDK and target versions every year, and an app that doesn't keep up loses the ability to ship updates, or loses visibility to new users, often on the day you need a fix.

The dates are public. From August 31, 2026, new apps and app updates on Google Play must target Android 16 (API level 36) or higher, and existing apps that target Android 14 or lower are only available on devices running that Android version or lower (Android Developers). Since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK (Apple Developer).

Not every fix needs a store build. In Expo apps, EAS Update can ship JavaScript, styling, and images over the air, but native code, permissions, and SDK upgrades still need a new binary (Expo docs). Our OTA release process post covers how we run those updates safely.

How do you find problems before customers do?

With monitoring that alerts whoever maintains the software, not whoever uses it. The minimum for any system is error tracking, an uptime check, and an alert on any background job that stops running. Bigger systems add health signals on queues and workers.

Two examples from our own products show what that looks like at the deeper end. Kraftr's workers write heartbeats every 10 seconds into a liveness view in the admin, so a stuck queue shows up before a customer reports it. Pullsy's scheduler recovers crashed jobs from missed heartbeats, and its Meta API errors map to backoff with jitter capped at 30 minutes; our rate limits and backoff post explains that pattern.

A $100 website plan won't include that depth, and doesn't need to. What it must include is the alert. We go further on the reliability and monitoring page.

Are your backups real until you've restored one?

No. A backup nobody has restored is a hope. A plan should confirm, on a schedule, that the database and uploaded files are backed up automatically, with enough history to recover from a mistake noticed a week later, and that a restore has actually been tested.

Check four things:

1. The database is backed up automatically, with at least a week of history.
2. Uploaded files, such as images and documents, are backed up too.
3. A restore has been tested into a separate environment, and someone knows how long it takes.
4. Backups live in an account separate from production, so one compromised login can't delete both.

Test a restore at least once a year, and after any major hosting change.

An example: the IT partner role

We're the ongoing IT partner for The Sharp Interiors, an interior design firm whose site and gallery CMS we built: hosting, domain, analytics, and the month-to-month changes are ours to handle, and the firm has one team to call. That shape suits many small businesses, where the people who built the system also keep it running.

Taking over software another team built

Start with one step: a short audit of the code, the hosting, and the accounts. Taking over blind means inheriting problems you'll be blamed for. The audit finds what's risky, you fix what's on fire, and then routine maintenance starts.

Typical findings:

1. Accounts held in a former developer's personal name.
2. No backups, or backups never tested.
3. Dependencies years out of date.
4. No error tracking at all.
5. Secrets committed to the repository.

Accounts belong in your name

You should. Cloud hosting, domains, app store accounts, and analytics belong in your company's name, with the maintainer added as a user and removed when they leave. If the accounts sit in the maintainer's name, you're not maintaining your software. You're renting it.

When don't you need a maintenance plan?

A simple marketing site on a managed host, with a CMS your team edits, may need only an occasional check. A monthly plan earns its cost when the software runs part of your business, takes payments, has an app in the stores, or changes often.

Before signing with anyone, ask five questions: what's included in writing, how fast they respond to an outage and how you reach them, who receives the alerts, whether the accounts stay in your name, and which software they look after today.

FAQ

Is a maintenance retainer cheaper than paying per fix?

Usually, once software runs part of your business. Per-fix work is billed when something has already broken, often urgently. A retainer pays for updates and monitoring that stop many of those breaks, plus a few hours of small changes. For a rarely changed brochure site, paying per fix can be cheaper.

How quickly should a maintenance team respond to an outage?

Agree it in writing before you need it: how you report an outage, who is alerted automatically, and a response time for urgent issues versus routine requests. Monitoring should mean the maintainer often knows first. A plan without a stated response time is a plan you can't hold anyone to.

What happens to unused support hours at the end of the month?

That depends on the plan, so ask before signing. Some plans let a small number of hours roll over for a month, others reset. Either way, the hours should be logged against named tasks, so you can see where they went and adjust the plan size if you're consistently over or under.

Need someone to keep your software running? See our maintenance and support plans and send us a list of what you run today: sites, apps, backends, and the accounts behind them.