Software maintenance as a service means taking responsibility for a defined set of ongoing software tasks in return for a recurring fee. It can be a viable service hypothesis when the scope, access, response expectations and cost of inherited problems are understood before the work begins.
The customer is not simply buying more development hours. They may want confidence that an important tool remains usable, someone will notice failures, and changes can be made without losing the ability to recover. Those expectations vary greatly between a small internal dashboard and a service that customers depend on all day.
Separate four kinds of work
A maintenance offer often mixes several different promises. Routine upkeep includes dependency reviews, planned updates and access checks. Reliability work concerns detecting and understanding failures. Corrective work repairs defects. Product development changes what the software does.
These activities have different costs and uncertainty. An offer that bundles all of them into unlimited maintenance makes it hard for either party to know what the fee covers.
Google's SRE book defines toil as repetitive operational work that tends to scale with a service. That engineering concept can help identify tasks worth reducing, but it does not establish demand for a particular maintenance offer.
The first question is whether a customer values the specific ongoing responsibility enough to fund it. The second is whether you can deliver it consistently.
Use a scope and ownership ledger
Before proposing a recurring plan, complete a ledger with the customer:
| Area | Decision to document |
|---|---|
| Supported assets | Which repositories, environments and integrations are included? |
| Access | Who owns accounts and grants or revokes permissions? |
| Routine work | What is reviewed, on what schedule, with what evidence? |
| Failures | Which channel receives reports and when is someone available? |
| Changes | Which work is included and which requires a separate estimate? |
| Recovery | Who can authorise rollback and where are usable backups? |
| Exit | How are documentation, access and unfinished work handed back? |
This is a scoping aid, not a legal contract template. Commercial terms and obligations need appropriate professional review where required. The important operating principle is that responsibility should never be inferred from a vague promise to keep everything working.
Assess before accepting inherited software
Ask for a bounded paid assessment before quoting continuing work. Inspect only the systems the customer authorises. Establish whether the software can be run, changed, deployed and restored by someone other than its original builder.
Record unknowns as unknowns. An application that appears simple may depend on a personal account, an unsupported component or a scheduled job nobody remembers. A successful login does not show that backups restore correctly.
The assessment should end with a supported scope, exclusions and a prioritised set of fixes. Sometimes the responsible recommendation is to replace a small tool or reduce its role, rather than accept open-ended responsibility for it.
A hypothetical internal-tool offer
Imagine a founder maintaining a parts-request application for an independent bicycle workshop. This example is hypothetical and excludes financial or safety-critical decisions.
The offer covers one documented application, a monthly dependency review, scheduled changes within a stated allowance and support during defined working hours. New integrations and major feature requests are separate. The workshop retains ownership of its accounts and appoints a person to approve changes.
During assessment, the founder discovers that the application sends notifications through a former employee's personal account. That issue must be resolved before the service promise begins. Calling it an edge case would not remove the operating risk.
The first month should measure actual work, interruptions and customer effort. If the workshop mainly wants new features, a development engagement may be a more honest fit than a maintenance subscription.
Price capacity as well as activity
Stripe's pricing guide distinguishes flat, usage-based and hybrid models. Those categories are useful reference points, but a maintenance service must also account for reserved availability and unpredictable incidents.
Build an internal worksheet with scheduled hours, expected interruptions, tooling costs, onboarding effort and a buffer for uncertainty. Then ask what work would make the account uneconomic. Do not assume that unused hours in one month cancel unlimited obligations in another.
Capacity is especially important for a solo operator. If two customers experience problems together, which commitments can you actually meet? A backup arrangement must exist before you sell coverage that depends on it.
When the model is a poor fit
Maintenance may be the wrong offer when the customer cannot grant legitimate access, cannot identify an approving owner or expects constant coverage at a price that cannot support it. Unknown architecture can also make an immediate recurring quote irresponsible.
Set a stop rule: do not accept an account whose supported assets, recovery path or working-hour expectations remain unresolved after assessment. Narrow the promise, charge for remediation or decline it. A sustainable maintenance business makes the ongoing work visible and bounded, then earns renewals by doing that work well.