What an AI app development company must get right

Seven things change when an AI feature ships inside a consumer application rather than an internal tool, and every one is a budget line. Latency stops being a metric and becomes a bounce. The network belongs to the user, and it fails mid-answer. Offline is a product state, not an error. Cost scales with engagement rather than seats. App review is a gate you do not control, and it has AI-specific rules. A wrong answer reaches someone with no training and a screenshot key. And you cannot hotfix a binary. None of that is model work. All of it decides whether the app survives its first ten thousand real users.

The category name hides the difference. A firm describing itself as an AI app development company may have built internal copilots for a bank or a consumer product with a million installs; those two disciplines share a model provider and almost nothing else. An internal tool has a captive user on a corporate network, a helpdesk, and a manager who can insist. A consumer app has a stranger on a train with one bar of signal, no patience and no obligation to come back. The engineering diverges from those two sentences, so the first question to put to any firm is which of the two they have shipped and operated.

Latency stops being a metric and becomes a bounce, and the thresholds are published rather than negotiable. Google's Core Web Vitals set them plainly: Largest Contentful Paint "should occur within 2.5 seconds of when the page first starts loading", pages "should have a INP of 200 milliseconds or less" and "should maintain a CLS of 0.1 or less", measured at "the 75th percentile of page loads, segmented across mobile and desktop devices" (Google, Web Vitals, web.dev). No model call fits inside 200 milliseconds. That is an architectural fact rather than a failure, and its consequence is absolute: a generated answer can never sit on the interaction path. The tap changes state immediately; the generation arrives into a place that already exists.

Anthropic's latency guidance names the two numbers worth instrumenting separately. Baseline latency is "the time taken by the model to process the prompt and generate the response". Time to first token "measures the time it takes for the model to generate the first token of the response, from when the prompt was sent", and is "particularly relevant when you're using streaming ... and want to provide a responsive experience to your users" (Anthropic, Reducing latency, Claude Platform documentation). The same page offers three levers and no others: choose a faster model, cut input and output tokens, and stream. A firm that has shipped consumer AI will quote a p95 time-to-first-token target before you ask for one, and will have an opinion about which requests deserve the slow model.

The network belongs to the user, and it fails mid-answer. On a corporate LAN a dropped stream is an incident; on a commuter train it is Tuesday. Anthropic documents the recovery path as a normal procedure rather than an edge case: a streaming request "interrupted because of network issues, timeouts, or other errors" can be recovered "by resuming from where the stream was interrupted" — capture the partial response, construct a continuation request, resume — with the caveat that "tool use and extended thinking blocks cannot be partially recovered" (Anthropic, Streaming messages, Claude Platform documentation). The same page notes that for requests with large token limits "the SDKs require streaming to avoid HTTP timeouts", which is the server-side version of the same problem.

The product decisions that follow are ones internal tools never have to make. What does a half-arrived answer mean — saved, discarded, or shown with an honest marker? If the user paid for that generation, in money or in a credit balance, the generate endpoint needs an idempotency key so a retry over a flaky connection cannot bill twice for one answer, and the retry has to be bounded. Ask a firm to describe the interrupted-stream path in their last app; if they have not thought about it, they built for an office.

Offline is a product state, not an error. The honest design names, for every AI feature, what the app does with no connection: serve a cached previous result, fall back to a non-AI path that is still useful, or queue the request and notify when it completes. Choosing none of the three is choosing a spinner, and a spinner is what one-star reviews are written about. The teacher training platform we built for the Government of Punjab was specified offline-first from the outset — content sync and progress tracking in a React Native app for low-end Android devices with intermittent connectivity — because retrofitting sync onto a connected app is a rewrite, not a sprint.

Cost scales with engagement rather than seats, and this is the change that most surprises a buyer coming from enterprise software. An internal tool is priced per seat and bounded by headcount and the working day. A consumer app is bounded by nothing, and the more successful it is the more it costs. The list prices are public: Anthropic publishes Claude Haiku 4.5 at $1 per million input tokens and $5 per million output tokens, Claude Sonnet 5 at $2 and $10, and Claude Opus 5 at $5 and $25 (Anthropic, Pricing, Claude Platform documentation). Those are a provider's published prices, not ours; we publish fixed deliverables and no rate card on pricing.

The same page carries a worked example that converts tokens into a unit a product manager can plan with: at an average of about 3,700 tokens per conversation, ten thousand support conversations on Claude Haiku 4.5 come to roughly $37.00. Multiply that by your own engagement assumptions before a screen is designed, because the number decides the product — free tier or not, generations per user per day, whether results are cached and reused. Two further details matter more than they look. Identical traffic on Opus 5 rather than Haiku 4.5 costs five times as much on both input and output, so the routing rule is a product decision with an invoice attached. And Claude 4.7 and later models use a newer tokenizer which "produces approximately 30% more tokens for the same text" — so an upgrade taken for quality can raise the bill on unchanged content. What it costs to run an AI agent in production works the recurring side through in full.

App review is a gate you do not control, and it has AI-specific rules. Apple treats an app whose output the user prompted as an app with user-generated content, and requires such apps to include "a method for filtering objectionable material from being posted to the app", "a mechanism to report offensive content and timely responses to concerns", "the ability to block abusive users from the service", and "published contact information so users can easily reach you" (Apple, App Review Guidelines, guideline 1.2). Three more catch AI apps specifically. Guideline 5.1.2(i): "You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so" — a model provider is a third party, so the consent flow is a build item. Guideline 1.2.1(a) requires creator apps to "use an age restriction mechanism based on verified or declared age." And guideline 2.1(a) requires a demo account or "a built-in demo mode ... with prior approval by Apple" exhibiting "your app's full features and functionality" — which is where an AI app behind a waitlist gets rejected.

Google Play adds a requirement with no ambiguity in it. Its AI-Generated Content policy states that "apps that generate content using AI must contain in-app user reporting or flagging features that allow users to report or flag offensive content to developers without needing to exit the app", and that "developers are responsible for ensuring that their generative AI apps do not generate offensive content" (Google, AI-Generated Content policy, Google Play Help). Together those rules size a workstream that rarely appears in a first proposal: a report control on every generated item, a queue behind it, a person who works it, a block list, an age gate, a consent screen, and a published contact address. In FeedDrop, a social platform where users generate video and images from prompts, the admin moderation panel to review, approve, feature and publish content was built alongside the generation engine rather than after it. Ask a firm what the moderation queue looked like on their last consumer app; one that has only built internal tools will not have had one.

A wrong answer means something different when the user is a member of the public. An employee using an internal assistant has training, context, a colleague across the desk and a manager who will hear about it. A stranger has none of that. They cannot calibrate a confident answer, they are likely to act on it, and if it is bad enough they will publish it with a screenshot. So the category of unacceptable output is wider than incorrect: it includes anything functioning as medical, legal or financial advice whether intended that way or not, a claim about a competitor, and anything simply unkind to the person who asked. The evaluation harness therefore needs a second axis an internal system can do without — not only was this correct, but was it safe to say to somebody who will believe it. The evaluation suite is that artefact in practice, and the substance behind AI evaluation and observability.

The design answer is a refusal path and an escalation path, both built rather than prompted. In a production support agent we built, escalation was triggered by confidence rather than by keywords and handed over the full conversation (AI support agent) — keyword triggers fail on exactly the cases that matter, because the user in trouble rarely uses the word you thought of.

You cannot hotfix a binary, and that single constraint should reorganise the architecture. A bad prompt shipped inside an app update stays live until a review cycle you do not control clears the fix. So everything model-dependent has to be server-controlled: the prompt, the model identifier, the token limits, the feature flag, and a kill switch that disables the feature without an app update. Ask an AI app development company where the prompt lives; if the answer is anywhere inside the shipped bundle, they have not operated one of these through a bad week. The same applies to model changes, since providers retire models on published dates and a binary has no opinion about that — model drift covers what moves underneath a running system.

Compressed into a call, it is seven questions and none is about the model. What is your p95 time to first token, and what happens on the interaction path while it runs? What does the app do when the stream breaks halfway? What does each AI feature do with no connection? What is the cost per active user per month, and which requests get the expensive model? What does the moderation queue look like, and who works it? What will the feature refuse to answer, and how does a user reach a human? And where does the prompt live?

The model is the part of this you can change your mind about later. Everything else here is structural, and cheapest to decide before the first screen is designed. Our AI development services page maps the capabilities behind each item, what AI development services actually include names the seven workstreams a scope should be written in, and what breaks when an AI-built prototype meets real users is the counterpart for a product that already exists and is about to meet the public.