The gap between an AI demo and an AI product
Teams usually come to us after one of three experiences. They built a prototype that worked on ten examples and failed on the eleventh. They bought an AI tool that does not connect to their data. Or they have been told that “AI will transform the business” and have no clear place to start.
All three have the same cure: pick a specific job, define what good looks like, measure it, then build. A support assistant is judged by the share of questions it answers correctly and the share it hands to a person at the right moment. A document-processing agent is judged by extraction accuracy and the time saved per document. A recommendation feature is judged by whether people use the recommendations. Without a measure, AI projects drift.
We start every engagement by writing that measure down.
What we build
AI assistants and chatbots
Customer-facing and internal assistants that answer from your knowledge base, policies, product data or past tickets, with citations so people can check the source. They hand off to a human when confidence is low.
Retrieval-augmented generation (RAG) systems
Search-and-answer systems that connect a language model to your documents, databases and files. Most “chat with your data” projects are really retrieval projects, and retrieval quality decides whether the answers are any good.
AI agents
Software that plans a sequence of steps and uses tools to complete them: look up a customer, check inventory, draft a reply, create a ticket, update the CRM. We design agents with clear permissions, approval steps for risky actions and complete logs.
Workflow and document automation
Extraction from invoices, contracts, forms and emails; classification and routing; summarisation of calls and meetings; report drafting.
Recommendation and personalisation
Features that suggest products, content, routes, meals or plans based on behaviour and preferences. We build these into mobile apps and web platforms.
Predictive models
Forecasting, scoring and anomaly detection using your historical data: demand, churn, lead quality, equipment failure.
Computer vision and speech
Image recognition, document scanning, transcription and voice interfaces.
Generative AI services in more detail
If you are researching generative AI development, you are probably asking four questions: which model, how to give it your knowledge, how to keep it from making things up and how to keep costs under control.
Choosing the model
We work with leading hosted models from OpenAI, Anthropic and Google, and with open models that can run in your own environment. Hosted models are faster to start and generally stronger on hard reasoning. Self-hosted models give you tighter control of data and predictable cost at high volumes. We run your real examples through two or three candidates and let the results decide.
Giving it your knowledge
For most business use cases, retrieval beats fine-tuning. We chunk, index and search your content, pass the relevant passages to the model and require it to answer from them. Fine-tuning is reserved for cases where you need a consistent style or format, or a narrow task at very high volume.
Reducing wrong answers
We cannot promise that a language model will never be wrong, and anyone who does is selling something. What we can do is ground answers in your sources, ask the model to cite them, test against a set of known questions, add guardrails for topics it should not touch and route uncertain cases to a person. We re-run those tests whenever the model, the prompt or the data changes.
Controlling cost
Usage-based pricing means a popular feature can become expensive quickly. We size the model to the task, use smaller and cheaper models for simple steps, cache repeated work, limit context length and monitor spend per feature from the first week.
How we run an AI project
- 01
1. Use-case discovery
A workshop to list candidate use cases, then rank them by value, feasibility and risk. Many clients leave with a short list of two or three, and a clear reason for the ones we parked.
- 02
2. Data and feasibility check
We look at the data the system will rely on: where it lives, how clean it is, who can access it and what privacy rules apply. Data readiness is where most projects succeed or fail. Industry guides commonly attribute 15 to 35 percent of total AI project cost to data preparation.
- 03
3. Prototype with an evaluation set
In a few weeks we build a working prototype and a set of test questions or cases with expected answers. This gives you evidence, not opinions, about whether the approach works.
- 04
4. Production build
Integration with your systems, authentication and permissions, logging, error handling, a proper interface and the infrastructure to run it.
- 05
5. Evaluation and safety
Automated tests on quality, safety and cost. Red-team style testing for prompt injection, data leakage and misuse. Human review of a sample of outputs.
- 06
6. Launch
Staged rollout, starting with a small group, with feedback tools built in.
- 07
7. Monitoring and improvement
Dashboards for quality, latency, cost and user feedback. Models change and data drifts, so we treat an AI system as something you operate, not something you ship once.
Where AI is worth the money
Not every problem needs AI. Our rule of thumb: AI is a good fit when the work involves language, documents, images or patterns that rules cannot easily capture, when volume is high enough to justify the build, and when a wrong answer is recoverable. It is a poor fit when you need exact, auditable calculations, when a simple rule would do or when mistakes have severe consequences and no human reviews the output.
Common wins include:
- Customer support deflection and agent assistance
- Sales and CRM assistants that summarise accounts and draft follow-ups
- Document and invoice processing
- Internal knowledge search for policies, contracts and product information
- Product recommendations and search relevance in commerce
- Personalised plans and itineraries in consumer apps, such as AI trip planners and AI meal planning apps
- Forecasting for inventory, demand and staffing
- Content operations: product descriptions, translations, metadata and summaries
How we build: architecture and engineering practices
Production AI is mostly ordinary engineering with a few specialised parts.
Retrieval layer
Document ingestion, chunking, embeddings and a vector or hybrid search index. We use managed vector services or PostgreSQL with pgvector depending on scale and your hosting preferences.
Orchestration
Application code, and where useful frameworks such as LangChain or LlamaIndex, to coordinate prompts, tools and memory. We avoid heavy frameworks when a small amount of plain code is easier to maintain.
Tool and system integration
Agents act through well-defined tools with scoped permissions. Where it helps, we use open protocols such as the Model Context Protocol to expose tools cleanly.
Evaluation harness
A versioned test set, automated scoring and regression checks that run before each release.
Guardrails
Input and output filters, topic restrictions, personal-data redaction and rate limits.
Observability
Tracing of every request: prompt, retrieved context, model response, latency, tokens and cost. Without this, you cannot debug an AI system.
Security and privacy
Role-based access to data, so the assistant never retrieves what the user is not allowed to see. Encryption in transit and at rest, private networking where needed and clear contractual terms about data usage with model providers. For sensitive data, we can use deployments where inputs are not retained or used for training, or models that run inside your own cloud account.
Application layer
The interface your users touch: a web app built in Next.js or React, a mobile app, a Slack or Teams integration, or an API behind your existing product.
Data readiness: the part nobody wants to talk about
Most AI delays trace back to data, not models. Before we promise a timeline, we look at five things.
Where the knowledge lives
Policies in PDFs, answers in old tickets, product data in a spreadsheet, tribal knowledge in people’s heads. Each source needs a different ingestion approach.
How current it is
An assistant that quotes last year’s pricing is worse than no assistant. We design refresh schedules and, where it matters, show the “last updated” date beside answers.
Who may see what
If a sales rep cannot open a document today, the assistant must not reveal it to them tomorrow. We carry your existing permissions into the retrieval layer.
How messy it is
Scanned pages, duplicate files, conflicting versions and inconsistent naming all degrade answers. Some cleanup is usually worth doing first, and we will tell you which.
Whether there is enough of it
For predictive models, you need enough history with reliable labels. If you do not have it, we say so and suggest how to start collecting it.
How we measure whether it works
“It seems good” is not a measure. For each project we agree a small set of numbers before building.
Answer quality
the share of test questions answered correctly and fully, judged against reference answers and reviewed by someone who knows the subject.
Groundedness
the share of answers that are supported by the cited sources.
Handoff accuracy
how often the system escalates when it should, and how often it escalates when it did not need to.
Latency
time to first word and time to complete answer.
Cost per task
model and infrastructure spend per conversation or document.
Business outcome
tickets deflected, minutes saved, conversion lift, whichever matches the original goal.
We keep these numbers on a dashboard, so you can see quality and cost move as the system changes.
When AI is not the answer
We would rather tell you early. If a database query, a rules engine or a better form would solve the problem, that is usually cheaper, faster and easier to maintain. If your data is too thin or too scattered, a data project should come before an AI project. And if an error would be costly and no person will review the output, we will recommend a design that keeps a person in the loop. A smaller, well-scoped project that works beats an ambitious one that is quietly switched off after six months.
Technology stack
| Layer | What we typically use |
|---|---|
| Models | OpenAI, Anthropic Claude, Google Gemini, open models such as Llama and Mistral |
| Retrieval and data | PostgreSQL with pgvector, Pinecone, Qdrant, Elasticsearch, S3 and cloud storage |
| Orchestration | Python, TypeScript, LangChain, LlamaIndex, custom workflow code |
| Classical ML and vision | scikit-learn, PyTorch, TensorFlow, OpenCV, speech-to-text services |
| Backend | Python (FastAPI), Laravel, Node.js |
| Front ends | Next.js, React, Flutter |
| Evaluation and monitoring | Custom evaluation suites, tracing tools, cloud monitoring |
| Cloud | AWS, Google Cloud, Azure |
Industries we serve
We build AI features for travel, food and nutrition, healthcare and wellness, e-commerce and retail, education, real estate, logistics, finance and SaaS. In regulated areas we design around the rules that apply to your data from the start, for example by limiting what personal information reaches a third-party model, and we recommend legal review where the stakes call for it.
Pricing and timelines
AI work spans a very wide price range, because “AI” describes everything from a weekend chatbot to a multi-year platform. Published industry guides show these broad bands. Treat them as context rather than a quote.
| Type of project | Published market range (USD) | Typical running cost |
|---|---|---|
| Simple AI agent | about $15,000 to $40,000 | $500 to $3,000 a month |
| Rule-based chatbot | about $3,000 to $15,000 | $200 to $1,000 a month |
| LLM-powered chatbot | about $50,000 to $150,000 | $1,000 to $10,000 a month |
| Generative AI application | about $75,000 to $300,000 | $3,000 to $50,000 a month |
| Machine learning model (prediction or classification) | about $30,000 to $150,000 | $500 to $5,000 a month |
| Enterprise multi-agent or platform work | $100,000 to several hundred thousand | $5,000 or more a month |
Costs move with the complexity of the task, the quality and accessibility of your data, how deeply the system integrates with your software, the level of security and compliance required and the volume of usage. Ongoing costs matter as much as build cost: model usage, hosting, monitoring and the time to keep quality high.
We recommend starting with a fixed-scope discovery and prototype phase. It limits your risk, produces a working demonstration and gives you a firmer number for the full build.
Frequently asked questions
How much does AI development cost?
It ranges from a few thousand dollars for a simple rule-based chatbot to several hundred thousand for an enterprise platform. A typical LLM-powered assistant or agent for a business falls somewhere between the low tens of thousands and the low hundreds of thousands, with monthly running costs on top. The biggest drivers are data readiness, integration depth, security needs and usage volume. A short discovery and prototype phase gives you a realistic number.
How long does it take to build an AI solution?
A working prototype usually takes a few weeks. A production system with integrations, evaluation and security typically takes three to six months, depending on scope. Projects with messy data or many integrations take longer.
Will an AI system give wrong answers?
Any language-model system can sometimes be wrong. We reduce the risk by grounding answers in your own documents, requiring citations, testing against known cases, adding guardrails and routing uncertain cases to people. We also measure accuracy before launch and monitor it afterwards, so you know how it performs.
Is my data safe?
We design for privacy first. That includes role-based access, encryption, redaction of personal data where appropriate, and provider agreements or self-hosted options so that your data is not used to train public models. We will tell you where your data goes at every step.
Which model do you use: OpenAI, Claude, Gemini or open source?
We choose per project. We test candidate models on your real examples and compare accuracy, speed, cost and data-handling terms. Many solutions use more than one model, sending simple tasks to cheaper models.
Do we need to fine-tune a model?
Usually not. For most business cases, retrieval from your own documents and good prompt and workflow design perform well at lower cost and with easier updates. We recommend fine-tuning only when there is a clear case for it.
Can you integrate AI into our existing software?
Yes. We add AI features to existing web applications, CRMs, ERPs, mobile apps and e-commerce stores through APIs and plug-in points, without rebuilding what already works.
Can you build AI features into a mobile app?
What do you need from us to get started?
A clear description of the problem, examples of the inputs and ideal outputs, access to sample data and someone on your side who understands how the work is done today. If you are not yet sure where to start, we can run a discovery workshop to find out.