# Maintenance and Support > Ongoing maintenance, monitoring, dependency and security upkeep for products in production. A 30 day warranty, then four severities with published response targets. Source: https://www.koombea.com/capabilities/maintenance-and-support/ --- A product in production needs dependency updates, security patches, monitoring that someone reads, and a path for the bug a customer found on Sunday. ## The problem This is the thing clients buy most often. Software does not hold still. Dependencies deprecate, certificates expire, an OS release breaks an assumption, and volume grows past what an early decision could carry. Left alone, that accumulates quietly for two years and then presents as a crisis with no obvious cause. Handled continuously, it is a small, predictable draw on capacity. While a Pod is running, maintenance draws from the same point capacity as feature work, so you can see the trade you are making. When a month goes heavily to upkeep, that shows in the capacity report, and it becomes a conversation rather than a surprise. After a build ends, this becomes its own thing. A 30 calendar day warranty covers qualifying defects in our code at no cost, starting from your written acceptance of the production launch. Beyond that, support is a separate monthly plan sized in points, from light upkeep on a stable product through to priority queueing on one that is still moving. - A 30 day warranty on delivered software, then an optional monthly plan - Dependency and security upkeep on a schedule, not on an incident - Monitoring configured so alerts mean something and get read - Four severities with response targets, agreed before launch ## What this covers - **Security upkeep**: Patching, dependency audits, and response to disclosed vulnerabilities. - **Monitoring that is read**: Alerting tuned to the business fact, reviewed as part of the cycle. - **Performance drift**: Catching slow degradation before users call the product slow. - **Infrastructure care**: Cost, capacity, and configuration reviewed rather than left to grow. - **Production issue path**: Agreed severities and response expectations, written down. - **Continuity**: Documentation and access that survive people changing jobs. ## If it is not tested, it does not exist Monitoring is the thing every partner claims and almost nobody proves. An error tracker with no DSN configured, a log line nobody ships anywhere searchable, an alert routed to a channel that was muted last quarter: all of these look like observability on a slide and none of them will tell you when your product breaks. So we treat it as a feature with its own acceptance criteria. If error capture is not verified by deliberately triggering an error and confirming it arrived with the right context, it is aspirational. The same goes for the structured log lines a background job emits and for the alert that is supposed to page someone. There is a specific reason this matters more on AI-First delivery. The failures that reach production from generated code are rarely crashes. They are plausible interpretations of an ambiguous requirement that produce quietly wrong results, contracts that drifted after the integration was written, and database queries that are correct but generate one call per row. None of those announce themselves. All of them are visible in performance traces and error context if the wiring is real. - Error tracking across frontend, backend and background jobs, with release and user context - Performance tracing with a p95 baseline per endpoint, so a regression is a number rather than a feeling - Query-explosion detection, which is the most common performance smell in generated code - Structured logs with a correlation ID, so one user action can be reconstructed end to end - Health checks that test real dependencies, not just that the process is alive - Alerts routed to a named owner per area, by severity ## Four severities, agreed before you need them Response targets are business hours, on reproducible defects in code we wrote, while a support plan is active. Published here rather than negotiated during an incident. | | Initial response | Containment | Target resolution | |---|---|---|---| | P1. Critical: a core flow is down with no workaround | Within 2 business hours | Within 1 business day where feasible | Within 2 business days for defects in our code | | P2. High: major degradation, partial workaround exists | Within 4 business hours | Within 2 business days where feasible | Within 5 business days for defects in our code | | P3. Medium: partial malfunction, limited business impact | Within 1 business day | As mutually prioritized | Next available cycle | | P4. Low: cosmetic or minor usability | Within 2 business days | Not applicable | Prioritized into the backlog | These are not an uptime guarantee and do not include 24/7 monitoring or after-hours on-call unless separately contracted. Where a third party controls the fix we investigate and contain, but cannot commit to a resolution window that is not ours. ## Where a support plan stops A maintenance plan is business hours, Monday to Friday. It is not an uptime guarantee and it is not an operations team. Round-the-clock monitoring, an on-call rotation, and infrastructure operations such as provisioning, scaling and disaster recovery are all real work, and all of them are scoped separately rather than quietly assumed into a monthly fee. Two other boundaries are worth saying out loud. A major framework or runtime upgrade that needs a coordinated migration is a project, not maintenance. And penetration testing and formal security audits belong to our governance practice, on a retainer or fixed fee, because an audit opinion is not a story point. Unused capacity in a support plan does not roll over, which is the opposite of how banked points work on a Pod. We would rather you knew that before you picked a tier than after. - Business hours support, Monday to Friday, excluding company holidays - 24/7 monitoring, on-call, and infrastructure operations scoped separately - Major version migrations handled as a project, not as upkeep - Anything above the plan capacity is estimated and agreed before it starts ## What drives the estimate Support plans are sized in monthly point capacity, so choosing a tier is really a forecast of how much change the product will absorb. Two products with identical feature sets can need very different plans. The dominant factor is dependency surface. A product resting on six third-party services inherits six other companies' release schedules, deprecations and outages, and someone has to absorb that whether or not you planned for it. - How many third-party services you depend on, and how aggressively each deprecates - Whether the product is still changing or genuinely stable - Regulated data in scope, which makes patching a compliance obligation rather than a preference - Mobile in the mix, because OS releases arrive on Apple and Google's schedule, not yours - Traffic growth, which turns yesterday's reasonable decision into today's bottleneck ## Questions worth asking ### Can you maintain a product another partner built? Yes, and it starts with a discovery pass so we know what we are agreeing to support. Committing to response targets on a codebase we have not read would be a promise we could not keep. The documentation pass under platform modernization is often the right first step. ### Does unused plan capacity roll over? No. Banked points on an AI Pod carry forward for 90 days. Unused capacity in a support plan does not roll over unless the agreement says otherwise. Do not assume the Pod behavior applies here. ### What is covered by warranty versus by a plan? The 30 day warranty covers qualifying defects in code we wrote, at no cost, from your written acceptance of the launch. It does not cover new features, changes you or a third party deployed, or third-party failures. After it expires, a support plan is how the same work keeps happening. ### Do we need a plan at all? Not necessarily. A genuinely stable product with few dependencies can go a long time on nothing, and we will tell you when that is your situation rather than selling you a retainer. The products that need one are the ones still changing or carrying regulatory obligations. ### What if we need something outside the plan? It is estimated in points and agreed in writing before it starts, at the same rate as any other work. There is no penalty and no premium for being outside the plan. ## Support measured in years Maintenance is why several of the engagements on our work page have run for years rather than months.