Journal · April 2026

What our annual support contract actually buys you

Reading time8 min read

Every Izafa Labs engagement ships with a twelve-month annual support contract. The terms are written into the engagement proposal, not negotiated in retrospect. This is what that contract actually covers.

— Mukesh Purohit · April 2026


What the AMC covers

Security patches. When a critical CVE lands in a dependency your site uses, I patch and deploy within fourteen days of public disclosure. High-severity advisories are patched within thirty days. I monitor the advisory feeds for Next.js, Supabase client libraries, Razorpay SDK, and the rest of the standard stack. You don’t need to track this yourself.

This is different from a bug fix. A security patch is a scheduled maintenance activity on a known timeline. A Critical Bug — something actively breaking your production system — has a tighter response clock described below.

Dependency updates. Once per quarter, I audit the full dependency tree, apply non-breaking minor and patch upgrades, run the test suite, and deploy. This keeps you off the two-year-old minor version that nobody will support when something breaks. It also means that when you come to me for new feature work, I’m building on current libraries — not digging out of an upgrade hole first.

SSL renewal and DNS management. Certificates renew automatically through the hosting platform, but I verify the renewal happened and catch edge cases (CAA records, certificate transparency delays, wildcard misconfigurations). If your DNS needs a change — an MX record for a new mail provider, a CNAME for a third-party integration — this is covered. The management is included; the cost of domain registrations and hosting subscriptions is not — those are reimbursed at cost.

Uptime monitoring. External uptime checks run at five-minute intervals. If your site goes down, I get the alert before you do.

Critical Bug response. A defect qualifies as a Critical Bug if it falls into one of these categories: the site is substantially unavailable; payment processing is failing for all or most transactions; user data is lost, corrupted, or exposed; a security vulnerability is being actively exploited; or authenticated users cannot access the system or perform their primary function.

For Critical Bugs: I acknowledge within four business hours, provide an initial root-cause assessment within twenty-four hours, and deliver a fix or documented workaround within forty-eight hours of acknowledgement. Where a fix isn’t technically achievable in that window, I communicate the cause, expected timeline, and available mitigations.

Four consultation hours per quarter. Up to four hours per calendar quarter of routine advisory time at no additional charge — for questions about performance interpretation, integration decisions, security advisory triage. Hours not used in a quarter don’t carry forward.

Monthly and quarterly reporting. By the seventh business day of each month, you receive an uptime report covering availability statistics, incidents, and patches deployed. Each quarter you receive a dependency audit summary — packages updated, packages deferred with reasons, and any deprecation notices affecting your system. At the end of the year, you receive an annual security advisory log.


What the AMC does not cover

This is the part most studios bury in fine print. I put it in the contract and I’m putting it here.

New feature development. If you want to add a feature — a new product type, a discount code system, a referral programme, a new page — that’s a new engagement or a defined change order. The AMC is maintenance, not development.

Design changes. Reskinning, layout changes, new brand assets: not covered.

Content updates beyond two per month. I’m happy to update a phone number or fix a typo — up to two routine content updates per month, each not exceeding thirty minutes of effort. If you’re sending more than that, it’s editorial support, not maintenance, and it should be scoped and priced accordingly.

Third-party API changes. If Razorpay changes their webhook format, if Shiprocket deprecates an endpoint, if your email provider migrates their API — responding to upstream changes that aren’t security-related falls outside the AMC. I’ll give you a fixed-cost quote to handle it. This sounds harsh, but it’s the honest version: if upstream migration work were included in the AMC, the AMC price would have to absorb worst-case third-party churn for every client. It would no longer be maintenance.

Issues caused by third-party modifications. If you or another vendor modifies the production codebase without informing me, and that modification causes the issue under report, my obligations in respect of the affected components may be voided. This protects both sides — it means I’m not responsible for debugging changes I didn’t make, and it creates a clear incentive to loop me in before touching production.

Performance optimisation. The site shipped fast. If it gets slower because your catalogue grew or your traffic patterns changed, optimisation work is scoped separately.


How it’s tiered

The AMC is priced on system complexity, not project value. The tier is fixed at the Effective Date of the contract and documented in the engagement proposal — alongside the build quote that comes out of your Discovery Sprint.

Marketing site / single-purpose application. Low integration count, single-tenant data model. One deploy target, a handful of external dependencies.

Storefront with checkout. Payment gateway and shipping integrations, single-tenant data model with order and customer state. More moving parts, more monitoring coverage required.

Custom platform. Multi-tenant SaaS, complex integrations, custom auth flows, internal admin tooling, audit logging, regulated-data handling. The most surface area, the highest monitoring overhead, the tightest security advisory requirements.

If the system grows materially beyond its original scope, the tier is renegotiated at renewal — with a cap of ten percent annual increase unless there’s a material change in scope or third-party cost base.

The number itself lives in the proposal. It isn’t on this page because every drawing concludes a different one.


How I track and report

Every month you receive an uptime report. It is one page. It shows availability percentage, incident count (including incidents I caught and resolved before they affected you), SSL certificate status, and any notable patches deployed in the period.

Every quarter you receive a dependency audit summary. Every year you receive a security advisory log covering everything evaluated across the twelve months.

Neither document requires you to do anything. They exist so you have a record of what was done, and so you can make informed decisions about when to invest in new feature work or a platform upgrade.


When to upgrade

The AMC is not a retainer. It does not give you guaranteed development hours. If you start finding that you need engineering work every month — new features, integrations, architecture changes — the right structure is a scoped engagement, not an expanded AMC.

Three signals that you’ve outgrown the AMC:

You’re sending more than two content changes per month. If I’m fielding content updates regularly, a small retainer with defined hours is a cleaner structure than treating each request as out-of-scope.

Your platform is ready to grow. The AMC was designed around a stable system. If your store is adding a new fulfilment partner, a B2B sales channel, or a new product category, you’re in new-build territory — that’s an engagement, not maintenance.

Your traffic has changed materially. A storefront sized for 500 concurrent users at launch may need a different Supabase configuration, a different caching strategy, or a different deployment architecture at 5,000. That’s engineering work, not maintenance.


One thing worth saying plainly

The AMC exists because I want to know what happened to the things I built. I don’t hand over a codebase and disappear. The monitoring, the quarterly audits, the 48-hour bug SLA — they’re not a product feature. They’re how I stay responsible for work that has my name on it.

If the site I built for you fails at 2am on a Tuesday because a dependency update broke the payment webhook, I want to be the one who gets the alert. Not because I’m obligated to, but because I wrote the code and I should care about whether it runs.

That’s what this contract is actually buying. Not support tickets. Accountability.

— Mukesh Purohit · April 2026


Questions about the AMC for your project? admin@izafalabs.com