# What does it cost to launch an AI-built app?

Mik Bry · 2026-07-23 · ~8 min read · AI

![A small stack of everyday objects balanced like building blocks, one meter needle just starting to tip past its marked zone.](/assets/2026-07-23-hidden-costs-hero.png)
The pitch you keep seeing is: pay twenty dollars a month for the AI, describe what you want, ship an app. Tool, outcome, nothing in between. Everything is in between. Twenty dollars a month buys you a hammer, not a house. Between the hammer and the house sit a foundation, plumbing, wiring, a roof, a door, an address — and someone showing up every month with a bill. I'm not reviewing code in this piece. This is for the stage before that: what it actually costs to get an AI-built app in front of real users, so you can plan for it instead of discovering it. The real question isn't "how much does an AI-built app cost?" It's "what makes the bill grow when usage starts?" A number goes stale the day a provider changes a tier; the mechanism that turns it loud doesn't.
Freshness note
Every price below was checked against the provider's own page on **17–18 August 2026**, with a source link. Providers change tiers without warning; treat anything older than a few months as a starting point, not a quote. I re-check this list roughly every quarter.
Where the money goes
1. [Fixed costs before your first user](#s1) 2. [Usage-based costs that jump](#s2) 3. [Mobile and AI costs, if they apply to you](#s3) 4. [Five questions to answer before you budget](#s4) 5. [My default: EU providers, a VPS, and boring economics](#s5) 6. [Launch readiness](#s6)

01 — Fixed costs before your first user

Any app a real person can use — pay for, log into, get emails from — sits on a small pile of services: a domain, hosting, a database, email delivery, authentication, file storage, a build pipeline, a payment provider, analytics, error tracking, and, if your product does AI work, an LLM API on the back end. Most of that pile is free or near-free before anyone shows up. What's genuinely fixed, regardless of traffic, is smaller than it looks: a domain (roughly €10–20/year), a baseline hosting plan, and — only if you're building mobile — the [Apple Developer Program at $99/year](https://developer.apple.com/programs/) and a [one-time $25 Google Play Console registration](https://support.google.com/googleplay/android-developer/answer/6112435). Everything else starts free and turns usage-based the moment someone actually uses your app. That's the part worth planning for: the cost can stay close to zero for a while, then jump as soon as you cross a usage threshold.

Reference: Apple Developer Program ($99/year) and Google Play Console registration ($25 one-time), checked 17 August 2026.

02 — Usage-based costs that jump

Costs on this stack don't grow in a straight line. You use something for months at zero, cross a boundary you didn't know existed, and get a bill. Sometimes the free tier just ends. Two confirmed, dated examples. **SendGrid retired its permanent free plan in late May 2025** — existing free accounts got a 60-day grace period, then paid-or-migrate; its cheapest paid plan starts around $19.95/month ([Twilio SendGrid changelog](https://www.twilio.com/en-us/changelog/sendgrid-free-plan)). **PlanetScale retired its free Hobby tier on 8 April 2024**; its cheapest entry plan is still $39/month ([PlanetScale changelog](https://planetscale.com/changelog/deprecating-hobby), [PlanetScale pricing](https://planetscale.com/pricing)). Neither was announced far in advance. **My rule: treat a free tier as a temporary offer, not as your business model.** Supabase is a common choice for AI-built apps — it bundles Postgres, auth, file storage, and a native [pgvector extension for embeddings](https://supabase.com/docs/guides/ai) in one place, a good way to get something working fast. My reservation isn't quality, it's coupling: for a product I expect to grow, I usually prefer an independent managed Postgres — Neon, Scaleway, AWS RDS — so auth, storage, and the database can each change on their own schedule later. Know the caps either way: free holds 500MB and 50,000 monthly active users; the flat **Pro plan starts at $25/month and includes 100,000 MAU**, with usage charges past either quota ([Supabase pricing](https://supabase.com/pricing)) — the same shape of surprise as anything else usage-based here. The sharper version of the same problem is a database that bills per operation from the start. Firestore's rate isn't one number — it varies by region and edition, Standard and Enterprise using different pricing models entirely ([Firebase pricing](https://firebase.google.com/docs/firestore/pricing)). One dated illustration, not a universal quote: Google's own billing example puts a single-region Standard rate at **$0.06 per 100,000 document reads and $0.18 per 100,000 writes**, after a free daily quota of 50,000 reads, as of 18 August 2026 ([billing example](https://firebase.google.com/docs/firestore/billing-example)). What doesn't vary is the mechanism — it stops being cheap per unit the moment one screen mounts a live listener and every visitor, on every visit, re-triggers it. Know what one visitor doing one ordinary thing costs, before thousands do many.
A detail worth knowing before you rely on it
Google Cloud's own documentation is explicit: an "alerts-only" budget **does not** cap spending or stop your services — it emails you after the threshold is crossed, and the meter keeps running unless you build a separate mechanism to disable billing yourself.
If you're already on Firestore, that's not a verdict — plenty of small apps run there for a long time inside the free quota. It's a reason to know the mechanism before you're the one explaining the bill. One widely discussed Hacker News case described a misconfigured process turning a roughly $50/month bill into tens of thousands in a single day after an unexpected volume of writes — unusual, but a useful illustration that budget alerts alone don't prevent it ([Hacker News thread](https://news.ycombinator.com/item?id=42732714)). Moving off Firestore later isn't free either: Google's export tooling writes to a Firestore-specific format, usable inside Firestore or BigQuery, with no documented direct path to another database — migrating means building that conversion yourself ([Firebase export/import docs](https://firebase.google.com/docs/firestore/manage-data/export-import)).

References: Twilio SendGrid — free plan changelog; PlanetScale — Hobby deprecation; Supabase — pricing; Supabase — AI & Vectors; Firebase — Firestore pricing; Google Cloud — budget alerts; Firebase — export/import. Checked 17–18 August 2026.

03 — Mobile and AI costs, if they apply to you

Two categories only matter if your product touches them — but when it does, they move the numbers more than anything above. **Mobile.** Apple's standard commission is 30%, or 15% on subscriptions after a customer's first paid year. The Small Business Program drops that to 15% overall for developers under $1M in annual proceeds — cross that line mid-year and you're back to 30% for the rest of it ([Apple Small Business Program](https://developer.apple.com/app-store/small-business-program/)). Google Play's fees depend on the programme and billing model, not one flat number: a common tier is 15% on your first $1M/year and 30% above, subscriptions commonly at 15% regardless of revenue ([Google Play service fees](https://support.google.com/googleplay/android-developer/answer/112622)) — but alternative-billing programmes can lower that, and a **restructured fee took effect 30 June 2026 in the US, UK, and EEA**, splitting the old rate into a service fee plus a billing fee ([Android Developers blog](https://android-developers.googleblog.com/2026/06/play-expanded-billing.html)). Check your programme terms rather than assuming the simple version is universal. Building mobile CI on GitHub Actions? For private repos, a macOS runner costs roughly 10x a Linux one, free tier 2,000 minutes a month — public repos on standard runners are free, but an iOS build weekend on a private one can burn through that fast ([GitHub Actions billing](https://docs.github.com/en/billing/concepts/product-billing/github-actions)). **AI.** The $20/month you pay for ChatGPT or Claude is a consumer subscription — you're the user. A product calling the same AI for *your* users pays the API price instead, per token, sent and received. As of 18 August 2026, Claude Sonnet 5 is $2 per million input tokens and $10 per million output tokens. That introductory price runs through 31 August; Anthropic lists $3/$15 from 1 September ([Anthropic pricing](https://platform.claude.com/docs/en/about-claude/pricing)). OpenAI's GPT-5.6 Sol is $5 in, $30 out ([OpenAI API pricing](https://developers.openai.com/api/docs/pricing)). Both will change again — check the date, not just the number. Here's the shape of the surprise. A chatbot has no memory of its own, so it resends the growing conversation on every turn — a "10,000-token conversation" is really many small messages, each carrying the whole history back, and output tokens cost more than input. Put those together and a feature that looks like a few dollars a day can become real money at the volume a genuinely-used app produces — potentially the largest line on the bill. Anthropic's prompt caching discounts repeated context up to 90% on a cache hit, and its batch API is 50% off for non-real-time work. Provider changes usually mean adjusting prompts, not a rewrite from zero, but it's real work, worth planning for rather than discovering.

References: Apple — Small Business Program; Google Play — service fees; Android Developers blog — 2026 fee restructure; GitHub Actions — billing; Anthropic — API pricing; OpenAI — API pricing. Checked 17 August 2026.

04 — Five questions to answer before you budget

Before spending anything on construction, these are worth answering in a page, not a spreadsheet: 1. **Which of these categories apply to me** — mobile, AI-facing, cross-border EU sales — and which don't? Half this article may not apply to your idea. 2. **Where's my free-tier cliff**, on each service I rely on, and what happens the day I cross it? 3. **Do I know what normal usage from one user actually costs** — database, AI, storage, email — and how that cost changes as the number of users grows? 4. **Have I set a real spending cap**, or only a budget alert that emails me after the money's gone? 5. **What's the one choice** — usually the database, sometimes the AI provider — that decides whether month twelve is manageable? If your idea's real, the table below maps where spending starts at each stage, not a forecast. No euro figures — the real number depends on your stack and usage pattern; the categories are the reusable part. | Stage | What usually starts costing money | |---|---| | Pre-launch | Domain, hosting, paid tooling | | Early users | Email delivery, database, logs, storage | | Paying users | Auth crossing its free cap, payment fees, support tooling, AI usage | | Growth | Database operations, egress, LLM inference, monitoring | Infrastructure cost is rarely the only reason a product fails. But it gets painful fast when usage grows faster than revenue and nobody modelled the cost per user beforehand — the gap your own numbers above will show you, if you fill them in before you build rather than after. The remedy isn't becoming an infrastructure expert. It's knowing your own stack's cost curve — which items on the list above you actually need, where each one's step-function boundary sits, and which single choice decides whether growth is manageable — before you commit to a stack that shapes everything else.

05 — My default: EU providers, a VPS, and boring economics

When I set up infrastructure for something I expect to run for years, my defaults aren't chosen for the lowest price line. For hosting and storage, I default to French or European providers — Scaleway, OVH, sometimes Hetzner. It gives me a simpler data-location story, reduces my dependency on US hyperscalers, and keeps more of the technical chain in Europe. For a small-team product with steady usage, I also default to a VPS over serverless: a fixed-size machine, a monthly bill known in advance, no cold starts. Serverless is the right tool for bursty, unpredictable traffic — I move a workload there when it actually needs it, not before. None of this is dogma. Global edge inference or genuinely unpredictable burst capacity is a real reason to reach for a hyperscaler or serverless from day one. For most first products, the boring default is the safer one.

06 — Launch readiness

Back to the real question from the top: what makes the bill grow when usage starts. Money is one shape of the same underlying question — what haven't you checked yet? A hidden cost you didn't budget for and a security hole you didn't test for come from the same blind spot — something that only appears once real users, real payments, or real traffic arrive. I check both, same discipline wearing different clothes. Knowing which costs are fixed, which are usage-based, and which is billed per operation instead of on a flat plan is worth naming *before* you launch — the same posture as checking who can read someone else's data, or what happens when a payment silently fails. If you want the security and data side, [Six things I check before trusting an AI-built app in production](/blog/ai/six-ai-built-app-red-flags) covers it. This piece covers the financial-surprise side.
If you want to go further

I review AI-built and vibe-coded applications before they go into production.

Start here
Trust Report

An automated review of your app and its code, using my analysis tools. You get the main risks, what deserves attention before launch, and what can wait. If you want to discuss the findings, a review with me is available as an option.

€349 one-time
Get yours
Audit — need a deeper look?

Architecture, payments, access, customer data, deploy-key custody, third-party software + a documented launch recommendation from a human CTO.

from €1,200 Talk to Mik