What an AI MVP costs in 2026, and where the money goes
People write to us with a deck and ask what it will cost. The answer in 2026 is six to twelve weeks and tens of thousands of dollars for a first version real customers can pay for. The spread inside that range comes from four things that have little to do with the AI. This is where the money goes, based on building bilz.ai and iproxy.online and on the products we have scoped for other people.
Why the range is wide
A web app with accounts, billing, one AI feature and an admin screen is the low end. Add a native mobile app and you are in the middle. Add a connection to a system with a bad API, or data nobody has cleaned, or an AI feature whose correctness you have to prove rather than demonstrate, and you reach the top.
The model API bill is not on that list. For an MVP it is usually a rounding error next to engineering time. Founders worry about per-token cost and underestimate per-integration cost almost every time.
Where the money goes
Integrations are the first line item. bilz.ai pulls sales from Toast, Square, Clover, Lightspeed and Syrve. Each one has its own authentication, its own idea of what a sale is, its own rate limits and its own way of failing at two in the morning. The first integration is a week. Each one after is less, but never zero, and the one that looks easiest in the docs is rarely the easiest in practice.
Data is the second. An AI feature that reads documents or answers questions over your records needs those documents and records in a form the model can use. If they live in email attachments, scanned PDFs and a spreadsheet three people edit, a large share of the budget goes to getting them into one place with one schema. That work is invisible in the demo and decisive in the product.
Evaluation is the third, and the one most quotes leave out. A feature that is “AI-powered” is a feature whose correctness varies by input. You need a set of real cases with known answers, a harness that runs the feature against them, and a number you track. Building that is a few days for a simple feature and a couple of weeks when the cases are messy. Skipping it means you learn the accuracy from customers.
Mobile is the fourth. iproxy.online is an Android app at its core, because the product is the phone. A native app adds store review, device testing, background execution rules, push notifications and a release process on top of everything the web app already needed. If the product is not the phone, we push hard to leave mobile for version two.
The AI itself, the prompts and model calls, is usually the smallest line. It is also the one that sounds most expensive in a sales conversation, which is useful to remember when you compare quotes.
What to cut
Cut the second user type. If the product serves restaurants and their suppliers, launch for restaurants. The second side can arrive when the first is paying.
Cut the dashboard. Founders want charts on day one; customers want the thing that does the job. bilz.ai’s first value was reading an invoice without typing. The profit report came later, and it was better for being built on real data.
Cut the fine-tuning. In 2026 a well-chosen hosted model with good retrieval and a tight prompt beats a fine-tuned model for almost every MVP, and it leaves you free to swap models when a better one ships next quarter.
Cut the custom design system. Use a sober default and spend the design hours on the three screens where the customer decides to pay.
Cut the self-serve onboarding, at least at first. Onboard the first twenty customers by hand. You will learn more from those calls than from any analytics tool, and the onboarding you automate afterwards will be the right one.
What not to cut
Do not cut the evaluation set. It is the only way to know whether a change made the product better or merely different, and it is the thing a buyer or an investor asks about once they have been burned by a demo.
Do not cut billing. A product people cannot pay for is a prototype. Payments, invoices and the cancel button take a few days with a modern provider, and they turn a conversation about interest into a conversation about money.
Do not cut the admin tools. The first month after launch is spent fixing individual accounts, refunding, re-running a failed import. If the only way to do that is a database console, every support request costs an engineer.
Do not cut monitoring and the model fallback. Hosted models have bad days. The product needs to know when a call is slow or has failed, retry sensibly, and show the user something other than a spinner.
Do not cut the handover. Code in your repository, the prompts and eval sets next to it, a runbook for deploys and incidents. If nobody but the builder can deploy it, you do not own it yet.
How to read a quote
Ask what share of the estimate is integrations, data and evaluation. If the answer is most of it, the vendor has built this before. If the answer is mostly the AI, they are pricing the demo.
Ask what is explicitly out of scope. A quote with no exclusions has not been thought through.
Ask whether the price is fixed after discovery. Ours is. One week of discovery, then a scope, a price and a date. The discovery week is where we say no to the parts that will not survive launch, and where you find out whether we are worth working with.
If you have a product in mind, the custom AI apps page describes how we build one, and this form is the way to start.