The first line of any application support checklist is a name: who gets the alert when the app breaks at 2 a.m. An application maintenance service sells that name plus 4 kinds of work, by the month. Check first whether the app needs ongoing care or a one-time hardening pass: a retainer cannot maintain what was never built.
Application maintenance service: what it is, and what the words on a vendor page mean
An application maintenance service is a standing arrangement in which an outside team keeps a live application working, secure and current after it was built, sold by the month, by the ticket or by a block of hours. Outsourcing firms sell the enterprise version of the same work under the initials AMS.
Most founders meet the term at the end of a build, when the contractor or agency is about to move on and somebody says the app needs a maintenance contract. That moment is part of what a developer handoff looks like, and what you buy next depends on what the handoff left in place.
The words come from outsourcing: CAST’s glossary describes AMS as help for “organizations and companies that need to outsource some of their workloads”. The initials vary by seller. CAST spells AMS out as “application maintenance services”, and Digisoft’s guide uses AMSS for “Application Maintenance and Support Services”, which it defines as “all the activities required to keep a software application functional, secure, up-to-date, and aligned with evolving business needs after its initial deployment.” Read past the acronyms and the claim underneath is the same: someone else will keep the app running.
An application maintenance company, in practice, can be a firm with a support desk, a smaller shop or a single person. For the packages sellers offer and their prices, see what is in an app maintenance package and what it costs. This page adds four things for a founder with one app: the questions that pin down what an agreement covers, a checklist of what the app must already have, eight questions to put to any seller, and the order to buy in.
Why it matters for a founder with one app: the basics a seller needs are often missing
Some work lands on a maintenance bill whether or not anyone touches the app, and the jobs on a maintenance bill are listed elsewhere. This section is about something else: the app a seller inherits on day one, and whether it has what a maintainer needs to do the job at all.
| What a maintenance seller needs | What my audits found | What the first month goes on without it |
|---|---|---|
| A way to learn about and apply a framework security release | 9 of the 26 audited apps ran a framework version with a publicly known, reachable RCE or auth bypass, and the fix was often a one-line version bump | Finding out which versions the app runs and bumping them |
| Something to look at when a user reports a problem | 17 of the 21 third-party apps had no error tracking or alerting: when a user hits an error, nothing records it | Installing error tracking and alerts before any report can be traced |
| A safe way to ship a fix | At least 17 of the 21 third-party apps had no deploy gate, and so did all 5 founder apps: every push ships straight to production with nothing checking it first | Building a gate so a fix does not ship untested |
| A way to know a fix broke nothing | At least 23 of the 26 audited apps had zero working automated tests | Writing the first tests on the core journeys |
The 26 are the apps I audited in June and July 2026: 21 third-party apps and 5 of my own. They were my choice, so none of these counts is a rate for AI-built apps in general. The right-hand column is my estimate of what a maintainer does first when the left-hand column is missing: the first month goes on building it. Your own app may have all four, and the checklist further down is how to check.
A public case shows the pattern behind the first row: a fix that was published, with a date, for anyone who owned the job of applying it. Let’s Encrypt’s page on DST Root CA X3, the older root certificate behind its cross-signature, named the date: “DST Root CA X3 will expire on September 30, 2021.” It said a typical website would not notice a difference. For anyone running an API, it listed two things to make sure of: every client must trust the newer ISRG Root X1, and clients using OpenSSL must use version 1.1.0 or later, because in OpenSSL 1.0.x even clients that trust ISRG Root X1 “will fail” with the Android-compatible chain. The date and the fix were both published. A fix that exists does nothing until applying it is somebody’s job.
When a fixed build ends, whatever cover came with it has an end date too, and what that window should include fits on a post-launch support checklist.
How it works: the two jobs, what an agreement covers, the support side, and the checklist
Four parts follow: the two jobs sold under one name, what the agreement must name, what the support side needs, and the checklist that decides whether any of it can work.
Application maintenance and support: two jobs under one name
Application maintenance and support are two jobs sold under one name. Support is reactive: a problem is reported and a person restores service. Maintenance is scheduled: patches, upgrades and root-cause fixes. An agreement for either should say how it is measured: support by response and resolution time, maintenance by what shipped and what is current.
The difference between the two, as sellers draw it, is answered in the package article’s FAQ, “What is the difference between app maintenance and app support?”, and this page does not walk through support levels. What matters here is how each job gets written into an agreement. The support side is measured in time, a response time and a resolution time per severity, which is a service level agreement, and knowing what SLAs are and what they promise matters before you sign one. The maintenance side is measured in output. I’d measure it with a monthly record of what changed: which fixes shipped, which dependencies and runtime versions moved, and what is still behind.
Vendor pages print the name in more than one order, some with an ampersand: Softjourn heads its service list “Application Support & Maintenance Services We Offer”. Whichever order a seller uses, ask which of the two jobs the price covers, because an application support and maintenance contract can be mostly one of them.
Application maintenance and support services: what the agreement must name, kind by kind
Application maintenance and support services cover four kinds of work: corrective, adaptive, perfective and preventive. The agreement should say which kinds are included and where each stops, because perfective work, improving the app, is where a maintenance contract quietly becomes a development contract.
The four come from the ISO/IEC 14764 standard, and Wikipedia’s summary of the four types of software maintenance gives them in one line each: corrective fixes a bug or a failure to meet requirements, adaptive keeps the software usable in a changed environment, perfective improves qualities such as user experience and efficiency, and preventive is forward-looking change so the software keeps meeting requirements. The current edition, ISO/IEC/IEEE 14764:2022, splits out a fifth, additive maintenance, which the IEEE Computer Society’s SWEBOK Guide describes as a change after delivery “to add functionality or features to enhance the usage of the product”. In a first agreement I group additive work with perfective: quoted per job. Some pages write “preventative”; this page uses “preventive”, as the standard’s list of types does.
| Kind | In a first agreement? | The question that pins it down |
|---|---|---|
| Corrective | In | What counts as a defect, and how fast is each severity fixed? |
| Adaptive | In | Who watches for host, runtime and API retirements, and who does the change? |
| Preventive | In, for dependency and security updates | How often are dependencies updated, and how fast does a security release ship? |
| Perfective | Quoted per job | Where does improvement stop and new feature work start? |
The middle column is what I’d put in a founder’s first agreement, not a standard: corrective and adaptive in, preventive in for dependency and security updates, perfective quoted job by job. Application maintenance support services written for a portfolio of applications can bundle all four, because a portfolio always has something to improve. For one app, the cheaper agreement is the one with the edge drawn in writing.
One vendor guide adds emergency work. Digisoft lists emergency maintenance as a fifth kind, which “provides rapid response under SLA-defined timelines to minimise damage and downtime” when “critical issues arise”. The 2022 standard defines it too, as “unscheduled modification performed to temporarily keep a system operational, pending corrective maintenance”, in the SWEBOK Guide’s words. I read that as corrective work with a clock on it, so the agreement covers it through the severity definitions rather than as a separate line.
Application support services: what the support side does, and what it needs from the app
Application support services answer when the app misbehaves: someone takes the report, someone investigates with access to logs and configuration, and someone changes code when the cause is in it. None of that works unless the app gives the support side something to read: an error tracker, logs and a way to deploy a fix.
How sellers package and price that work, by unit, by seller type or one job at a time, is covered in the package article. Who should carry it is a separate question: the four arrangements that keep an app alive run from doing it yourself to handing it on entirely. Buying a developer’s hours is one of them, and what a month of part-time developer support buys leaves out monitoring unless it is written down separately. The wider choice, fractional CTO vs agency or a fixed piece of outside work, is a buying decision of its own.
My own point is narrower. The support side can only read what the app records. A person with excellent judgment and no error tracker is reading user emails and guessing. So the useful question before any contract is what the app must have, which is the next list.
The application support checklist: what must exist before anyone can maintain the app
An application support checklist has nine items that must exist before anyone can maintain the app: access in the company’s name, a gated deploy path with a rollback, error tracking and an uptime check, a restored backup, runbooks, tests on the core journeys, severity definitions, named contacts and a record of what was built.
- Access. The repository, hosting, database, DNS and every third-party account sit in the company’s name, with a way to add a person. The seller uses it to work without borrowing anyone’s login; it comes from the accounts you already pay for.
- A deploy path that does not depend on one laptop or on the tool that generated the code, with a gate and a rollback. The seller ships every fix through it; it comes from the hosting platform’s build settings and a short pipeline file.
- Error tracking and an outside uptime check. The seller reads them when a user reports a problem, and they alert someone when nobody does; both come from a monitoring account wired into the app.
- A backup that has been restored once. The seller relies on it before any risky change; the restore is what proves it exists.
- Runbooks for deploy, rollback, key rotation and restore. The seller follows them in the middle of the night instead of guessing; they come from writing down each procedure the first time it is done.
- Tests on the core journeys: signup, login, payment and the main task. The seller runs them before shipping a patch; they come from whoever knows the journeys writing them once.
- Severity definitions. The seller triages against them, so urgent means the same thing to both sides; they come from one page in the agreement.
- A named contact on each side, with stated hours. The seller knows who decides; it comes from the agreement.
- A record of what was built and why: an architecture description and a list of known limits. The seller reads it in week one instead of rediscovering it; it comes from the builder at handover.
Which accounts to check, one by one, is the who-maintains article’s FAQ “What should be in my own name before anyone else works on the app?”. The fuller list for a build that is changing hands is a software project handover checklist, and the procedures in item five have their own runbook templates. Items two, three and six are the same gaps as the table above, from the same audits.
A seller who takes on an app missing most of these spends the first months building them, at monthly rates. The same nine items also work as the application support checklist for an internal team taking the app over from a contractor.
How to check whether you need one yet: the buy-order rule, eight intake questions, and the first month
Whether to buy an application maintenance arrangement yet comes down to one count: how many of the nine checklist items the app already has. With most missing, one-time hardening comes first, because monthly hours spent building basics are the expensive way to get them. With most present, a small monthly plan or pay-per-job is enough.
Whether the app has recurring work to buy at all, given how often it changes and what an hour of downtime costs you, is answered in the who-maintains article and in the package article’s FAQ “My app works today. Do I need a plan at all?”. The rule here does not overrule that answer. It only decides what to buy first once there is work to buy.
I wrote the buy-order rule above myself; it is not an industry standard, and “most” is deliberately loose: an app with one or two gaps can buy monthly help and close them there. What a one-time hardening pass covers, area by area, fits on a production readiness checklist. Once the basics exist, which of the four arrangements fits is the who-maintains article’s question.
Once you are talking to sellers, eight questions show quickly whether one has looked at your app. I have marked the worrying answer to each:
- 01 What do you need from the company before you start? Worrying: nothing. A seller who needs nothing has not looked.
- 02 Which of the nine checklist items do you expect to find, which will you build first, and at what charge? Worrying: a flat monthly fee with no answer to the first part.
- 03 Which of the four kinds of work is included, and where does perfective work stop? Worrying: "everything", with no line drawn.
- 04 How do you learn about a security release for the app’s framework, and how soon does it ship? Worrying: a vague promise to keep an eye on it.
- 05 Does every change go through the app’s deploy gate, or around it? Worrying: edits made straight on the server.
- 06 Who receives the monitoring alerts, and what happens next? Worrying: the alerts still go only to the founder.
- 07 What will the first month’s report show? Worrying: hours used, and nothing about what shipped.
- 08 What do you hand back if the arrangement ends: the accounts, the notes, the runbooks you changed? Worrying: a pause before the answer.
Response times in the contract, unused hours and notice periods belong to what belongs in a web developer retainer agreement, so they are not asked again here.
After the first month, check the arrangement against your own records. Each item passes or fails:
- One change shipped through the gate, with its date.
- One test alert fired on purpose and answered inside the stated time. Fire it by lowering an alert threshold in staging below the current value, so it trips at once; a threshold set just above the current value may never fire.
- One report received that lists what shipped and which versions changed.
Keep the three dated records. If any one is missing after a month, the arrangement is not yet doing the job it was sold for.
Where the sprint fits
The Production Hardening Sprint covers one codebase and runs for 10 working days. Deliverable 13.3, operating runbooks, documents deployment, rollback, key rotation, backup restoration, and the response to each operational alert, and it is verified by walking through the runbooks against the delivered configuration and referencing the rehearsal evidence. After handover come 14 calendar days of fixes for defects in the delivered work, and deliverable 13.5 is verified by recording the coverage dates, reporting channel, reproduction details, fixes, and retest results. The 30 calendar days of async questions about the handover and architecture also begin at handover, and for deliverable 13.7 the handover gives the channel, access instructions, and the start and end dates. Hosting, paid tools, and API usage remain in your accounts. Every item and its check is in the published scope.
Common questions about application support and AMS
What are AMS services?
AMS services are outsourced work to keep a company’s applications running; in CAST’s glossary the letters stand for application maintenance services. AppDirect’s glossary uses the name application management services and defines it as “a wide range of services and processes for maintaining and managing custom or third-party software applications.” For one app, it is the same work under a smaller name: an application maintenance service.
What are some examples of application management services?
Typical examples are debugging, code audits, migrations, performance tuning and SLA management. Softjourn’s service page lists eight under application support and maintenance: debugging services, in-depth code audit, migration services, proactive performance optimization, feature updates and modernization, root cause analysis and continuous improvement, customizable SLA management, and system health and capacity planning.
What is an example of application support?
A typical example is a customer who cannot log in and writes in. The first responder confirms the problem and collects the account, the time and the error shown. The next person checks the logs and finds that the app’s email provider is rejecting sends because a credential expired, so no login codes are going out. A developer rotates the key, adds an alert for the next expiry date, and the customer is told it is fixed.
What is an application service provider?
An application service provider (ASP) is “a business providing application software generally through the Web”, in the words of Wikipedia’s application service provider page. It is not a maintenance seller: an ASP rents you software that it runs, while a maintenance service looks after software that you own.
Owning an app means being able to run it, change it and recover it without guessing. The sprint below leaves you with the runbooks and documentation to do that.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase