Launch is the start of the expensive part.
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.
| Dimension | 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?
Does unused plan capacity roll over?
What is covered by warranty versus by a plan?
Do we need a plan at all?
What if we need something 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.
Bring us the backlog.
In 30 minutes, we will show you what a Pod would ship first and how we would price it.