What a custom AI app for a brand really costs
Why the same brief gets quoted at five thousand and at five hundred thousand, what actually moves the number, and the running costs nobody puts in the proposal.
Ask four studios to build the same artificial intelligence tool and the quotes will not be within an order of magnitude of each other. That is not four different prices for one thing. It is four different things, and the brief was vague enough to permit all of them.
For scale, GoodFirms’ custom software development cost survey puts most small and medium custom software projects between $30,000 and $100,000 — and adding a model to a product does not so much add a line to that budget as change which parts of it are hard.
Why do quotes vary by ten times?
Because “an artificial intelligence app” describes at least three unrelated products, and a brief that does not distinguish them gets priced by whichever one the studio assumed.
The first is a wrapper: a form, a well-designed prompt, an output. Real value, genuinely quick, and completely dependent on the model behind it. The second is a tool with judgement — it knows your specific business, refers to your own data, and has to be right often enough to be trusted unattended. The third is a product with users: accounts, permissions, payments, other people’s data, and a duty of care that arrives the moment a stranger logs in.
| Shape | What it is | What drives its cost |
|---|---|---|
| Wrapper | One input, one output, no memory | Almost nothing. Design and copy dominate |
| Internal tool | Does a real job for one team, on your data | Getting the data in, and the review step for when it is wrong |
| Product with users | Strangers sign in and trust it with something | Accounts, permissions, payments, support, and every rule that applies to holding data |
A studio quoting the first shape and a studio quoting the third are both being honest. Deciding which one you are buying is the single highest-value hour you will spend on the project, and it happens before anyone writes code.
What actually drives the cost?
Four things, in roughly this order of impact. None of them is the model, which is the part everyone asks about.
First, how expensive a mistake is. A tool that drafts social captions can be wrong all day; a person reads it before anything ships. A tool that sets a price, or writes something a customer pays against, needs a review step, a confidence score, and a way for a human to intervene. That review layer is often more work than the part that produces the answer.
Our own auction work is the clearest example we have. The reference corpus behind it is 32,000 past items, and the reason it can replace typing roughly 1,250 lots by hand for each auction is not the description-writing — it is that the output is confidence-scored, so only uncertain items are flagged for a person and everything else passes straight through. That triage is what turned it into 400+ hours saved rather than a demo.
Second, where your data lives. If it is in one clean export, you are days from a working prototype. If it is spread across a supplier portal, an inbox and somebody’s spreadsheet, the integration is the project and the model is a small part at the end. This is where most budgets actually go, and almost no proposal says so plainly.
Third, whether other people log in. The moment a stranger has an account, you have acquired password resets, permissions, abuse handling, support and obligations about their data. It is a real threshold, not a feature. Ehsaan, the person-to-person marketplace we build for Suleman Farooqui, sits on the far side of it — a whole product on React, Vite, TypeScript and Supabase, where trust between two strangers is the actual thing being designed.
Fourth, who owns it in six months. A build handed over with no documentation is cheaper on the invoice and considerably more expensive the first time it breaks. On Ehsaan the first build took 23 prompts, and then the work moved to a 19-section knowledge base so the product keeps its own rules as it grows. That knowledge base is a cost item that looks optional and is not.
What scope fits a small budget?
If the budget is genuinely small, the right answer is not a smaller version of the big product. It is one job, for one team, with no accounts.
- Pick the task somebody currently does by hand, every week, that they hate. Not the most valuable one — the most repetitive one.
- Give it one input and one output. No dashboard, no settings, no user management.
- Let it run somewhere internal, where being wrong is embarrassing rather than expensive.
- Measure the hours it removes for a month before adding a single feature.
- If it does not remove hours, stop. You have learned something cheaply, which was the point.
The reason to be this strict is that most of the value in these tools is concentrated in one narrow task, and most of the cost is in everything built around that task to make it feel like a product. Our own Inventory Watch build for the same auction client is deliberately narrow in exactly this way: it monitors 21 dealer sites for new listings, in 16 Python modules, and does nothing else at all.
What does it cost to run, every month?
This is where budgets are quietly broken, because the proposal covers the build and the running costs arrive afterwards.
| Recurring cost | Why people forget it | How to size it early |
|---|---|---|
| Model usage | The demo cost pennies at ten uses a day | Estimate real daily volume, then multiply by three for retries and mistakes |
| Hosting and storage | It is small until the data set is not | Ask what happens at ten times today’s volume |
| Model changes underneath you | Providers deprecate and reprice on their own schedule | Budget a maintenance day per quarter, permanently |
| The human in the loop | Review time is real work and rarely counted | Count it as a salaried cost from day one |
| Fixes and small changes | Everyone assumes the build is finished | Agree a monthly amount, or agree there is none and mean it |
The one people underestimate most is the third. The model you build on this quarter will change, and something that worked will quietly stop working in a way no error message reports. A tool with nobody responsible for it degrades silently, which is worse than breaking.
When does off-the-shelf software win?
Most of the time, and we would rather say that than sell you a build you will regret. If software already exists that does eighty per cent of the job, buying it is almost always correct, and the twenty per cent you compromise on is cheaper than the maintenance you avoid.
Build when the process is genuinely yours — when the reason it works is knowledge nobody else has, or when the existing product forces you to change how you operate in a way that costs more than the licence saves. The auction build cleared that bar because the reference set was the client’s own history, and no product on the market has that history.
It is worth knowing how often this goes wrong at much larger companies. MIT’s Project NANDA reported in its 2025 “GenAI Divide” study that around 95% of enterprise generative artificial intelligence pilots produced no measurable return, with the failures attributed to workflow integration and undefined outcomes rather than to the models themselves. Those organisations were not short of budget. They were short of a decision about what the thing was for.
So the question to answer before asking anyone for a price is not what it costs. It is what it replaces, measured in hours or in money, and who will still be responsible for it a year from now. Bring those two answers and the quotes stop varying by ten times, because everyone is finally pricing the same thing.
Software without a price is a hobby with a repo. Decide how it pays before deciding what it costs.