An app with AI inside it, not AI looking for an app to justify itself. We start with what the product needs to do and add intelligence where it genuinely changes the outcome for the people using it.
The word gets used to cover everything from a chatbot to a self-driving car. In the apps we build, it means something specific, and understanding the shape helps you decide whether it belongs in yours.
An AI app is not an app that is entirely AI. It is a normal, well-built app that uses an AI model for one or more things it could not do with regular code. Recognising an image, generating a response, surfacing a pattern in data, sorting something that would take a human hours. The AI handles that specific part. The rest of the app, the accounts, the interface, the data, the payments, is built the same way any app is.
The model sits inside the app like an engine sits inside a car. The car still needs wheels, brakes, and a steering wheel. The engine alone is not the product. Neither is the AI.
This distinction matters because the most common mistake is starting with "we want to build an AI app" instead of "we want to build an app that solves a problem, and AI might be part of how it does it." The second version builds better products.
AI model
The part that could not be regular code
AI is one layer inside the product, not the product itself. The app around it is what makes it useful, safe, and maintainable.
These are the shapes of problem where adding a model does something regular code cannot, and the result is worth the added complexity.
Users ask questions in their own words and get useful answers from an LLM that understands the context. Customer support, internal knowledge tools, onboarding assistants.
Spotting things in data a human would miss or take too long to find. Fraud signals, demand forecasts, maintenance windows, risk scoring.
Extracting information from photos, scanned pages, or uploaded files without someone reading through them. Receipts, IDs, medical records, product photos.
An LLM that writes a first draft, a summary, a report, or a reply, inside the app, for the user to review and edit. Not a replacement for the user, a tool that removes the blank-page problem.
Connecting people, products, or content based on behaviour and fit, not just filters. Personalised feeds, job matching, product suggestions that actually help.
Replacing a step a human does repeatedly, where the decision is based on reading, classifying, or judging something. Triage, categorisation, routing, approval.
AI adds complexity, cost, and something to monitor and maintain. It should only be in the app if it genuinely changes the outcome for the person using it. If any of these apply, we will say so on the call.
If the rules are clear and fixed, a well-written function is cheaper, faster, and more reliable than a model. AI is for tasks where the rules are too complex or too variable to write down.
Adding AI because it is expected, or because a pitch deck says to, creates cost and fragility without value. The question is always what changes for the user, not whether the feature list mentions AI.
AI models can be wrong, and in places where an error causes real harm, the trade-off needs careful thought. We will be direct about where a model's confidence level is not good enough for the stakes.
Build the product first, prove people use it, then add intelligence where it makes that product better. If the idea itself is unproven, start with an MVP before layering on AI.
The honest test: would a user notice if you removed the AI part? If yes, it belongs. If the app would work the same without it, the AI is decoration, and decoration that costs money to run every month.
AI does not just cost more to build. It costs differently, because there is an ongoing running cost that a regular app does not have. Understanding this upfront is how you avoid being surprised later.
Build cost
The interface, the logic, the accounts, the data. This part is the same as any custom app. The AI layer adds work for integration, testing, and making sure the model fits the use case, but it is a defined project with a defined price.
Running cost
Every time the AI does something, there is a per-use cost. An LLM that writes a response, a vision model that reads an image, a classifier that scores a record. The more people use the feature, the higher this goes. It is not a fixed bill.
Monitoring cost
AI models drift, hallucinate, and break in ways regular code does not. Someone needs to watch the outputs, catch when quality slips, and adjust. This is ongoing work, not a set-and-forget.
Provider cost
Using an API from a major provider is the fastest route and the most common. Training or hosting your own model is more expensive to start but can be cheaper per use at scale and gives you more control. The right call depends on volume and sensitivity.
The cheapest AI app is one that uses the model only where it has to. We design to minimise unnecessary calls, cache where possible, and keep the running cost proportional to the value it creates. The goal is an AI feature that pays for itself, not one that drains the margin.
The app and the AI are built together, tested together, and monitored together. A model that works in a demo but fails on real data is not a finished product.
We understand what the app needs to do and identify which parts genuinely need AI and which do not. No model is chosen yet.
We test whether the right AI approach can do the job reliably enough, on real examples, before the app is built around it.
The full app, with the model integrated and the guardrails in place so it fails safely when it is wrong, not silently.
Checked against the messy, varied inputs people will actually give it, not the clean examples it was designed for.
Live, monitored, and handed over. AI needs ongoing attention, so we set up the monitoring and can stay on to manage it or hand that to you.
Whether the app needs AI or not, the build paths sit in the same place, same team.
Related app services
For most apps, using an existing model through an API is the right starting point. It is faster to build, cheaper to start, and the quality of available models is high enough for most real-world tasks.
Training or fine-tuning your own model becomes worthwhile when you have a large amount of domain-specific data and the off-the-shelf option is not accurate enough, or when data privacy requirements mean the information cannot leave your environment. We will recommend the route that fits your case.
It depends on how often the AI feature is used and which model powers it. A lightweight classifier on a few hundred requests a day might cost very little. A large language model handling thousands of long conversations will cost more. The cost scales with usage, not with a flat monthly fee.
We design to minimise unnecessary calls and choose the smallest model that does the job well, because a cheaper-to-run model is a better business decision than an impressive one that eats the margin.
It will, sometimes. AI models are probabilistic, not perfect, and pretending otherwise would be dishonest. What matters is how the app handles that. We build guardrails: confidence thresholds, human review for high-stakes outputs, fallback behaviour when the model is not sure, and clear signals to the user when a result is AI-generated.
The goal is for the model to be useful enough to save real time, and honest enough that when it is wrong, the user notices and catches it rather than trusting it blindly.
Data handling depends on the approach. When using an API from a provider, you need to be comfortable with the data reaching that provider's servers, and most major providers offer agreements that prohibit using your data for training. When privacy is critical, the model can run in your own environment so nothing leaves it.
We will be clear about where the data goes, who can see it, and what the trade-offs are for each option, so the decision is yours and it is informed.
Yes, in most cases. Adding an AI feature to an existing app is often simpler than building one from scratch, because the product already exists and we can see exactly where the model helps. We review the current app, identify the integration point, and build the AI layer into it.
If the existing codebase makes integration difficult, we will be upfront about that and propose the cleanest path, which might include refactoring the relevant part before adding the feature.
You own the app code and everything we build, fully. If we fine-tune a model on your data, you own that fine-tuned version too. If the app uses an existing model through an API, the model itself belongs to its provider and you pay for access like any other service.
We make this clear at the start so there is no ambiguity about what is yours, what is rented, and what the ongoing costs look like. The code is always yours. The model ownership depends on the route we take together.
Thirty minutes on what you want the app to do, whether AI belongs in it, and what a first version would look like. If the answer is regular code, we will say so.
Or email hello@culmen.digital