The cost of maintaining custom software is easy to underestimate because maintenance rarely arrives as one predictable project.
A production application accumulates small obligations: security patches, dependency updates, certificate renewals, API changes, performance issues, browser or operating-system changes, data corrections, user support, minor enhancements and occasional incidents.
Businesses usually choose between two commercial models.
A maintenance retainer reserves recurring engineering capacity and support availability.
On-demand support purchases engineering only when a specific need appears.
Neither is automatically cheaper. The better model depends on how frequently the application changes, how quickly incidents must be handled, how much context engineers need and how expensive delayed maintenance becomes.
Actiknow’s maintenance plans explicitly include areas such as support, bug fixes, backup restoration, adaptive maintenance, performance optimization and developer hours. Those categories illustrate why post-launch ownership is broader than emergency bug fixing.
Think in Total Cost, Not Hourly Rate
On-demand support can look cheaper because the business pays nothing during quiet months.
A retainer can look more expensive because the recurring cost is visible.
But hourly spend is only one component.
Total maintenance cost also includes:
- time spent onboarding engineers;
- time spent reproducing old issues;
- downtime while support is arranged;
- knowledge lost between engagements;
- deferred security work;
- technical debt;
- release risk;
- internal management effort.
A lower hourly rate can produce a higher total cost if every incident starts with rediscovery.
What a Maintenance Retainer Buys
A good retainer buys more than a block of hours.
It creates continuity.
The support team remains familiar with the codebase, deployment process, infrastructure, integrations, recurring issues and business priorities.
It can also establish a regular operating rhythm:
- review monitoring;
- apply dependency updates;
- fix small defects;
- optimize performance;
- handle user-reported issues;
- review backups;
- prepare minor releases;
- keep documentation current.
This reduces the probability that maintenance becomes purely reactive.
Actiknow’s custom web application development page describes deployment and ongoing support as part of the development lifecycle, including post-launch optimization of performance and security. That is the correct mental model: launch begins the operating phase.
What On-Demand Support Buys
On-demand support preserves flexibility.
It can work well when:
- the application is stable;
- usage is low;
- business impact of downtime is limited;
- changes are rare;
- internal staff retain technical knowledge;
- documentation is strong;
- response time is not urgent.
The business pays when work exists rather than reserving capacity.
For a small internal tool that changes twice a year, this may be economically sensible.
The risk appears when “on demand” is interpreted as “someone will be immediately available whenever we need them.”
External engineering teams cannot always reserve unsold capacity for a customer with no recurring commitment.
Response Time Has Economic Value
The right model depends partly on the cost of waiting.
If an internal dashboard is unavailable for half a day, the impact may be inconvenient.
If a customer portal cannot accept orders, every hour may have a measurable cost.
Define support expectations:
- critical incident response;
- high-priority response;
- normal bug response;
- minor enhancement scheduling.
Then compare the cost of reserving availability with the business cost of uncertain availability.
A retainer often makes more sense when response expectations are tight.
Incident Frequency
Review the last twelve months.
Count:
- production incidents;
- urgent fixes;
- minor bugs;
- dependency updates;
- security patches;
- API changes;
- performance investigations;
- small feature requests;
- data corrections.
If work appears almost every month, repeatedly procuring on-demand support may add unnecessary friction.
If there were two small requests all year, a large retainer may be wasteful.
Use actual history rather than intuition.
Release Cadence
Applications that release frequently benefit more from continuous engineering context.
Every release can require:
- testing;
- deployment;
- monitoring;
- rollback planning;
- dependency checks;
- documentation.
A product releasing every two weeks has a different support profile from an application that changes twice a year.
Retained capacity can blend maintenance and minor enhancement work into a predictable release rhythm.
Knowledge Retention
Custom software contains business knowledge that may not be obvious from code.
Why does a status mapping have an exception?
Why is one API called before another?
Why does a report exclude a specific category?
Why is a database job scheduled at 2:15 rather than 2:00?
Engineers who work with the system continuously accumulate this context.
On-demand teams may need to rediscover it unless documentation and handover are excellent.
Actiknow’s guide on what to define before custom application development specifically calls out documentation, knowledge transfer, infrastructure access and post-go-live support as long-term responsibilities.
Knowledge retention should therefore be treated as an asset with economic value.
Technical Debt
Maintenance deferred does not disappear.
Libraries become obsolete. Tests fall behind. Infrastructure configuration drifts. Workarounds accumulate.
Actiknow’s article on successful custom applications describes software as a living product requiring testing, monitoring and continuous improvement after launch.
A retainer can create space for preventive maintenance that is difficult to justify during an emergency-only support model.
However, a retainer only provides this benefit if preventive work is actually planned. Unused hours that expire without useful activity do not improve the codebase.
Security Maintenance
Security creates recurring work even when users request no new features.
Dependencies need patches. Certificates expire. Cloud permissions evolve. Vendor APIs change authentication. Vulnerabilities are disclosed.
For business-critical software, establish a patching and review cadence.
Actiknow’s security page describes change management, peer review, least privilege and production controls. Ongoing maintenance is where those practices must continue after the original project team moves on.
Integration Maintenance
Third-party integrations make maintenance less predictable.
A SaaS vendor can deprecate an endpoint, change an OAuth flow or introduce a new required field.
Payment gateways, CRM platforms, cloud services and identity providers evolve independently of your release schedule.
Applications with many external dependencies often benefit from continuous ownership even if the core code is stable.
Infrastructure and Performance
Growth changes application behavior.
Queries that were fast at 10,000 records may be slow at ten million.
Traffic patterns change. Storage grows. Background jobs overlap. Logs become expensive.
Maintenance should include performance review and infrastructure optimization, not merely bug fixing.
Actiknow’s maintenance plans explicitly reference performance optimization, including server upgrades, slow-query analysis and indexing.
Minor Enhancements
Many post-launch requests are too small to justify separate projects:
- add a field;
- change a validation;
- modify an export;
- add an admin filter;
- adjust a notification;
- support a new role.
A retainer can make these changes operationally simple because capacity already exists.
With on-demand support, each request may require estimation, approval, scheduling and re-onboarding.
Measure the administrative overhead as well as engineering time.
When a Retainer Usually Makes Sense
A retainer is usually attractive when several conditions apply:
- the application is business-critical;
- response time matters;
- monthly work is common;
- releases are frequent;
- integrations change regularly;
- security obligations are significant;
- internal engineering ownership is limited;
- context is expensive to rebuild.
The value comes from continuity and readiness.
When On-Demand Support Usually Makes Sense
On-demand support can be appropriate when:
- the application is mature and stable;
- incidents are rare;
- changes are infrequent;
- downtime has modest impact;
- documentation is strong;
- internal staff can diagnose issues;
- there is no expectation of immediate external response.
The model works best when the business genuinely accepts variable scheduling.
The Hybrid Model
Many companies benefit from a hybrid.
Maintain a small base retainer for monitoring, security, continuity and incident response.
Purchase larger enhancements separately as projects.
This avoids using maintenance capacity for major roadmap work while preserving system knowledge and availability.
Another option is a bank of hours with a longer validity period, provided response expectations and ownership are clear.
Define What Is Included
Retainers create frustration when “maintenance” is undefined.
Document whether the agreement includes:
- bug fixes;
- monitoring;
- security patches;
- dependency upgrades;
- infrastructure;
- backups;
- data fixes;
- minor features;
- third-party API changes;
- support requests;
- performance tuning;
- release management.
Also define exclusions.
A new mobile application is not a maintenance request merely because it connects to the existing backend.
Define Service Levels
Service levels should describe severity and response, not promise that every issue will be resolved instantly.
For example:
- critical: production unavailable or severe data/security impact;
- high: major workflow impaired;
- normal: noncritical defect;
- low: cosmetic or minor request.
Agree how incidents are reported and who can assign severity.
Without this, every request becomes “urgent.”
Track Utilization and Outcomes
A retainer should be transparent.
Review:
- hours used;
- work completed;
- incident count;
- response times;
- preventive maintenance;
- technical debt addressed;
- planned next work.
The objective is not to maximize hour consumption. It is to keep the application healthy and useful.
If a retainer is consistently underused, resize it.
If demand consistently exceeds capacity, increase it or separate roadmap development.
Calculate Annual Cost
Compare both models using scenarios.
1. Retainer cost:
annual recurring fee plus major out-of-scope projects.
2. On-demand cost:
engineering hours plus onboarding/rediscovery plus emergency premiums where applicable plus internal coordination plus downtime impact.
Run low, expected and high incident scenarios.
This is more useful than comparing one quoted hourly rate.
Do Not Ignore Vendor Continuity Risk
If only one external developer understands the application, both support models carry risk.
Maintain repository access, architecture documentation, deployment instructions, credential ownership and runbooks.
Actiknow’s pre-development guidance recommends clarifying ownership of source code, repositories, cloud accounts, databases and third-party services.
Good handover reduces dependency on any vendor and makes retained support more effective.
Maintenance Is Not a Substitute for Product Ownership
A support team can keep software healthy.
It should not be expected to decide business priorities without an owner.
Assign someone internally to approve changes, prioritize requests and clarify business rules.
This prevents the maintenance queue from becoming an unstructured list of stakeholder wishes.
Review the Model Annually
The right support model changes.
A new application may need intensive retained support during its first year.
A mature internal system may later become stable enough for a smaller plan.
A previously quiet platform may become customer-facing and require stronger service levels.
Review criticality, incident history, roadmap and internal capability at least annually.
Frequently Asked Questions
Is a software maintenance retainer always cheaper?
No. It is economical when continuity, recurring work and response readiness justify the recurring fee.
What should a maintenance retainer include?
Typical areas include support, bug fixes, security and dependency updates, performance work, minor enhancements and release support. The agreement should define exact scope.
Can we use on-demand support for a critical application?
Yes, but only if the business accepts the availability and response-time risk or has strong internal coverage.
How many hours should we retain?
Estimate from historical maintenance demand, planned release activity and required response coverage. Review actual usage and resize over time.
Should major features be part of maintenance?
Usually large roadmap features are cleaner as separate projects. Retainers work best for operational continuity and bounded enhancements.
How do we avoid vendor lock-in?
Maintain source-code ownership, repository access, infrastructure access, documentation, deployment instructions and knowledge transfer.
What happens to unused retainer hours?
Commercial policies vary. Agree this explicitly before signing, including whether hours roll over and for how long.
Conclusion
The cheaper maintenance model is the one that matches the application’s operating reality.
Stable low-risk systems can work well with on-demand support. Business-critical applications with recurring change often benefit from retained capacity because continuity, response readiness and preventive maintenance have real value.
If you are deciding how to support a custom application after launch, Actiknow can help assess the maintenance workload and define an appropriate ongoing support model. Review Actiknow’s maintenance plans or discuss your application support requirements with Actiknow.