What does an AI-built app really cost?
There is no defensible single monthly price without an app, a workload and a billing period. A static landing page, an app with user uploads and an AI chat product do different work after publication. Count the services your product actually uses, not every possible item in a generic software stack.
Start with two totals: cash paid during the period and usage consumed during the period. Buying credits today and using them next month are different events. Human time is a third measure; keep it in hours unless you explicitly choose a rate. This is a planning method, not measured pricing for any particular app.
The six-line budget
| Line | Measure | Possible charge | Your amount |
|---|---|---|---|
| Builder plan | Seats, plan and billing period | Plan quote | UNKNOWN |
| Additional build usage | Retries and edits beyond included usage | Token / credit top-ups | UNKNOWN |
| Hosting and backend | Compute, requests, database, storage and transfer | Uncovered usage or fixed service fee | UNKNOWN |
| AI inside the app | Model calls made by the running product | Uncovered gateway usage or provider bill | UNKNOWN |
| Other services | Domain, email, payment fees and monitoring if used | Renewal or transaction-based charges | UNKNOWN |
| Human work | Review, repair, support and maintenance | Hours; optional declared hourly rate | UNKNOWN |
For each row record provider, currency, billing period, included allowance, expected usage, source URL and checked date. Use NOT APPLICABLE for a service you do not use. An unconfirmed charge is UNKNOWN, not zero. If one subscription covers several rows, give them the same allowance identifier and count the payment only once.
Count each payment once: subscriptions due + additional usage purchases or uncovered charges + separate service bills + taxes. Do not add the value of included credits to the subscription that bought them.
Three billing examples that change the calculation
Lovable: one balance does not mean one kind of work
Lovable is rolling out a unified credit balance. Build, Cloud and app AI usage remain distinct; usage-specific grants are used before general credits. Some workspaces retain the previous experience. Top-ups are purchases outside the subscription. Verify your account's balance model before estimating an extra payment.
Lovable connectors: identify who bills the request
In Lovable's unified-credit reporting, Build credits and Run credits are usage views, not separate balances. Managed connector usage draws from the monthly connector grant first, then general credits. Monthly Cloud and AI grants do not cover connector usage. As checked October 14, 2026, Free, Pro and Business include 1 credit per month for connectors; this is a temporary offering, not a permanent entitlement. Unused connector grants expire rather than roll over: Free refreshes on the calendar month, Pro and Business on the subscription cycle. Check the owning workspace's remaining grant and current rate before budgeting uncovered requests.
| Connection | Who pays | What to record |
|---|---|---|
| Managed by Lovable | The project-owning workspace, under Run credits | 4 Lovable credits per US dollar of Parallel usage, or 2 on Business; verify the current plan and rate. |
| Use your own credentials | Your Parallel account directly; no Lovable credits for these calls | The provider's usage and bill, separately from the builder subscription. |
Parallel's managed research task is charged when created; reading its result is free. Requests fail when the workspace lacks credits, and usage reporting can lag. No separate API key is required for the managed connection, but that does not mean free usage. These terms are specific to Parallel, not every connector.
In your budget, record the connection mode, billed workspace or provider, request/task volume, rate date and actual stop condition. Count the underlying payment once, not both as consumed credits and as a second service bill. We have not run or benchmarked this integration; your actual cost remains UNKNOWN.
Bolt: generation allowance is not a hosting budget
Bolt counts tokens while processing project context and generating changes. Its hosting plans separately specify request and bandwidth allowances. Track both categories. A remaining building allowance is not proof that a live app has unlimited hosting capacity or that an external service is paid for.
Bolt Forge: the preview deadline is plan-specific
Forge's research preview ends October 14, 2026. Pro access to Forge and its additional free usage end on that date; the Pro plan and Standard and Max usage are unaffected. October 14 is also the last day to sign up for Lite. Under the documented terms, existing Lite subscribers keep Forge at $9 per month, renewing until cancellation. This is not a shutdown of every Forge subscription. Record the actual plan, entitlement period and renewal separately from hosting and external bills; account-specific access and measured costs remain UNKNOWN. ShipStackLab has not subscribed or tested this transition, and this worksheet is not a recommendation to buy a plan.
Replit: the deployment type matters
Replit documents publishing usage in transfer, autoscale compute and requests, with separate database metrics. Static deployments do not use autoscale compute units. Record your actual deployment type and its rates; applying an autoscale estimate to a static page produces the wrong budget.
These are billing structures, not a price ranking. For the specific two-product decision, use Lovable vs Bolt. Avoid converting one vendor's credits into another's tokens as though the two units represented identical work.
Lovable: a low balance, a usage block and a paused backend are different
Usage limits & alerts is available on paid plans; only workspace owners and admins can change rules. Run usage belongs to projects, not member Build limits. Record scope, credit type, period and blocking behavior before choosing a recovery action.
| Condition | Effect | Recovery boundary |
|---|---|---|
| Workspace balance exhausted | Building and runtime AI stop; built-in backend services can pause. Published pages still serve. | When credits return, check backend status. If still paused, use More → Cloud → Overview → Wake up. Data cannot be accessed or exported until services run. |
| Usage limit with blocking enabled | Build stops editing; Cloud pauses backend; AI or Connectors pauses that service; Run covers all three. General covers all usage in scope. | Adding credits does not lift a usage block. Wait for the period reset, or have an owner/admin approve raising the threshold or disabling blocking. Then wake a Cloud-paused project. |
| Alert or auto-top-up purchase limit | Low-balance alerts only notify. An auto-top-up limit caps purchases, not app usage. | Neither is a service hard cap. Check the actual balance and blocking rules separately. |
Usage can exceed a limit slightly before enforcement. Paused storage still consumes credits; removing Cloud is irreversible, not a recovery shortcut. The empty-balance FAQ describes a separate cause from configured usage blocking. Neither a restored balance nor a loaded page proves login, database, uploads or AI works. This is source-backed planning: we have not triggered limits or measured recovery.
Vercel: stored deployment history is a separate cost
Vercel's October 9 announcement extends Deployment Storage and Functions Storage billing to existing Pro teams at $0.10 per GB-month. The team email gives the actual billing start. The notice also sets a 30-day retention window, with cleanup starting October 23 unless the team opts out beforehand; settings already at 30 days or less stay unchanged.
Record retained deployment output and function storage separately from application files and database storage. Review Usage and the actual project policy before estimating a charge; the rate alone is not your bill. Do not automatically buy more storage or remove history.
Retention has exceptions and a recovery period; age alone does not prove a deployment was deleted. A deleted build is not immediately rollback-ready. Use the Vercel rollback checklist to review the recovery consequence before shortening retention. This is a billing review, not a measured Vercel bill or an executed cleanup.
Define a workload before estimating a bill
Mostly static website
Count edits, visits, asset transfer, domain renewal and any form service. Do not add a database merely because the builder offers one.
App with accounts and uploads
Add active users, reads and writes, file storage, download traffic, authentication and backup requirements.
AI feature inside an app
Add model calls per user action, input and output size, retries, background jobs and abuse exposure. Editor generation and runtime model calls are different workloads.
Make three workload scenarios: a quiet month, your intended operating month and an explicitly assumed spike. Record the assumptions, not just a total. More visits can multiply transfer and requests without causing another editing session; a large refactor can consume build usage without bringing a single new visitor.
A worked example of avoiding double counting
Suppose a fictional plan costs $30 for the month, you buy a $10 top-up, pay $8 for a separate service and renew a domain for $24. Cash paid that month is $72 before tax. If you allocate the domain renewal across 12 months, the corresponding planning total is $50. These amounts are invented to explain the method, not vendor prices or a promised budget.
Do not add the plan's included credits as another $30 expense. If part of the top-up remains unused, the $10 is still a cash payment, but it is not all attributable to work completed this month. Record any review hours separately. A cost-per-feature claim needs both attributable usage and a defined, accepted feature—not a prompt count.
Copyable budget record
Copy and fill in the record below in your own notes. This page does not calculate or save a budget, and nothing needs to be sent to us. Never include credentials, customer records or payment details.
- Period / currency / account plan: __________
- App type / deployment type / backend: __________
- Expected edits / visits / requests / model calls: __________
- Subscriptions due / shared allowance IDs: __________
- Included usage / expiry / expected uncovered usage: __________
- Top-ups / outside services / renewals / taxes: __________
- Connector / managed or own credentials / billed account / request volume: __________
- Cash total / normalized monthly estimate: __________
- Measured usage / remaining prepaid balance: __________
- Human hours / optional hourly rate: __________
- Billing evidence URL / checked date / unknowns: __________
- Alert threshold / actual cap or stop action / owner: __________
- Limit scope / credit type / period / blocking / recovery evidence: __________
- Deployment storage / billing start / retention / recovery owner: __________
Before increasing traffic or buying a larger plan
- Identify the meter. Find which project and service caused the usage. Separate building, production traffic and background work.
- Check what a limit does. An alert, a top-up spending limit and a hard service cap are different. Record the documented behavior when each threshold is reached.
- Agree on a stop action. Decide who may pause a costly integration or change a plan, and what user impact is acceptable. Do not silently shut down a live service.
- Reconcile a small observation window. With approval, use normal authorized activity and review reported usage after processing delays. Do not manufacture traffic or purchase capacity just for this worksheet.
- Review the baseline. Recheck after a plan, model, architecture or workload change. Preserve the old assumptions so the comparison remains meaningful.
If the bill suggests moving platforms, first read what code export does not move. A lower hosting quote can leave migration work, authentication and support costs unresolved. Use Stack Builder to list every service owner before you count the stack as complete.