Pavel Yanushka
September 20, 2026
9
min. read
and updated on:
September 22, 2026
AI app development, in the overwhelming majority of commercial projects in 2026, means building a conventional application that calls a hosted model over an API. It does not mean training models. It does not mean hiring machine learning researchers. The engineering work is ordinary software engineering plus a specific set of production concerns that ordinary software does not have.
That distinction matters commercially, because it determines who you should hire and what you should expect to pay. A team that builds solid applications and understands the operational realities of model APIs will deliver a better AI product than a research-heavy team with weak product engineering, and it will cost less.
The four patterns that cover most AI features
Nearly every AI feature shipped in a business or consumer application falls into one of four shapes. Identifying which one you need is the first useful step, because cost, complexity, and risk differ substantially across them.
Generation. The model produces text, images, code, or structured output from a prompt. Drafting, summarising, rewriting, translating, extracting fields from documents. This is the simplest pattern and the fastest to ship, often two to four weeks for a well-defined feature inside an existing application.
Retrieval-augmented generation. The model answers using your own content. Documents are chunked, embedded, stored in a vector index, retrieved by relevance at query time, and passed to the model alongside the question. This is what people mean by an AI assistant that knows our data, and it is meaningfully harder than generation because retrieval quality, not model quality, determines whether the answers are good.
Classification and extraction. The model assigns categories, extracts structured data, or routes items. Support ticket triage, document processing, content moderation, sentiment analysis. Reliable, testable, and often the highest return on investment of the four because it removes measurable manual labour.
Agentic workflows. The model plans a sequence of steps and calls tools to execute them. Powerful, considerably harder to make reliable, and the pattern where most ambitious projects overreach.
What the engineering actually consists of
The model call is one line. The work around it is the project.
- A server-side proxy. Provider calls belong on your backend, never in the mobile or web client. This keeps API keys out of shipped code, lets you change prompts without an app release, and gives you a single place to control spend and log usage. Any proposal that puts a provider key in the client should be rejected on that basis alone.
- Prompt and context management. Prompts are versioned artefacts, not strings buried in code. You will change them frequently based on observed output, and you need to know which version produced which result.
- Streaming. Users tolerate a slow response that is visibly arriving and abandon a spinner. Streaming is a client and server concern and is not optional for anything conversational.
- Cost controls. Per-user rate limits, per-request token caps, caching of repeated queries, and model tiering so that simple requests do not go to your most expensive model. This is the single most neglected area in AI feature work and the reason otherwise successful features get switched off.
- Failure behaviour. Providers have outages and latency spikes. Decide in advance what your product does when a call times out: retry, degrade to a non-AI path, queue for later, or fail visibly. Products with no defined answer fail confusingly.
- Evaluation. A test set of representative inputs with expected characteristics, run whenever prompts or models change. Without it, you are changing behaviour based on whether the last three outputs looked good.
Cost to build
| Scope | Typical build cost | Duration |
|---|---|---|
| Single generation feature in an existing app | $8,000 to $25,000 | 2 to 4 weeks |
| Classification or extraction pipeline | $15,000 to $45,000 | 3 to 6 weeks |
| Retrieval-augmented assistant over your content | $35,000 to $90,000 | 6 to 12 weeks |
| AI-centred application built from scratch | $60,000 to $180,000 | 10 to 20 weeks |
| Multi-step agentic workflow in production | $80,000 to $200,000 | 12 to 24 weeks |
Bolder Apps quotes MVP engagements at 8 to 20 weeks and prices project work fixed-scope rather than hourly, which is worth noting on AI work specifically because AI features are where scope creep is most tempting. The temptation to keep improving output quality is effectively unbounded, and a contract that makes each expansion a deliberate priced decision is a useful constraint on a category that invites indefinite iteration.
Cost to run, which is the part budgets miss
Unlike conventional software, AI features have a marginal cost per use. Token pricing means every request costs money, and a feature that becomes popular becomes expensive in direct proportion.
Model your unit economics before building. Estimate tokens per request, requests per active user per month, and cost per token at your chosen model tier, then multiply by your projected user base. Features that are delightful at 200 users and ruinous at 20,000 are common, and the arithmetic that reveals this takes an afternoon.
The levers that control it are model tiering, caching, prompt compression, capping context length, and limiting free-tier usage. All of them are easier to design in than to retrofit.
The number worth calculating first: cost per active user per month for the AI feature. If it exceeds a meaningful share of what that user pays you, the feature needs different economics, not better prompts.
How to sequence an AI roadmap rather than commissioning one
Companies that end up with useful AI features almost never build the thing they first described. They build a narrow feature, learn what users actually do with it, and expand from evidence. The sequence below reflects that.
First, one classification or extraction feature. Not the assistant. Something with a measurable accuracy target replacing manual work you can count today. It is cheap, it is testable, and it forces you to build the shared infrastructure, the server proxy, prompt versioning, cost controls, logging, that every later feature depends on.
Second, a generation feature with human approval. Drafting something users currently write from scratch, with the user editing before it is used. Adoption and edit rate together tell you whether the output is genuinely good, which is information no benchmark provides.
Third, retrieval over your own content. Now you have infrastructure and evidence, and the retrieval investment, which is the expensive part, is made against known demand.
Fourth, and only if the first three are used, agentic workflow. Multi-step action with confirmation, expanded gradually as measured accuracy justifies it.
Roughly 60 percent of the engineering in that sequence is shared infrastructure built once. This is why the first feature seems expensive relative to its size and the fourth seems cheap relative to its ambition, and why commissioning the ambitious version first inverts the economics.
Bolder Apps prices project work fixed-scope rather than hourly and sells paid discovery as a standalone engagement, and discovery is worth more on AI work than on almost any other category because the specification determines whether you are buying a feature or an open-ended research programme. Ask any partner to write down the accuracy or adoption bar that constitutes done, because AI work without that number does not finish.
Where AI features fail
Solving a problem the user did not have. AI added because it is expected rather than because it removes work produces features with low usage and permanent running cost. The strongest AI features replace a specific task someone currently performs manually and dislikes.
Poor retrieval mistaken for a weak model. When an assistant over your own documents gives bad answers, the cause is almost always retrieval, chunking strategy, embedding choice, or index quality, rather than the model. Teams that respond by upgrading models spend more and improve little.
No handling of confident errors. Models produce plausible wrong answers. In any context where a wrong answer has consequences, the interface needs to show sources, express uncertainty, or require confirmation. This is a product design obligation rather than a technical limitation.
Unbounded scope. An assistant that can do anything is difficult to build, hard to evaluate, and confusing to use. Narrow, well-defined features ship and get used.
Data, privacy, and what you must decide before building
Four decisions belong in the specification rather than in the retrospective.
- What data leaves your infrastructure, and whether your provider agreement permits it. Enterprise API tiers generally offer commitments about training use and retention, and those commitments are what your customers and your compliance team will ask about.
- Whether regulated data is involved. HIPAA and comparable regimes require specific agreements with any processor handling protected information, and using a consumer-tier API for regulated data is a compliance failure regardless of technical soundness.
- What you disclose to users about AI involvement, which is increasingly a regulatory as well as a trust question.
- Whether outputs are logged, for how long, and who can read them. Conversation logs are enormously useful for improving a feature and are also a data liability with retention obligations attached.
