What does it actually cost to build an app with AI?

Fabricate charges credits for AI work. A focused fix uses fewer credits than adding a feature, and a feature usually uses fewer than generating a complete application.

Every plan includes a monthly credit pool, with larger allowances and higher limits on paid plans. The Pricing page is the source of truth for current plan details. There is no surprise usage invoice on top of the plan: if the available balance or a safety limit is reached, generation pauses until the balance refreshes or the plan changes.

There is no honest fixed price for every app. A landing page, a subscription product, and a multi-role dashboard require very different amounts of work. The useful way to budget is by the size of each request and the charge shown after your own completed generations.

A credit is Fabricate's customer-facing unit for AI work. It lets a quick correction cost less than a large build without asking you to interpret technical usage logs or compare external price sheets.

The charge reflects the kind of work requested, the amount of project context needed, and how much new output the generation creates. It is not a flat fee per message: changing one sentence and building five pages are not treated as the same request.

Every completed generation is itemised in Settings → Billing. That history is the best source for your own budgeting because it reflects the kinds of apps and prompts you actually use.

Scope is the largest factor. A precise request such as "change this button label" is smaller than "redesign the dashboard", which is smaller than "build the complete product".

Generated output matters too. Reading enough of your project to locate a bug can be substantial work, but rewriting many files generally costs more than returning a short diagnosis or a small patch.

Complex features can require several coordinated steps. Authentication, payments, data models, permissions, and deployment checks involve more work than a visual-only change, even when the prompt is short.

Retries and broad revisions can add usage. The most reliable way to stay efficient is to ask for one clear outcome at a time and review it before expanding the scope.

There is no universal numeric estimate for a request because two features with the same name can involve very different amounts of work. The useful comparison is relative scope.

A quick edit generally uses the least. That includes copy changes, color adjustments, small layout tweaks, and targeted bug fixes.

A new feature generally uses more. Examples include a new page, a form, an API integration, or adding authentication to an existing project.

A full app generally uses the most. Multi-role workflows, payments, and substantial backend behavior add scope beyond a simple single-page product.

Fabricate uses a stable credit rate for each kind of build step. If the same kind of action consumes the same amount of AI work, its customer credit charge stays consistent even as we improve the systems used to perform it.

That separation is intentional. Credits are a product unit with predictable plan allowances. Improvements behind the scenes should not turn your balance into a moving target.

Different requests can still require different amounts of work. What remains stable is the rate assigned to the kind of action, not a promise that every message costs the same.

A first build begins with an empty project and must create the structure, screens, behavior, and deployment-ready code. That is usually the largest amount of new output your project will need in one request.

An edit starts from something that already works. A focused follow-up can change only the relevant files instead of recreating the application, which is why iteration is commonly much cheaper than the initial build.

This is also why "how many apps can I build?" is less useful than "how many new builds and follow-up changes do I expect?" Most real projects use a mix of both.

Every plan has a per-generation ceiling. Its purpose is simple: one unusually broad prompt should not be able to consume an unlimited share of your monthly balance. When a run reaches its safe boundary, Fabricate stops at a coherent checkpoint so you can continue later.

Free also has a daily limit in addition to its monthly pool. Paid plans have larger per-generation limits and no free-tier daily limit. Current plan allowances and limits are always shown on the Pricing page.

Credits reset each billing cycle and do not roll over. If you consistently finish with a large balance, a smaller plan is likely a better fit. If you repeatedly reach the limit, a larger plan gives more monthly headroom.

Flat subscriptions are easy to budget, but their usage limits can be difficult to predict. Per-message plans are easy to count, but they price a one-line fix and a large rewrite as the same turn.

Seat-based plans work well for teams but can become expensive when many people mostly review rather than generate. Raw technical usage is precise, but it is difficult to forecast without specialist knowledge.

Credits sit in the middle: they make small work cheaper than large work and set hard limits, while keeping the customer unit easy to understand. The tradeoff is that the cost of an app cannot be known exactly before its scope is known.

Start with one representative project on Free and review the completed generation charge. A real example from your workflow is more useful than a platform-wide average.

Estimate a month as a mix of new builds, features, and small edits. For example, a founder validating one product usually needs one initial build followed by many focused changes, not a month made entirely of new apps.

Compare your actual history with the current allowances on the Pricing page. Pro is designed for regular individual use, while Scale provides more monthly capacity and higher limits for heavier workflows.

Credits can create meter anxiety. A visible balance may make people hesitate to iterate, even when another small change would improve the product.

Credits also require experience to forecast. We can explain what raises or lowers usage, but we cannot promise one price for every app because the scope of an app varies enormously.

The benefit is proportionality and a hard boundary: focused changes use less than broad generations, and a single request cannot create an unlimited bill. Whether that is better than a flat fee depends on how much control you want over usage.