Short answer: because every provider is a separate merchant with its own subscription, its own billing cycle and its own idea of what counts as usage. Nothing consolidates them by default. The tooling that made it trivial to add a ninth service did nothing about the ninth invoice, and the cost of a vibe-coded app is now mostly a paperwork problem rather than a compute problem.
This is new. Five years ago a hobby project ran on one server from one company. Today a small app that took a weekend to build routinely touches a hosting platform, a database, an auth provider, an email API, an object store, an error tracker, an analytics tool, one or two model APIs and the coding agent's own subscription. That is nine relationships, and every one of them wants a card on file.
Do the inventory first
Most people have never written the list down. Do it now, from your card statement rather than from memory, because memory reliably misses two or three. A realistic list for one small live app looks like this:
| What it is | Bills as | Why it is easy to forget |
|---|---|---|
| Coding agent subscription | Flat monthly, per seat | Feels like a personal tool, not a project cost |
| Hosting | Flat, plus bandwidth and function overage | Free until a link gets shared |
| Database | Flat per project, plus compute and storage | Per project, so a second project doubles it |
| Auth provider | Free to a user count, then per user | The cliff arrives with success |
| Email API | Free allowance, then per thousand | Daily limits look like monthly limits |
| Object storage | Per GB stored, per operation, sometimes egress | Three separate meters on one service |
| SMS or voice | Per number per month, per message, plus carrier fees | Registration and carrier fees are not in the calculator |
| Model APIs | Per token, prepaid or postpaid | An agent loop can multiply it overnight |
| Monitoring and analytics | Per event or per seat | Added by the agent, never reviewed |
Nine rows, nine vendors. If several of them sit on paid tiers at roughly twenty to twenty five dollars each, you are at a couple of hundred dollars a month for an app with fifty users, and almost none of that is the usage itself.
Five costs the pricing page does not lead with
The idle floor. Most paid tiers are a subscription, not a meter. A quiet month costs the same as a busy one. Three services at twenty five dollars is seventy five dollars whether anyone visits or not, and the number does not move when you stop working on the project.
Per seat, per project, per environment. Read which unit the plan multiplies by. Hosting often charges per member of the team. Databases often charge per project, so a staging environment is a second full price project. Add a collaborator and several bills change at once.
Three meters on one service. Object storage bills for what you store, for the requests you make and sometimes for what you send out. Each is cheap. The combination is what produces a bill you cannot explain.
Compliance and setup fees. Sending SMS to US numbers means registering a brand and a campaign, which has one-time and recurring costs that appear nowhere in the per message price. Nothing about that is unreasonable; it is just not in the number you budgeted with.
Currency, tax and card fees. Nine foreign currency charges on a personal card is nine conversion fees. If you are a registered business, it is also nine VAT or sales tax treatments to get right at year end.
The subscriptions outlive the projects
The compounding version of this problem is not one app with nine bills. It is four apps, three of them abandoned, and nobody cancelled anything. Vibe coding is fast enough that people start a project a fortnight. Every prototype creates accounts, and a paid tier that was added for one afternoon of testing renews quietly for a year.
The tell is a card statement with merchant names you no longer recognise. The fix is unglamorous: once a quarter, open the statement, match every line to a project, and cancel anything you cannot match. Expect to find two.
The question you cannot answer: what does this app cost?
Ask a founder with one product what it costs to run and you will usually get a number. Ask someone with three AI-coded projects what any single one costs and you get a guess, because the bills are organised by vendor and the projects are not. The database bills per project, so that part is clean. Hosting bills per team member across all projects. The model API bills one balance that three apps and your own experiments all draw from. The coding agent subscription is not attributed to anything.
This has a practical consequence beyond tidiness. You cannot decide whether a project is worth keeping if you do not know what it costs, so abandoned projects keep running and viable ones get killed on vibes. The minimum useful fix is to create a separate project or environment per app in every vendor that supports the concept, and to use distinct API keys per app in vendors that do not, so at least the usage reports split cleanly. It is tedious and it is the only way to get a per app number out of nine separate billing systems.
What actually helps
- One payment method for everything project related. A dedicated card or virtual card, never the personal one. It turns an archaeology problem into a single statement you can read in two minutes.
- A services file in every repository. A plain
SERVICES.mdlisting every vendor, the plan, the monthly cost, the account it belongs to and what breaks if it is cancelled. Your agent will happily keep it updated if you ask it to. - One billing email address that forwards. Send every receipt to one inbox, not to whichever personal address you were logged into that day. More on that in our post on automating receipts and invoices.
- Prefer usage-priced services over subscriptions while you are small. A service that costs nothing when idle is worth a slightly worse feature set at this stage.
- Set a cap wherever a cap exists. Not every provider offers one, and the ones that do rarely enable it by default.
Or stop having nine merchants
The structural fix is to have one commercial relationship instead of nine. That is what Squiid does: you fund one prepaid credit balance, and usage across every connected service draws from it at the provider's own list price with no markup. Subscription-priced plans, such as a database's paid tier, pass through on the same invoice at the provider's price with no fee added. At the end of the month you get one PDF invoice covering everything, which you can forward to a bookkeeper without explaining what any of the merchants are.
Squiid charges for that plainly rather than by marking up usage: nothing a month on the free plan with a 15 percent fee taken when you top up credits, 19.97 dollars a month on Solo where that fee starts at 8 percent and falls to 3.5 percent as your spend grows, or from 29.97 dollars per seat on Team where the same ladder runs a point lower. You can decide whether that is worth it, and the arithmetic is easy because nothing is hidden in the unit prices. What it removes is the nine sign-ups, the nine cards on file, the nine renewal dates and the quarterly archaeology session with your card statement.