AI Engineering
We build web applications where the model is part of the product — streamed responses, retrieval-backed search, agentic workflows the user can watch and interrupt. Engineered for token cost, latency and the days the model fails.
AI web development is the building of web applications where the model is part of the product surface — answers that stream as they generate, search grounded in your own documents, workflows an agent runs while the user watches — rather than a chat bubble bolted onto a marketing site. ZenMagix is an AI web development company in Mumbai that builds these products for founders and engineering teams shipping to real users. We came to this from blockchain and distributed systems: years of exchange backends, wallet infrastructure and settlement pipelines, where partial state, retries and cost per operation were daily concerns long before anyone was streaming tokens into a React tree. That background matters more than it sounds. An AI-powered web application is not a CRUD app with a new API call in it. The response arrives in pieces, costs money per request, takes seconds instead of milliseconds, and sometimes returns something confidently wrong or nothing at all. We design the interface, the data layer and the failure paths around those four facts.
The moment a response streams token by token, the request-response model your frontend assumes stops holding. Application state becomes partial, cancellable and resumable — and every component rendering it has to handle all three.
A normal request has two states: loading, then done. A generation has five — pending, partial-and-renderable, partial-and-invalid (half a JSON object), cancelled mid-flight, and failed after the user already read three paragraphs. That last one is the interesting case, because you cannot show an error toast over content someone is mid-sentence into. We stream over server-sent events for one-way token flow, because SSE survives corporate proxies and reconnects on its own; WebSockets are reserved for surfaces where the client also streams, such as voice or collaborative cursors.
The stream is persisted server-side under a generation ID, usually in a Redis stream, so a page refresh or a dropped mobile connection reattaches to the run in progress instead of throwing away twenty seconds of output you already paid for. Stop buttons are wired through AbortController all the way to the upstream provider, not just to an unmounting component — otherwise the tokens keep billing after the user has walked away. Structured output gets incremental JSON parsing so a table, a form or a chart fills in progressively rather than appearing in one jump at the end.
And we optimise for time-to-first-token, not total duration: 400ms to first word with a steady stream reads as fast, while three seconds of skeleton loader followed by an instant dump reads as broken.
Most AI product surfaces reduce to four patterns — streamed generation, retrieval-backed search, agent runs the user can watch and interrupt, and shared realtime state. The engineering problems come from combining them without a plan.
In-app retrieval is where quality is won or lost. We run hybrid search — dense vectors in pgvector alongside lexical search in Postgres full text — fused and then reranked, because pure embedding search misses exact identifiers, part numbers and names that your users search by constantly. Permission filtering happens inside the query, on tenant and ACL fields, never as a filter applied after the top-k comes back, which either leaks documents or silently starves results.
Answers carry citations that anchor into the source document at the right position, so a user can verify in one click instead of trusting the model. Agentic surfaces run server-side against a durable job, streaming a step log to the browser: closing the tab must not kill a five-minute run, and the interface needs an interrupt and an approve or reject control for anything that writes. For collaborative products we use CRDTs, typically Yjs with server-side persistence, and apply model-generated edits as a named actor inside the same document — so an AI rewrite merges, conflicts and undoes exactly like a colleague's edit rather than overwriting whatever a teammate typed while the generation was in flight. The rule that keeps this coherent: a generation belongs to the document or the workspace, not to the socket that happened to start it.
Because the hard part of an AI web app is not the prompt — it is unit cost, tail latency, and what the screen does when the provider returns a 529. We build those three in from the first sprint rather than after the first bad month.
Cost is measured per session and per active user, not per token, because that is the number your pricing has to survive. We cut it with prompt caching on stable system instructions and retrieved context, model routing so classification, extraction and routing calls go to a small fast model while only synthesis reaches a frontier one, and semantic caching on repeat queries. Hard ceilings sit per user and per organisation, with a real UI path when a limit is hit instead of a surprise invoice at month end.
Latency budgets are set per surface and enforced: inline autocomplete gets roughly 300ms and a small model, a research panel may take twenty seconds provided it streams visible progress the whole way. Degradation is designed, not improvised — every AI path has a defined non-AI fallback, so semantic search drops to lexical when the embedding service is down, summaries fall back to the last cached good version, and a generation panel fails into an editable empty state with an honest error rather than a spinner that spins forever.
Circuit breakers sit per provider with a secondary model behind the same interface. Evaluations run in CI against a golden dataset built from your real content, scoring retrieval precision, groundedness, refusal behaviour, latency and cost, and a pull request fails when groundedness drops — so a prompt tweak or a model upgrade is measured rather than hoped about. Code, prompts, evals and infrastructure are yours from day one.
We work in IST, which overlaps a full working day with Europe and almost all of APAC, and we can be in your office within a day anywhere in India. The cost structure matters too — but mostly because it changes what you can afford to build.
IST is UTC+5:30. That gives roughly five hours of live overlap with London and Berlin, six or more with Dubai, and near-total overlap with Singapore, Bengaluru and Sydney — enough for daily standups, pairing sessions and same-day decisions rather than a 24-hour round trip on every question. North America is the honest exception: we hold two to three hours with US East Coast by starting our day late and yours early, and roughly one with the West Coast, so those engagements run on written end-of-day handoffs covering decisions, blockers and what needs your answer before we log on.
We say that up front rather than discovering it in week three. On cost, a Mumbai team is materially cheaper per engineer-hour than an equivalent London or Bay Area shop, and the useful consequence is not a smaller invoice — it is that the eval harness, the observability, the fallback paths and the load testing all fit inside a budget that would otherwise only cover the happy path. Those are the parts teams cut first when engineering hours are expensive, and they are the parts that decide whether an AI product survives contact with real usage.
For Indian clients we run discovery workshops on site — we are in Mumbai, and Pune, Bengaluru, Hyderabad and Delhi NCR are same-day trips. Data residency is a deployment decision, not a team location one: we deploy into AWS ap-south-1 in Mumbai for clients with DPDP Act obligations, and into eu-central-1 or a customer VPC for European clients, with our engineers operating as processors under your DPA. The hiring pool here helps as well. Mumbai is India's exchange and fintech engineering centre, which means the people we recruit have already built systems where latency, idempotency and audit trails were non-negotiable — the same instincts an AI product needs once it has paying users.
What you get
A written design of every AI surface: transport, stream persistence and resume behaviour, partial-state rendering, cancellation, latency budget and the fallback for each path when the model is slow, wrong or unavailable.
The shipped product — typed end to end, streamed AI surfaces, authentication, multi-tenancy and role-based access, deployed to your cloud with CI/CD, preview environments and infrastructure as code.
Ingestion and chunking pipelines, hybrid vector and lexical search with reranking, permission-aware queries, citation anchoring, and re-indexing that runs without downtime as your content changes.
Model routing, prompt and semantic caching, per-user and per-org spend ceilings, circuit breakers with a secondary provider, plus dashboards showing cost per session, time-to-first-token and error rates by surface.
A golden dataset from your real content scoring retrieval precision, groundedness, latency and cost, wired into CI, with architecture docs and working sessions so your team can change prompts and models without us.
How we work
One to two weeks defining which screens genuinely need a model, what each one costs per use, and what the user sees when it fails. Surfaces that a query or a rules engine handles better get built that way.
One real surface end to end against real data — streaming, cancellation, resume, citations, error states. This is where time-to-first-token and cost per session stop being estimates and become numbers.
Build the retrieval layer properly, add caching, routing, ceilings and fallbacks, assemble the golden dataset, set pass thresholds, and load-test the streaming paths under concurrency.
Production release behind feature flags, then weekly review of usage, cost per session, retrieval misses and abandonment mid-generation. Prompts, routing and chunking get tuned against real behaviour.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
The response arrives in pieces, costs money per request, takes seconds rather than milliseconds, and can be confidently wrong. That changes the frontend architecture — partial and resumable state, cancellation, progressive rendering — and adds a cost and evaluation layer that a conventional CRUD application never needs.
Almost always we extend what exists. AI surfaces sit alongside your current stack: a retrieval service, a streaming endpoint, and new components on the screens that need them. A rewrite only makes sense when the current frontend cannot support streamed or partial state at all, which is rare.
A focused product with two or three AI surfaces, real retrieval, auth and multi-tenancy typically ships in ten to sixteen weeks. A single AI feature added to an existing application is usually four to six. Both include the eval harness and fallback paths, which are not optional extras here.
Per engineer-hour, yes — typically a third to a half of a comparable London or US agency. But model and infrastructure spend is priced in dollars and identical wherever you build, and the cheapest quote you receive is usually the one that skipped evals and fallbacks. Judge on scope and engineering depth, not rate.
Every AI path has a designed fallback. Semantic search drops to lexical, summaries serve the last cached good version, and generation surfaces fail into an editable empty state with a clear message. Circuit breakers route to a secondary provider behind the same interface, so an outage degrades the product instead of breaking it.
We instrument cost per session and per active user from the first release, then control it with prompt caching, routing cheap calls to small models, and semantic caching on repeat queries. Hard per-user and per-org ceilings with a proper UI response mean growth never produces an invoice nobody forecast.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
A paid diagnostic that tells you what is worth building and what is not.
The pipelines and quality layer every AI project stalls on.
A working AI product in weeks, scoped to prove one thing to investors or users.
See also: let the workflows behind the interface run themselves with AI agent development · ground in-app search in your own documents with RAG and LLM integration · get the first version in front of users faster with AI MVP development
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
