What a mobile app really costs in 2026: from free prototype to running meter

Written on 20/07/2026
Jérôme Granados

Entry prices have never been lower. But the price left the sticker: it's on the meter. Three meters: build, infrastructure, usage.

“An app is free now, AI generates it.” It’s the line of the year. I’ve been in this business since 2011, at GoodBarber, a Mobile App Builder, and I understand why the line took hold: a prototype is born in minutes, and entry prices fit in one or two digits, zero, nineteen, twenty-five dollars a month. Next to a custom-development quote, it feels like the cost of an app simply evaporated.

It didn’t evaporate. It changed shape.

The sticker price isn’t a lie. It’s incomplete. Inference, cloud, and integrations have a real cost, and somebody pays it. The trouble starts when you compare subscriptions without knowing what each one measures, what it cuts off at the limit, and which lines will get added along the way.

The quota caps your spending, not your outcome

Open any generator’s pricing page and one notion is unavoidable: the credit. Behind the credit there are tokens, which is to say inference costs. And a per-token cost is close to unreadable for a human: it depends on the length of the conversation, the size of the project the tool re-reads with every message, the complexity of the request, the model being called, and the number of round trips the agent makes under the hood to plan, execute, check, and fix. Nobody can project a budget onto that.

So everyone translated the token into their own language. As of July 20, 2026: Lovable sells credits, consumed in fractions by effort, roughly 0.5 to gray out a button, 1.2 to add authentication, 2 to build a landing page, per its own documentation. Bolt owns the raw token: 300,000 a day on the free tier. Base44 counts message credits, whose consumption varies by action and model. Replit bills the effort actually spent: a small fix costs less than a complex feature, and the price shows up once the work is done. The intent is honest, and I know what I’m talking about: we made exactly the same choice for the pricing of our RAG chatbot, for the same reason. Give the user a threshold to project onto.

You just have to see that threshold for what it is. The quota tells you what’s included and, if you turn off auto-reloads, it caps your spending. What it doesn’t tell you is the result you’ll have reached when it runs out. How many credits to get to an app that holds up? Nobody knows in advance, not even the tool: it depends on what you ask for, what fails, what you redo. The first screen comes fast. It’s the button to redo, the bug to chase, the “just one more prompt” that reveal the real burn. Once you hit the cap, two options: wait for the reset, or pay more. Everywhere, the free tier is a taste, not a build budget.

Fall 2025 illustrated it at Replit: after the switch to effort-based pricing, users reported bills jumping from roughly $200 a month to nearly $1,000 in a single week, iterating on existing code. Extreme cases, fixed since, partly refunded. But they say something about the nature of the system: you discover the price as you build.

And that bill only counts the dollars. The debugging session that burned a pile of credits cost you an evening first.

One app can run three different meters

Talking about “the” meter, singular, keeps a confusion alive. A generated app can be metered in three places.

1. The build meter

It runs when you ask the agent to create, change, or repair. It’s the most visible one: credits at Lovable, tokens at Bolt, effort at Replit. At Bolt, the documentation states that most consumption comes from reading and syncing your project files: the bigger your app gets, the more the same prompt costs.

2. The infrastructure meter

A published app needs hosting, compute, and a database. At Lovable, the Cloud balance is separate from build credits, and when it runs out, the app can be paused until you top it up. The budget stays capped, but the price is an interruption of service.

3. The usage meter

At Base44, integration credits are consumed by the published app itself: an email sent, an AI call, a file processed, an image generated. A static storefront consumes next to nothing; an app whose users lean on those features consumes in proportion.

Saying “the bill follows your success” would be too simple: the meter follows whatever the architecture makes billable. But when growth runs through those places, project size, cloud, user actions, the bill accelerates exactly when your app starts working. It’s written in their docs. Not on their homepages.

A meter is not a trap

Let me be clear: usage-based pricing is not a scam. Starting with next to nothing and paying only for what you consume is the most rational model for exploring an idea, standing up a prototype, or running an internal tool used now and then. And a hard cap, reloads off, genuinely protects a budget. You just need to know what it protects and what it interrupts: the agent, an integration, or the app itself. Auto-reload protects the opposite thing, continuity, and reopens the bill.

So the question isn’t whether a fixed price is morally superior to a meter. It’s which risk you’d rather hold: the amount, the uptime, or the scope.

Custom development hides part of the cost too

Custom development keeps the opposite illusion alive: a number known in advance, the quote, and a meter kept out of frame. As of July 2026, Clutch’s directory puts the average project at around $90,780 on its marketplace; the quote says nothing about what comes next, hosting, fixes, the upgrades that OS releases force on you, the stores’ rules. An Apple developer account costs $99 a year for as long as the app lives; Google Play’s, $25 once. Our CTO Dumè recently detailed what breaks in an app when nobody touches it for three years.

The two illusions are symmetrical, and that’s what strikes me most. Custom development shows you the price of the build and hides the price of the years. The generator shows a tiny sticker and starts the meter at the first prompt. Same truth on both sides: the real cost of an app lives after day one.

So how much does an app cost in 2026?

There is no single useful number, because three business models cover different projects.

Custom development. Up front: a design and development quote. Next: maintenance, infrastructure, evolutions, the stores. A good fit for a product built on highly specific business logic.

AI app generator. Up front: free, or an entry subscription. Next: build, cloud, integrations, and AI features depending on the tool. A good fit for fast exploration, prototypes, and products you’re willing to steer technically.

Mobile App Builder. Up front: a tiered subscription. Next: quotas, paid options, developer accounts. A good fit for an app meant to last, built on proven building blocks, run day to day by a non-technical team.

The meter logic has one more consequence, which I unpacked separately: an audience can be too small for custom development and still sustain an app.

Before choosing, four questions make the offers comparable:

  1. Which unit is billed: the build work, the infrastructure, or your users’ activity?

  2. What happens at the limit: a stop, a slowdown, a manual reload, or automatic overage?

  3. What does the main line cover: hosting, database, CMS, notifications, updates, publishing?

  4. Which costs stay separate: stores, extensions, third parties, AI features?

What a fixed price can actually promise

At GoodBarber, we went with a tiered subscription: as of July 20, 2026, starting at $360 a year for a PWA, and $660 a year with native iOS and Android apps, that’s $30 and $55 a month on an annual plan.

That price doesn’t buy a guarantee of success. It buys a known scope: the build tool, hosting, the database, the CMS, notifications within the plan’s limit, the platform’s technical updates. Redoing a screen doesn’t consume credits.

Not everything in it is fixed, either: the Apple and Google developer accounts stay on you, some extensions are paid, and our optional AI features, the RAG chatbot, the AI Extension Builder, have quotas of their own, because inference costs money, for everyone. The difference isn’t “fixed versus variable.” It’s where the variability sits: with us, at the edges, on clearly labeled options; with the generators, at the core, on the very act of building and running the app.

The rare thing in 2026 isn’t a free app. It’s a cost model you understand before you build.

So before picking the tool that will generate your app in thirty seconds, don’t just ask “how much does my app cost?” Ask: “what’s on the meter, where’s the cap, and what happens when I hit it?”