SaaS Maintenance

What Happens After Launch

The work of building a product doesn't end at launch. In some ways it intensifies. Before launch, the only people using the product are the team and a small group of testers who are motivated to find issues. After launch, real users use the product in ways you didn't anticipate, with data in formats you didn't expect, on devices and browsers you didn't test, with workflows that expose edge cases in your assumptions. The volume of issues that surface in the first month after launch often exceeds what was found in all of testing.

At the same time, the infrastructure needs to be watched. Logs fill up. Database tables grow and queries that were fast with small datasets become slow. Dependencies release security patches. The cloud provider deprecates a service. Third-party APIs change their behavior. None of this is dramatic, but all of it requires ongoing attention to keep the platform working reliably.

Most SaaS companies underestimate the engineering time required to maintain a production system properly. If you're not actively maintaining it, entropy wins: security falls behind, performance degrades, technical debt accumulates, and the cost of future development increases steadily. Ongoing maintenance is an investment in the platform's long-term quality.

What Good Maintenance Includes

Bug fixes are the most visible part of maintenance — the things users report that aren't working as expected. We triage incoming bugs by severity and fix critical ones quickly. But reactive bug fixing isn't the complete picture of maintenance. Most of the value in a good maintenance program is proactive: catching issues before users report them, rather than after.

Proactive maintenance means reviewing error logs regularly to find exceptions that are happening silently without user reports. It means monitoring performance metrics and investigating when response times are trending upward before they become noticeable. It means reviewing database query performance periodically as data grows. It means looking at warning-level log messages that aren't critical now but may be pointing to problems that will become critical later.

Dependency Management

A production application has dozens or hundreds of third-party dependencies. These dependencies release updates — sometimes for new features, sometimes for bug fixes, and sometimes for security vulnerabilities. Falling significantly behind on dependencies is a common and underappreciated form of technical debt. The further behind you are, the more work each individual update involves (because the gap between current and target versions is larger), and the higher the risk that you're running code with known, publicly disclosed security vulnerabilities.

We manage dependencies as a routine part of maintenance: monitoring for security vulnerabilities in the dependency tree, updating dependencies regularly to avoid large version gaps, and testing updates carefully to catch breaking changes. For security vulnerabilities with a CVE, we prioritize based on the severity and the actual exploitability in your specific application context — not all CVEs in your dependency tree represent real risk, but the ones that do need prompt attention.

Database Maintenance

Databases need maintenance that's different from application code maintenance. PostgreSQL databases accumulate dead rows from updates and deletes that need to be cleaned up via vacuum operations — automated in PostgreSQL but worth monitoring to ensure autovacuum is keeping up. Indexes become bloated over time and need periodic reindexing. As table sizes grow, query plans change and queries that were fast may become slow without any change in the application code.

We monitor database health metrics: table and index sizes, vacuum and analyze status, slow query logs, connection pool utilization. We perform regular query performance reviews to catch queries that have degraded with data growth. We review and add indexes as query patterns evolve. We handle database version upgrades, which are necessary for continued security support and access to performance improvements in newer versions.

Infrastructure Maintenance

Cloud infrastructure requires ongoing management: OS security patches, container base image updates, SSL certificate renewals, storage capacity management, and periodic reviews of security configurations. We handle these systematically — scheduled maintenance windows for updates that require restarts, monitoring for certificate expiry, alerts for storage and resource utilization before they become critical.

We also review cloud costs periodically. As a product evolves, the infrastructure requirements change, and the configuration that was appropriate at one stage may be wasteful at another. Unused resources, oversized instances, and suboptimal service choices accumulate over time. Periodic cost reviews typically find meaningful savings without reducing capability.

Feature Development Allocation

Most maintenance plans include a monthly allocation of development hours for small feature additions and improvements. This is valuable because the backlog of small improvements that don't justify a full project engagement always exists: a UX improvement that would take a day, a small feature that a customer has requested, a reporting addition that would save the operations team an hour a week. Having a development allocation for these means they actually get done rather than accumulating indefinitely.

We work from a prioritized list that's maintained jointly with you. Each month, we review what's in the list, confirm priorities, and complete as much as the allocation allows. You always know what's being worked on and the status of items in the list.

Communication and Reporting

At the end of each month, you receive a written summary of maintenance activity: bugs fixed, dependencies updated, any issues found proactively and addressed, infrastructure changes made, and anything worth noting for awareness. This report is kept brief and focused on what actually happened and what you should know about — not a padding document.

We communicate proactively when something unusual happens: a performance degradation that's being investigated, a dependency with a high-severity CVE, an infrastructure issue that required immediate attention. You hear about these in real time, not in next month's report.

Frequently Asked Questions

What's the minimum engagement for maintenance? We structure maintenance engagements for products that are in active use and require reliable operation. The scope depends on the complexity of the product and the level of ongoing development work needed.

Can you take over maintenance from our previous team? Yes. We do a technical review of the product before taking over maintenance to understand the codebase, the infrastructure, and any known issues. This gives us a baseline and surfaces anything that needs immediate attention.

What response times can we expect for bugs? Critical issues (the product is down or there's a security incident) get immediate response. High-severity issues (a core feature isn't working) are addressed within one business day. Medium and low severity issues are addressed according to the maintenance schedule.

Getting Started

Tell us about the product: the technology stack, the current maintenance situation (is it currently maintained, if so by whom), and the most pressing concerns. We'll review the product and propose a maintenance structure appropriate for it.