What Will My App Cost After Launch?

We launch our app next month. I budgeted for the build, but nobody told me what it costs to keep it running: hosting, the AI features, the developer. What should I plan for each month?

Two bills start after launch: running the app and working on it. Running is often a few dollars a month until users arrive. The AI features bill per conversation.

The work is usually the bigger line. Users find edge cases, providers change their APIs, the next feature waits. SaaS development is a weekly investment, and launch is where it starts.

I'd plan both lines before launch day, starting with the small one.

A Small Tool Runs on Almost Nothing

Free tiers cover a small tool. Hosting, a database, sign-in and file storage all come with one, and a tool for one team stays close to them.

The parcel tool I shipped is the usual case. It runs on Firebase, and through five years of daily use it cost about $3 a month.

A portfolio site with a CMS we built on Next.js, Airtable and Vercel ran on their free tiers alone.

At this size, the design sets the bill more than the traffic does. My RSS reader, Fidder, cost about $17 a month with one user.

Security rules that read the database on every check did most of it, plus a server polling for work. After the fix it cost $0.75 a month.

A bill that grows faster than the users is a design question. Why is my Firebase bill so high? traces where one like that comes from.

So if your app is small at launch, the first bills can sit near zero. Users are what change that.

Users End the Free Tiers

The database, email and storage start billing as users arrive. Error tracking, backups and analytics follow. Each has a free plan and a paid one, and a product with real users needs some of the paid ones.

The build cost tool I made puts numbers on it. For a typical MVP it budgets $20 to $200 a month for hosting. The realistic minimum, all in, is $100 to $500 a month.

Every extra service adds a bill, a dashboard and a key to rotate. Consolidation is why I start on one platform for sign-in, database, storage and hosting. That's one bill to read instead of seven.

The line that surprises people is a paid third-party API. In January 2025, X charged SaaS providers at least $200 a month for enough quota to serve their users. It has moved to pay-per-use since, which is the other risk: that price is someone else's decision.

My own site is the example I can show in full. With its AI tools, varstatt.com runs under $50 a month all-in. The tool pages are static, and no build step calls a paid API.

AI Bills Every Conversation

Your AI features bill differently from everything above. Providers charge per token: the text sent in and the text the model writes back.

A monthly chat bill multiplies four numbers: conversations, messages per conversation, tokens per message and the model's price. The third one grows inside each chat, because every message resends the history.

So the shape of the feature matters as much as the traffic. Three shapes cover most AI features:

• One call. A summary, a draft, a category. The cost per use stays flat.
• An assistant. A chat resends the conversation with every message, so the cost grows with the length of the chat.
• An agent. A model that calls tools makes several requests per task, so one click can become many billed calls.

Two more choices move the total. The model comes first: answers from a short FAQ rarely need the largest one.

The spread is wide. On Anthropic's price list in October 2026, a million input tokens cost $0.10 on its smallest current model and $10 on its top one.

The history comes next. On an eight-step AI workflow I built, each step started over. It carried labeled results and the last 30 messages instead of the whole history. That lost the cache discount, and it still came out about 27% cheaper.

My Discovery tools are now a single call each, and in an October test a run cost about 4 cents.

The cheapest bot is the one that never runs. My 404 page's AI chat opened 272 times. Six times someone typed, nobody left an email, and I removed it.

The Bills Belong on Your Card

Whoever builds the app, the running bills should sit with you from day one. Hosting, database, email and model keys open in your name and bill to your card.

That does three things:

• You see the real bill, with no markup inside it.
• Nothing switches off when the developer leaves.
• You can stop working with anyone any week, because nothing runs on someone else's account.

With n8n it's also a license question. Its community license lets a developer run a client's workflows on their own instance only as long as the client can't open or edit them. A workflow you should be able to open belongs on your own instance.

So before launch, check whose card each of your bills sits on. Who owns the code my developer writes? has the full list of what should be in your name.

The Work Is the Bigger Line

The second bill is the work. Users hit edge cases, providers change their APIs, models get retired or repriced. Each new feature touches the last one.

That's one job, not a build followed by a maintenance phase. No Split is why I don't price it as a separate phase. Whoever built a feature fixes it, knowing how it's used.

A small tool needs little of it. Over five years the parcel tool gained multi-currency support, more stores and a move to a new shipping API.

A product with users needs some of it most weeks, and the work surges, then slows. Pause, Not End lets that work stop when it's quiet and pick up where it stopped.

So the question before launch is whether the weeks after it fit the budget. If they don't, the business model may not be viable yet.

How I Plan the Months After

Before I build an AI feature, I price one request at the expected volume. You know the cost per conversation before users start any.

Every account runs in your name from the start. The providers bill the usage and the hosting to you, and none of it passes through my invoice. An n8n workflow I build goes on your instance, and I hand it over.

After launch, SaaS development carries on week by week: features, integrations and fixes, in the order users show. It pauses when the work is quiet. The price is on the homepage.

What the Founder Should Plan Now

Plan two numbers before launch day. The first is the running budget: the bills above, set per month, read every month and each one on your own card.

The second is the work, set in weeks, not as a maintenance fee. Start it at launch, when the first users find the first edge cases. For the first months, plan the developer at the same weekly pace as the build.

After launch the real work starts. Users find bugs, assumptions break and the product has to adapt. What people do with it shapes the software more than any plan made before. So let their use set the pace after that.

For your launch next month, the bills are the easy part: usually small and simple to read. The developer's weeks are most of what your app costs after launch.