Plan SaaS maintenance as an ongoing product capability covering reliability, security, dependencies, support, infrastructure and change. Build a service inventory, assign owners and service levels, model fixed and variable costs, and reserve capacity for incidents and technical debt. A launch budget is not an operating plan.
This belongs in SaaS development and AI automation governance. Every live feature creates monitoring, support and change obligations.
NIST's Secure Software Development Framework recommends integrating secure practices into the development lifecycle to reduce vulnerabilities and prevent recurrence Source: NIST.
Define the supported service
List users, critical journeys, availability periods, data, integrations and consequences of failure. Separate contractual commitments from internal targets.
Define production, staging, backups and third-party services. Include scheduled jobs and manual operations.
Assign ownership
Name product, engineering, infrastructure, security, privacy and support owners. Define who can deploy, pause service and communicate incidents.
Create a responsibility matrix with backups. Outsourced hosting or development does not remove business accountability.
Establish service levels
Set availability, response, restoration, data recovery and support targets based on customer need and risk. Define measurement and exclusions.
Do not promise round-the-clock support with business-hours staffing. Price the operating model required by commitments.
Review service levels as customers and criticality change.
Build a dependency inventory
Record packages, APIs, databases, hosting services, certificates, domains and licences. Include version, owner, purpose, renewal and replacement path.
Monitor security advisories and deprecations. Remove unused dependencies.
Use software composition tools where appropriate, but verify findings and ownership.
Plan security work
Fund vulnerability handling, access reviews, patching, penetration testing, logging and incident response. Track requirements and design decisions.
NIST says secure practices should be integrated into each lifecycle rather than added separately Source: NIST.
Prioritise by exposure and impact, not headline severity alone.
Maintain development environments
Protect repositories, CI/CD, secrets, build runners and artefact storage. Use least privilege and multifactor authentication.
Review former staff and supplier access quickly. Keep production data out of ordinary development.
Test that releases are reproducible and traceable.
Budget infrastructure by driver
Model compute, storage, database, bandwidth, queues, monitoring, backups and third-party usage. Identify fixed, per-user and per-transaction costs.
Create normal, growth and peak scenarios. Include South African and international regions actually served.
Alert on unusual spend and link cost to product usage.
Plan backups and recovery
Define recovery point and time objectives. Encrypt backups, separate access and test restoration.
A successful backup job does not prove the service can recover. Run scheduled exercises including dependency and credential recovery.
Document customer communication and data-reconciliation steps.
Operate observability
Monitor availability, errors, latency, saturation, queues and business-critical transactions. Use actionable alerts with owners and runbooks.
Avoid alert floods. Review missed incidents and noisy thresholds.
Keep logs appropriate to privacy and retention requirements.
Structure support
Define intake channels, priority, response targets, escalation and knowledge ownership. Separate product defects, user education and feature requests.
Measure time to useful response, resolution and recurrence. Feed common problems into product work.
Provide backup coverage for leave and peak periods.
Reserve incident capacity
Plan on-call or escalation appropriate to service criticality. Maintain runbooks, contacts, status channels and decision authority.
After incidents, record causes, impact and prevention actions without blame. Verify that actions are completed.
Budget time for exercises and learning.
Keep dependencies current
Set routine update windows and risk-based urgent paths. Test application behaviour, not only whether the build succeeds.
Avoid both uncontrolled auto-updates and years of version drift. Group manageable changes while keeping rollback.
Record unsupported components as explicit risk.
Fund technical debt
Maintain a debt register with business impact, risk, effort and owner. Reserve recurring capacity rather than waiting for a crisis.
Retire obsolete code, flags and integrations. Simplification reduces maintenance cost.
Do not label every disliked implementation as debt without a consequence.
Plan product change
Allocate capacity for discovery, design, development, testing, rollout and measurement. Separate roadmap work from mandatory maintenance in planning.
Use feature flags and staged releases where appropriate. Define rollback and customer communication.
Measure adoption and outcome before expanding complexity.
Maintain data governance
Map personal information, purpose, access, retention, operators and deletion. Review changes for POPIA and applicable sector duties.
Test data-subject and incident procedures. Restrict exports and production access.
Include legal and privacy review in material feature changes.
Track vendor renewals
Maintain contract, renewal, price, usage, service level, data export and exit information. Start material renewal reviews early.
Remove unused licences and duplicate tools. Test portability before a vendor becomes urgent risk.
Avoid committing based on introductory pricing only.
Calculate people cost
Include product ownership, engineering, support, security, design, QA, analytics and administration. Count management and supplier coordination.
Avoid assuming one developer can sustainably cover product, infrastructure and support at all times.
Model hiring, leave, training and knowledge continuity.
Create maintenance categories
Report effort across run, secure, support, improve and retire. This shows whether urgent work crowds out product change.
Set target capacity bands, then compare actual work. Adjust for incidents and growth.
Measure unit economics
Track infrastructure and support cost per active customer, transaction or relevant unit. Segment unusually expensive accounts or features.
Do not optimise cost in isolation. A cheaper architecture that harms reliability can reduce retention.
Connect cost with service and customer outcomes.
Review quarterly
Examine reliability, incidents, vulnerabilities, support themes, dependency age, spend, capacity and roadmap delivery. Update forecasts.
Review whether service levels and architecture still fit the product. Retire unused capability.
Keep decisions and accepted risks visible.
Forecast growth and contraction
Model what happens when active customers, stored data, transactions and support contacts double. Identify components that scale linearly, step up at licence thresholds or require specialist people. Include a contraction case so the business understands which contracts and infrastructure can reduce when demand changes. Review whether pricing continues to cover service cost in each scenario.
Do not assume cloud services scale economically without architecture and commercial review. Test peak behaviour and quotas before campaigns or customer migrations create urgency.
Maintain an exit and continuity plan
Document how another team could operate the service, including repositories, environments, accounts, vendors, runbooks and current risks. Keep architecture diagrams and recovery contacts current. Define how customers receive data and how the service can be retired safely.
Exercise supplier and key-person contingencies. A maintainable product should survive a provider change, staff departure or material platform failure without depending on undocumented personal knowledge.
My take: maintenance is the product after launch
My take is that the distinction between “build” and “maintenance” becomes artificial once customers depend on the service. Security, support and improvement are how the product continues to exist.
Budget the operating capability explicitly. Otherwise urgent work will consume the roadmap invisibly.
Frequently asked questions
What percentage of build cost should maintenance be?
There is no reliable universal percentage. Model the service, team, risk, vendors, usage and change demand directly.
Is cloud hosting the main maintenance cost?
Often not. People, support, security, dependencies and product change can exceed raw infrastructure.
Can a development agency handle all maintenance?
It can perform agreed work, but the business still needs accountable product, risk and service ownership.
How much incident capacity should we reserve?
Base it on history, criticality and uncertainty, then review when the reserve is repeatedly exceeded or unused.
Fund the service customers rely on
If your business needs a realistic operating and maintenance model for a live application, get in touch for SaaS development and AI automation.
Related guides
For further background, read our cms vs custom development and website maintenance costs. The user journey glossary explains the terminology used in those guides.