Web applications built AI-native from day one

Generation that takes eight seconds and appears all at once feels like eight seconds of nothing. The same generation streamed feels like roughly the 400 milliseconds it took to produce the first token, because the user starts reading immediately and reading consumes the rest of the wall-clock time. Nothing else in an AI product produces that scale of perceived improvement for that little engineering.

Doing it properly means streaming end to end. The model endpoint streams, the server relays without buffering, and the client renders incrementally — including markdown that is still incomplete, which requires a parser tolerant of half-finished structures rather than one that throws until the closing token arrives.

The metric to optimise is time to first token, not total generation time. Users tolerate long generations they can watch; they do not tolerate silence. We measure TTFT at the 95th percentile because the average hides exactly the sessions that lose users, and we treat a regression in it as seriously as a regression in correctness.

Optimistic UI extends the same principle to actions. When a user accepts a suggestion, apply it immediately and reconcile with the server afterwards, rolling back visibly on failure. The pattern is familiar from well-built conventional apps; it matters more here because AI interactions are frequent and small.

Professionals will not act on output they cannot verify, and no amount of model quality substitutes for the ability to check. In the products we have built for legal, financial and clinical users, the features that drove adoption were consistently the verification affordances rather than the generation quality.

Citations must resolve precisely. A link to a 90-page document is not provenance; highlighting the specific paragraph the claim came from is. That precision requires retrieval that tracks source spans through chunking and generation, which is an architectural decision made early rather than a display feature added late.

Every AI action should be proposed before it is applied. Show the diff, let the user accept, edit or reject, and make undo real rather than nominal. This single pattern is what makes users comfortable granting an AI system write access to anything that matters, and its absence is the most common reason a promising internal tool stalls at pilot.

Communicate uncertainty rather than flattening it. Output the model is unsure about should be visibly distinguished — and where the system genuinely does not know, saying so plainly builds more trust than a confident guess destroys. Users forgive "I could not find this in your documents"; they do not forgive being wrong confidently twice.

Finally, make the AI’s role legible. Users should always be able to tell what was generated, what was retrieved and what they wrote themselves, especially in collaborative documents where authorship carries professional weight.

AI web applications sold to enterprises get security-reviewed harder than conventional SaaS, because buyers are still calibrating their risk and because a model in the architecture raises questions no questionnaire had two years ago. Building for that review from the start costs little; retrofitting it stalls deals for quarters.

Tenant isolation is enforced at the data layer with row-level security rather than in application code alone, so a query missing a filter fails closed. Retrieval indexes are partitioned per tenant — a shared vector store with tenant metadata as the only separation is a serious leak waiting to happen, and it is a design we are frequently asked to remediate.

Prompt injection is the vulnerability class specific to this architecture, and it is real. Any content the model reads that a user did not author — an uploaded document, a scraped page, an incoming email — can carry instructions. We treat that content as untrusted data: instructions inside it are neutralised, tool calls are validated against the original user intent, and no retrieved content can escalate the session’s permissions.

The rest is conventional but non-negotiable: SSO and SCIM, role-based access control, audit logs covering AI actions as well as user actions, zero-retention model endpoints, and configurable data residency. We prepare the security documentation — architecture diagram, data-flow description, subprocessor list — alongside the build, so the answer to the first enterprise questionnaire is a document rather than a project.

A per-seat AI product with unmetered generation has an unbounded cost per seat, and the heaviest 5% of users can consume more than the rest combined. Products priced without modelling that distribution discover the problem at the worst possible moment: after growth.

We model cost per active user against actual usage distributions rather than averages, and design the pricing and the architecture together. Model routing sends the majority of calls — classification, short summaries, formatting, retrieval decisions — to small fast models, reserving frontier models for genuine reasoning. Prompt caching removes the cost of resending stable context. Streaming allows early termination when the user stops reading, which sounds marginal and is not at high volume.

Metering belongs in the product from day one even if you do not bill on it. You need to know cost per customer, per feature and per plan to price rationally, to spot an account whose usage has gone pathological, and to have the conversation with a customer who is genuinely using ten times what they pay for. Adding metering after launch means reconstructing history you do not have.

Gross margins of 70–85% on AI features are achievable with this discipline. Products that skip it commonly run at negative margin on their heaviest cohort without knowing it — which we have been called in to diagnose more than once.

Usage counts tell you almost nothing about AI feature quality: a user regenerating four times is engaged and unhappy. The metrics that matter are behavioural and specific.

Acceptance rate — what share of AI suggestions does the user take? Edit distance on accepted output — when they take it, how much do they change? A high acceptance rate with heavy editing means the output is a useful starting point but not a finished one, which is a different product problem than outright rejection.

Regeneration rate and abandonment during generation are the clearest dissatisfaction signals available, and both are cheap to instrument. A rising regeneration rate after a model upgrade is a regression the aggregate numbers will not show you for weeks.

Alongside behavioural metrics we run an evaluation harness in CI: a golden set of real inputs with graded expected outputs, scored on every change to prompt, model or retrieval. This is what makes model upgrades and prompt iteration safe rather than nerve-wracking, and it is the single practice that most distinguishes teams shipping AI features weekly from teams shipping them quarterly.