AI applications
LLM-powered products, from prototype to a paying-customer app.
An AI feature is a product feature first. It needs a loading state, an error state, a way for the user to correct it, and an answer to what happens when the model is confidently wrong. I build LLM products with the same discipline as any other software — the model is one component in a system, not the whole system — which is why they survive contact with real users past the first week.
What you get
- Streaming chat or copilot UI with inline citation rendering
- Ingestion pipeline with incremental re-indexing as sources change
- Hybrid retrieval — keyword plus vector — tuned on real questions
- Permission-aware retrieval filtered by the requesting user's access
- Versioned prompt library with a graded regression suite
- Model layer behind an internal interface, so providers stay swappable
- Rate limiting, token budgets and prompt-injection defences
- Feedback capture on every response, feeding back into the eval set
Outcomes you can expect
- Every answer traceable to the source passage it came from
- Measured retrieval accuracy instead of anecdotal “it seems good”
- Sub-second time-to-first-token, so the product feels responsive
- Switching model provider is a config change and an eval run
- Spend per active user visible on a dashboard before it surprises you
- Unsupported answers suppressed rather than invented
What those actually mean
Every item above is something you can check for yourself after launch — not a promise that only becomes measurable once the invoice is paid. Here is the reasoning behind the ones that matter most.
Answers grounded in your data, with citations
Every response points at the source passage it came from, so users can verify rather than trust. Ungrounded answers are suppressed instead of invented — the system says it doesn't know.
A retrieval layer tuned against real questions
Chunking strategy, embedding model and hybrid keyword-plus-vector search tuned against actual user questions and measured on retrieval accuracy, not vibes. Most bad RAG output is a retrieval problem wearing a generation costume.
Streaming interfaces that feel instant
Token streaming, optimistic UI and skeleton states so the product feels responsive even when the model takes six seconds. Perceived latency is a design problem as much as an infrastructure one.
Provider portability designed in
The model sits behind an internal interface, so switching providers or adopting a cheaper model is a configuration change and an eval run, not a rewrite.
A regression suite for prompts
Prompts are versioned and tested like code. Every change runs against a graded set of cases, so improving one behaviour cannot silently break three others.
Cost and abuse controls from day one
Per-user rate limits, token budgets, prompt-injection defences and response caching, with a dashboard showing spend per active user rather than one alarming monthly total.
The engagement, phase by phase
This is the actual sequence, including how long each phase takes and what is expected from you at each point.
Problem shaping
3–5 daysWe define the specific job the AI feature does and, critically, what it is not allowed to attempt. Scope discipline here is the difference between a feature and a liability.
- The 20 questions users most need answered, written down
- Explicit out-of-scope list the system should refuse
- Success criteria — accuracy, latency, cost per interaction
- Review of the data available and its actual quality
Data & retrieval foundation
1–3 weeksIngestion, cleaning and chunking, then measurement. Retrieval quality is tuned before a single prompt is written, because generation cannot fix what retrieval never found.
- Ingestion pipeline with incremental re-indexing as sources change
- Chunking and embedding strategy tested across several configurations
- Hybrid search combining keyword and vector retrieval
- Retrieval accuracy measured on a labelled question set
Product build
3–6 weeksThe interface is designed as a product surface, with all the states a real user will hit — including the ones where the model fails.
- Streaming chat or copilot UI with citation rendering
- Empty, loading, partial, error and rate-limited states designed
- Feedback capture on every response, feeding the eval set
- Auth, per-user history and permission-aware retrieval
Evaluation & hardening
1–2 weeksAdversarial testing before launch, not after an incident. This includes people actively trying to break it.
- Graded eval suite run against every prompt and model change
- Prompt-injection and jailbreak testing on user-supplied content
- Load testing with realistic concurrency and streaming
- Cost projection modelled at 10x current expected usage
Launch & iteration
2 weeks +Released behind a flag to a small cohort first, with the feedback loop wired up before the audience widens.
- Feature-flagged rollout to an initial user group
- Dashboards for answer quality, deflection, latency and cost
- Weekly review of low-rated responses, folded back into evals
- Tuning retainer available for ongoing model and prompt work
Where this works — and where it doesn't
Turning down the wrong project is cheaper for both of us than discovering the mismatch in week four.
- Products that would be meaningfully better with a natural-language surface
- Companies sitting on documentation or records nobody can find anything in
- Teams with a working AI prototype that cannot survive real users
- SaaS businesses adding a copilot without rebuilding the whole product
- Adding a chatbot because competitors have one, with no defined job for it
- Use cases a good search index would solve more cheaply and reliably
- Products with no tolerance for occasional wrong answers and no review path
- Content mills producing bulk generated text at scale
What you own at the end
Everything below transfers to you on completion. There is no proprietary layer you have to keep paying me for, and no account that stays in my name.
- Application source code with the model layer cleanly abstracted
- Ingestion and indexing pipeline, documented and re-runnable
- Versioned prompt library with its evaluation results
- Monitoring dashboards for quality, latency and spend
- Cost model projected across realistic usage tiers
- Documentation covering how to add sources and update prompts
AI applications — the usual questions
The things people ask on the first call, answered before you have to.
You constrain it rather than hope. Answers are grounded in retrieved passages, responses without sufficient supporting context are suppressed, citations let users verify, and the eval suite specifically scores unsupported claims. The honest position is that you reduce and detect hallucination — you don't eliminate it — so the interface is designed to make verification easy.
Let's scope your ai applications project.
A 30-minute call, a written scope within two working days, and a price you can plan around.