Practical notes from the engineers who build agents, copilots and AI products.
Expect access setup, data sampling, a scope lock, weekly demos and an evaluation baseline within the first month. If any of those five has not happened by day 30, something is wrong with the engagement, and the earlier you name it the cheaper it is to fix.
Production LLM apps have versioned prompts, evals, multi-model routing, structured outputs, observability and cost control from the first commit. A demo has none of these and still looks the same on screen, which is why so many pilots stall. Here is what each requirement means, how it is built and what it costs.
RAG grounds an AI's answers in your documents by retrieving relevant passages first, so responses are specific, current and citeable. It is the standard way to make a language model answer from your policies, contracts and tickets rather than from its training data, and most enterprise AI assistants are built on it.
A super app bundles many services behind one login and wallet; build one only if you have several services and one customer base. The test is whether the same customer already uses two or more of your services and would use them more if they shared identity, payment and history. If not, build one excellent app instead.
RAG builds typically run $14,000–50,000 depending on document types, permissions and refresh needs, plus modest running cost. The price is driven by how messy the sources are, whether access control must be enforced per user, and how often the index must refresh, far more than by the model or the vector database.
Maintenance runs 15–25% of build cost per year or a monthly tier; AI systems need an add-on for evals, prompts and cost tuning. A good plan names a response time, an hour allowance and what it covers: patches, updates, monitoring, and for AI, the eval re-runs that catch a model change first.
Ask which decision changes, what the data readiness is, what it costs monthly, who owns it and how success will be measured. Five questions, answered in writing before approval, separate an AI investment from an AI experiment, and a good vendor will already have asked the team proposing the spend the same questions.
Payments need a wallet ledger, UPI and card rails, reconciliation and refunds designed as a subsystem, not an afterthought. In a super app the payment layer serves every module, so build it once as a shared service: a double-entry ledger, a gateway abstraction, webhook handling and daily reconciliation.
Meter events per tenant, aggregate to billing periods and expose usage in the admin so AI and API features can be priced. The pipeline is small and boring: an immutable event log, idempotent ingestion, periodic aggregation and a reconciliation job that proves the invoice matches the events before it goes out.