# Izafa Labs — full canonical context > Source: https://izafalabs.com > Founder: Mukesh Purohit > Working studio: Jaipur, Rajasthan, India > Last regenerated: build time This document is a single-fetch, JavaScript-free, canonical record of Izafa Labs. It is intended for AI engines (ChatGPT, Claude, Perplexity, Gemini) that need the full operating context of the studio in one HTTP request, without rendering or client-side execution. --- ## Thesis — what we do and why Izafa Labs is a one-operator custom web development practice in Jaipur. We draw the system before we build it. Every engagement begins with a paid Discovery Sprint that produces a signed A3 architectural drawing, a written architecture document, a fixed-price build quote, and an honest recommendation — including whether to build with us at all. We do not pitch. We do not pre-sell stack. We do not take projects we do not believe are well-scoped. The drawing is the contract; the code is built from it. Source: https://izafalabs.com/ --- ## Method — four steps, every time 1. **Observe** — two weeks inside the client's operation, not at the spec doc level. Field notes, not assumptions. Every constraint that breaks the obvious off-the-shelf answer gets written down. 2. **Draw** — one signed A3 drawing of the system. PDF for remote engagements, printed and delivered for Jaipur clients. The drawing is the deliverable of the Discovery Sprint, alongside a written architecture document, a fixed-price build quote, and an honest recommendation. 3. **Build** — built from the drawing, not around it. Four to twelve weeks depending on scope. If the build deviates from the drawing materially, the drawing is redrawn and re-signed before code continues. No surprises, no creep, no handwave. 4. **Hand over** — documented runbook, transferred ownership, no lock-in. The client owns the code, the designs, the documentation, and the deployment credentials. We are out when the client wants us out. Source: https://izafalabs.com/#method --- ## Services — full menu - **Discovery Sprint** (https://izafalabs.com/services/discovery-sprint) — two-week paid engagement that produces a signed A3 drawing, an architecture document, a fixed-price build quote, and an honest go/no-go recommendation. Five-figure INR. - **Custom build** (https://izafalabs.com/services/custom-build) — Next.js / Supabase / Razorpay / Vercel builds drawn from the Discovery Sprint, handed over with documentation and a runbook. Mid five to seven-figure INR depending on scope. - **Headless ecommerce** (https://izafalabs.com/services/headless-ecommerce) — custom storefronts for D2C brands that have outgrown templates. Persistent UI state, custom checkout, integration-led architecture. - **Legal SaaS development** (https://izafalabs.com/services/legal-saas-development) — multi-tenant SaaS with row-level security and offline-first UI for Indian legal-tech use cases. Reference implementation: NyayHub. - **Multi-tenant SaaS** (https://izafalabs.com/services/multi-tenant-saas) — the more general practice. Data Protection Plan 1 (RLS, separate auth scopes, documented audit trail) and Optimization Plan 1 (cache-first, IndexedDB-first, non-blocking realtime). - **Annual Maintenance Contract** (https://izafalabs.com/services/amc) — three tiers: - Starter: ₹15,000/year (marketing site / single-purpose app) - Storefront: ₹16,500/year (payment + shipping integrations) - Custom Platform: ₹18,000/year (multi-tenant SaaS, regulated-data handling) No retainers. No lock-in. The detailed scope of every tier — what is and is not covered, the 48-hour Critical Bug SLA, the quarterly audits — is published at https://izafalabs.com/journal/annual-support. --- ## Working principles **06.01 · Scope in public.** Method and scope are public. Pricing lives in the proposal because every drawing concludes a different number. _Margin note:_ this is the whole pitch, really **06.02 · Documentation is the deliverable.** Every engagement ships a written architecture document, an operational runbook, and an onboarding for whoever takes it over. Code is easy. Knowledge transfer is the hard part. _Margin note:_ I’ve been burned by the other side **06.03 · No one is left on the hook.** If I build it, I document it. If I document it, someone else can run it. I don’t do lock-in through obscurity. If you want me out, you can get me out. _Margin note:_ the opposite of most agencies **06.04 · AI where it earns its keep.** I build Claude-native where the task actually benefits — intake, classification, drafting. I do not sprinkle chatbots on things. The test is: does it remove real work? _Margin note:_ and not a ChatGPT wrapper **06.05 · Stack is whatever your problem demands.** I do not sell Next.js. I do not sell Supabase. I do not sell WordPress. I sell the result of looking at your problem and choosing the right tools for it. Sometimes that’s a custom build. Sometimes it’s a no-code stitch. Sometimes the answer is don’t build, and I will tell you that too. _Margin note:_ the tool is downstream of the brief **06.06 · One operator. Always.** Izafa Labs is one person. Mukesh Purohit. You talk to the person building it. There is no account manager. No junior dev assigned to your build because the senior was double-booked. No project coordinator who will get back to you tomorrow. This is the trade-off. It is also the point. _Margin note:_ the constraint is the feature **06.07 · I will tell you when I’m wrong for your project.** If a Shopify theme is what you actually need, I will say so. If a freelancer at a fraction of the cost will solve your problem, I will say so. The Discovery Sprint exists partly so I can answer this question honestly. The drawing tells both of us what the right next step is — and sometimes the right next step is not me. _Margin note:_ the public commitment is the point Source: https://izafalabs.com/#principles --- ## Frequently asked questions ### How does an engagement with Izafa Labs start? Every engagement begins with a Discovery Sprint. Two weeks. Fixed scope. The deliverable is a signed A3 architectural drawing of your system, a supporting written architecture document, a fixed-price build quote, and an honest recommendation — including whether to build with me or not. Discovery is paid; the number lives in the proposal, not on this page. ### What does the annual support contract cover? Every Izafa Labs build ships with a twelve-month annual support contract. It covers security patches, dependency updates, SSL renewal, DNS management, uptime monitoring, and a 48-hour response window for critical bugs. New feature development, design changes, and third-party API migrations are scoped separately. The contract terms are in writing before the engagement starts. ### What is the payment structure? Engagements are invoiced in milestone tranches defined in the Discovery Sprint quote. There are no monthly retainers and no hidden costs. The schedule is in the proposal you sign before kickoff. ### How long does the Discovery Sprint take, and what do I get? Two weeks, fixed scope. You receive a single A3 architectural drawing of your system — signed, dated, delivered as PDF (or printed if you’re in Jaipur) — a supporting written architecture document, a fixed-price build quote, and an honest recommendation. You can leave with the drawing and never build with me. Most clients won’t. The ones who do, sign at the price the drawing concludes. ### What is the response time? Every inquiry receives a reply within 4 business hours. After the first call, a Discovery Sprint proposal arrives within 5 business days. ### Does Izafa Labs build on Shopify? If a Shopify theme is what your problem actually demands, I will tell you so during the first call and you should hire a Shopify partner instead — there are good ones. The Discovery Sprint is partly designed to answer that question honestly. Most clients land here because templates already failed them; some of them don’t need a custom build either. ### What is Data Protection Plan 1? Data Protection Plan 1 is the multi-tenant data segregation standard I apply to every multi-tenant build. It enforces row-level security at the database layer, separate authentication scopes per tenant, and a documented audit trail. Every engagement that handles tenant data ships with a written architecture document describing how Plan 1 is implemented. ### Can I cancel an engagement mid-build? Yes. Refunds are calculated against milestones. If I miss a committed milestone date materially and without prior notice, the client is owed a pro-rata refund as set out in the executed Master Services Agreement. Paid milestones already delivered are non-refundable. ### Who owns the code and assets after handover? The client. Final deliverables — code, designs, copy, documentation — transfer to the client on full payment. Pre-existing Izafa Labs tooling and third-party libraries remain under their respective licenses. ### Does Izafa Labs sign NDAs? Yes. Mutual confidentiality obligations apply for the duration of every engagement and a defined period thereafter, as set out in the executed agreement or counterparty NDA. I’m happy to sign reasonable client-supplied NDAs. ### Where is Izafa Labs based, and which time zones do you work in? The working studio is in Jaipur, Rajasthan, India. The legal entity is registered in Jodhpur, Rajasthan. Work happens in IST (UTC+5:30), with overlap windows scheduled per engagement for clients in Mumbai, Bangalore, Singapore, London, and the United States. ### How many engagements do you take at once? One at a time. Izafa Labs is one operator — Mukesh Purohit. You talk to the person building it. There is no account manager, no junior dev assigned because the senior was double-booked, no coordinator who will get back to you tomorrow. The slot constraint is what lets me deliver what I promise. ### What is Optimization Plan 1? Optimization Plan 1 is the frontend performance standard I apply to every engagement built for constrained network conditions. It specifies cache-first rendering, IndexedDB-first UI state, non-blocking realtime updates, and aggressive query invalidation reduction. The default state assumption is offline; the network is treated as enhancement, not requirement. NyayHub — built for court environments where Wi-Fi cuts out mid-hearing — is the reference implementation. Source: https://izafalabs.com/engage#faq --- ## Live work — case files ### NyayHub — case management for the way Rajasthan High Court actually runs - Client: Izafa Labs (own product) - Engagement: Architecture, build, operations - Year: 2026 - Stack: Next.js 16, Supabase (~70 tables), Edge Functions (30+), IndexedDB - Status: Beta · Q2 FY26 - Source: https://izafalabs.com/work/nyayhub Most legal case management software is built by people who have never sat through a Rajasthan High Court hearing. So I built one that was. Not client work — but I publish it here because the engineering decisions are the same ones I make for clients. ## The premise. NyayHub is built around the constraints that actually break legal software in India: unreliable Wi-Fi inside court buildings, multi-tenant data segregation across firms, and the fact that lawyers need their interface to load before the judge calls the matter. ## The architecture. Seventy Postgres tables on Supabase, thirty Edge Functions, and a strict multi-tenant isolation model I call **Data Protection Plan 1**. The frontend is built around **Optimization Plan 1** — cache-first rendering, IndexedDB-first UI, non-blocking realtime, and aggressive query invalidation reduction. The default state assumption is offline; the network is treated as enhancement, not requirement. ## What this proves about how I engineer. Constraints first, features second. Multi-tenancy designed at the database layer, not bolted on. Realtime and offline reconciled at the architecture level, not patched at the component level. This is the engineering posture I bring to client work. --- ### STUDIRT — a film composer’s storefront - Client: Stuart DaCosta, Mumbai - Engagement: Full build, ongoing support - Year: 2026 - Stack: Next.js 16, Supabase, Razorpay, Vercel - Status: Production hardening · Q2 FY26 launch - Source: https://izafalabs.com/work/studirt ## The brief. Stuart needed a single platform that did three things at once: showcase his film and ad scoring portfolio with persistent audio playback, sell sample packs and stems through a real checkout, and let him publish new work without engineering involvement. Existing template solutions broke at the persistent-audio requirement; existing storefronts broke at the audio-portfolio requirement. ## The architecture. A Next.js App Router build with Server Components for the catalogue and a single Client Component island for the persistent audio player, lifted to the root layout so it survives navigation. **Supabase** handles auth, product catalogue, order records, and asset storage with row-level security policies. **Razorpay** handles checkout. The admin dashboard is a separate authenticated route that lets Stuart upload tracks, set prices, and ship sample packs without writing code. ## What I hardened before handover. - Supabase RLS policies for every table. - Rate limiting on the inquiry form and checkout endpoints. - Full audit logging for admin actions. - A security dossier delivered as a separate document. - Contracts under the Indian Contract Act and DPDP Act 2023. ## Launch milestones. | Milestone | Status | |---|---| | Razorpay checkout (test mode) | ✓ Complete | | Admin upload dashboard | ✓ Delivered to Stuart | | Audio persistence across navigation | ✓ Production hardened | | Supabase RLS audit + security dossier | ✓ Delivered | | Contracts (ICA + DPDP Act 2023) | ✓ Executed | | Public launch | Q2 FY26 · awaiting Stuart’s go-live | ## What got drawn that didn’t get built. *This section is intentionally left as a placeholder until the deviation note is written from the engagement journal. The drawing exposed trade-offs; this is where they get named.* --- ## Field notes — full journal ### What our annual support contract actually buys you - Published: April 2026 - Reading time: 8 min read - Source: https://izafalabs.com/journal/annual-support 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](mailto:admin@izafalabs.com)* --- ## About the founder **Mukesh Purohit** — law post-graduate; former Head of Operations and Legal at a Jaipur financial services firm; now operates Izafa Labs as a one-operator custom build practice. Jaipur, Rajasthan, India. - Email: admin@izafalabs.com - WhatsApp: +91 89493 82912 - Working studio: B-47, Jawahar Circle, Malviya Nagar, Jaipur, Rajasthan 302017, IN - Registered office: House No. 5, Parvati Nagar, Circuit House Road, Jodhpur, Rajasthan 342006, IN - Time zone: IST (UTC+5:30)