“With AI, I can finally afford my dream project”: what really changed about the price of an app
A quote that killed a project five years ago no longer describes what building costs. What AI actually made cheaper, what it did not, and the real 2026 budget.

The 100,000 euro quote that buried the project
A few years ago, a former tour operator walked into an agency with a simple idea: a travel app that would replace generic guidebooks with genuinely personalised recommendations, for an island he knew inside out after working there for years. He had the content, the field knowledge, the contacts and eleven pages of functional spec. He walked out with a quote for 100,000 euros. The project died that day, filed away in the drawer of ideas that cost too much.
That quote was not dishonest. At the time it was roughly fair: a native mobile app, a back office, a recommendation engine and multilingual content added up to hundreds of person-days. The problem was not the price itself, it was the ratio between that price and an idea nobody had validated yet. Nobody bets 100,000 euros on a hypothesis.
This summer, the same person called us back with the same project. In the meantime something changed, and it was not his budget: it was the cost of building. This article spells out exactly what AI made cheaper, what it left untouched, and what a realistic budget looks like in 2026 when you finally want to take a project out of the drawer.
“The project was not too expensive. It was too big for what we still knew about it.”
What AI actually changed on the invoice
Let's be precise, because the general conversation is not. No, AI did not divide the price of software by ten. It divided the cost of one clearly identified line item: code production. Writing a screen, wiring an API, generating tests, translating an interface into three languages, producing the tenth variation of a form. All of that used to be billed by the day and measured in weeks. It is now measured in hours, with a senior developer steering, reviewing and correcting.
The rest of the invoice has not moved. Understanding your business, deciding what not to build, designing a journey where users do not get lost, checking that the data is accurate, keeping the product healthy once it runs in production: those are human hours, and they cost what they always did. That is why some projects saw their budget collapse and others barely moved. It all depends on how much pure code there was in the total.
| Cost line | Before AI | Today |
|---|---|---|
| Code production | The bulk of the invoice | Divided by 3 to 5 |
| Integrations and technical plumbing | Weeks | Days |
| Translations, content, variants | A separate quote line | Nearly marginal |
| Scoping and product decisions | A few days | Unchanged, and more decisive |
| Design and user journey | Billed by the day | Unchanged |
| Data quality and field verification | On you | Still on you |
That is the genuinely good news. The budget does not disappear, it moves. Where most of the invoice used to go into manufacturing, a large share can now go into what actually decides success: scoping, user experience, and shipping earlier to learn from the market instead of guessing.
We see the same shift inside companies on automation projects, and we covered it in our guide on how to bring AI into an SME.
What your project actually costs in 2026
Let's get to the numbers, since they are the only thing that decides whether the project leaves the drawer. At Figue we take on a project from around 15,000 euros, and the top end of an ambitious platform sits near 100,000 euros, exactly the figure that killed our visitor's project. The difference is that 100,000 euros today no longer buys you a first version: it buys a complete product, in production, with users on it.
the threshold we start a project at today. The same initial scope routinely came in at six figures five years ago.
Figue pricing, 2026
Between those two figures, everything is a matter of scope. The question is never 'how much does an app cost' but 'what is the smallest version that proves someone wants it'. That is exactly the debate between an MVP and a V1, better settled before you ask for a quote than after you receive one.
Add the cost that comes after, the one people systematically leave out: a living product needs maintaining, fixing and evolving. Budget from 1,750 euros a month to keep a hand on a product in production, with no lock-in. This is not an optional line: software nobody runs degrades within months, and picking it back up costs more than maintaining it would have.
The opposite trap: believing it costs nothing now
For the past two years a new mistake has replaced the old one. After believing everything was too expensive, many now believe everything became free. Founders show up with a prototype assembled over a weekend out of prompts, convinced they have 80 percent of the product. They have roughly 20 percent, and rarely the right 20 percent.
A generated prototype proves an idea can look like something, and that is already valuable. It says nothing about what comes next: how it holds up with a hundred concurrent users, what happens when a payment fails, where your European customers' personal data is stored, who picks up the code when it needs to evolve eight months from now. Those questions have no shortcut, and that is precisely where a real product's budget goes.
Knowing when to stay on a quick assembly and when to move to custom development is a decision to make deliberately rather than to suffer: we broke it down in our comparison of no-code versus custom development.
“AI made the first version ten times cheaper. It changed nothing about the price of the second one, when the first was badly built.”
Carving up your dream so it fits a budget
Here is the skill AI did not change, and the one that decides everything: knowing what to remove. Our visitor's project, in its dream version, meant a native app, fifty venues verified on the ground, three languages, a recommendation engine, a freemium model and a booking system. Four decisions bring it inside the budget of a first version.
One user, one moment
Do not build for everyone. Pick the precise user and the precise moment where your product changes something. In his case: the traveller planning a trip three months ahead, at home, on a large screen. Anything serving another profile or another moment waits for the next version, no exceptions.
Responsive web before a native app
This is the advice that saves the most money, and almost nobody offers it spontaneously. A well-designed web interface adapts to every screen, opens from a plain link, requires no download and depends on no app store. A native app, with its developer accounts, review queues and separate build, earns its place once you have users who come back, not to convince them to exist.
Postpone monetisation, do not postpone testing it
Decide the model (free, premium, affiliate) but do not build the machinery until someone has paid. A button leading to a form is enough to measure intent. Full checkout, subscriptions, refunds and invoicing represent several thousand euros you will spend far more comfortably once demand is proven.
Get it designed before you get it coded
An interactive mockup costs a fraction of development and answers the only question that matters at the start: does anyone understand the product within ten seconds? At Figue that step is part of the quote, before any commitment, because a disagreement discovered on a mockup costs one meeting, while the same disagreement discovered in the code costs two weeks.
A good partner does this sorting with you and offers to remove things rather than add them. It is the most reliable signal when choosing who will build your software.
Frequently asked
What people ask us most about project costs in the age of AI.
Now is the right moment, and that is not a sales line
If you have a project sitting in a drawer because a quote put it out of reach three, five or ten years ago, that quote has expired. The number that stopped you no longer describes what building actually costs today. That does not mean your idea is good; it means it finally deserves to be tested for an amount you can afford.
The approach has three steps: get the project re-quoted as it stands today, cut it down to the smallest version that proves something, then add only what users actually ask for. The dream does not disappear in that carving; it becomes reachable piece by piece, and the first piece is finally within budget.
“AI is not what makes your project possible. It is what makes the first attempt cheap enough that you can finally afford it.”
Read next: MVP or V1, what to ship first and getting your business software built.
Related articles

Vendor or partner: how to choose who builds your software
Every vendor says the same thing. What separates a partner from a mere executor is the incentive. Seven questions and a few signals to tell them apart.

Having your first business software built when you are not technical
You know your trade, not software. Here are the reference points a non-technical owner lacks: your real edge, the three traps, and how to de-risk before coding.

Your spec describes a V1, not an MVP: how to scope it right
Most specs describe a V1, not an MVP. Here is a method to reread your own document and separate what produces proof from what only produces comfort.

What is a product studio? Definition, model and pricing
Product studio: the word is everywhere, the definition nowhere. Here is what the model really covers, how it works, what it costs and who it fits.

Publishing your app to the App Store and Play Store
Your developer accounts exist and your build runs: here is how to submit your app to the App Store and Play Store, step by step, without getting rejected.

How to integrate AI into your business: a practical, honest guide
Everyone tells you to do AI, without saying where or for what gain. Here is where AI truly creates value in a small business, concrete use cases, custom vs no-code, costs, ROI and the mistakes to avoid.

Fractional CTO: what it is, when to bring one in, and how to choose
A product taking off, a small team, and no one to arbitrate the technical choices that will shape the next five years. A fractional CTO fills that gap without the cost of a full-time hire. When to bring one in, what they really do, how much it costs.

SaaS go-to-market plan: the first 8 weeks to win your first customers
A clean product that will not sell is almost always a go-to-market problem, not a tech one. Here is a concrete 8 week plan: positioning, channels, pricing, growth loop. Founder to founder.

No-code or custom: how to choose when launching your first product
No-code to move fast, or custom to do it right? The real question is not the camp, it is the moment. Here is the grid to decide when you already have an audience or traction.

Tech as a Service: senior engineering reinforcement to ship 3x faster
You have a technical team but a velocity bottleneck? Plug-and-play senior reinforcement lets you hit deadlines without hiring. Here is how, and when to use it.

ReactIn: from side project to full LinkedIn outreach tool
How an internal LinkedIn prospecting tool became a $6K MRR bootstrapped SaaS, with zero paid advertising or fundraising.

We tripled our prices: the real pivot behind our design offer
How we went from a $2K/month design subscription to a $6K+ premium product studio. Fewer clients, 3x revenue per client, better quality.

Our best SaaS tools (and how we actually use them)
The complete stack of a product studio building SaaS products: dev, design, growth and ops. Real tools, real costs, real lessons after 3 years.

Bootstrap vs fundraising, freelance vs agency, solo vs co-founders: our founder choices
3 dilemmas that define your startup trajectory. A look back at our choices at Figue, with real numbers and hard-won lessons.

Product studio vs traditional agency: why it changes everything
Agencies optimise for volume. Product studios optimise for outcomes. Here's why that makes all the difference for your project.