AI App Build Cost for Agencies (2026): Bill vs Run
Split every AI build into build cost, run cost, and margin. A worked $22K example, a builder run-cost comparison, and an 8-item checklist to run before you quote.
Updated on July 2, 2026

On this page
Quick Answer (July 2026): An agency AI app has two cost lines that owners routinely conflate: the one-time build cost (scoping, generation, integration, QA, handoff) and the recurring run cost (hosting, database, AI usage, monitoring, support). Bill the build against client value; forecast the run cost for at least the first twelve months, because that is the line that quietly erodes margin after the client signs off. Agencies that quote a build number with no run-cost model are the ones that lose money by month three.
The public 2026 cost guides all answer the wrong question. They tell a buyer that "an AI app costs $40,000 to $400,000," which is a procurement number, not an operating model. For an agency owner the more useful question is narrower: of the price you quote, how much is build, how much is run, and how much survives as margin twelve months later.
We reference four platforms in the run-cost math below:
Totalum, Lovable,
Bolt.new, and
Vercel.
The number agencies keep getting wrong
A fixed-price AI build feels profitable at signature because the build cost is legible. You can count the hours, add a margin, and quote. The run cost is illegible at signature, so it gets waved off with "hosting is cheap." Then the app ships, real users arrive, the AI calls meter up, someone files a support ticket, and the profit you booked in month one is being paid back out in months three through nine.
This is not a pricing-too-low problem. It is a cost-modeling problem. The build was priced. The run was not.
The fix is to treat every AI build as three numbers, not one.
Build cost vs run cost vs margin: the three-line model
Split every engagement into three lines before you quote. The build line is what you bill. The run line is what the app costs to stay alive after handoff. The margin line is what remains, and it is a function of who carries the run line.
Scroll to see more
| Line | What it covers | Timing | Who usually pays |
|---|---|---|---|
| Build cost | Discovery, prompt/generation cycles, custom code, integrations, QA, handoff docs | One-time | Client (fixed price or T&M) |
| Run cost | Hosting, database, AI/inference usage, email, monitoring, backups | Recurring, monthly | Contested: agency, client, or split |
| Margin | Build price minus internal build cost, then minus any run cost you absorbed | Realized over 6 to 12 months | Whatever is left |
The trap is line two landing on line three by default. If your contract is silent on who pays hosting and AI usage after go-live, the agency absorbs it, and the absorbed run cost is subtracted directly from the margin you thought you locked in. We size the build side of this in our 2026 agency rate-card benchmarks; this piece is about the side those rate cards do not cover.
What actually shows up on the run-cost line
Run cost is not one number. For an AI-native app in 2026 it is a stack of small recurring lines that individually look trivial and collectively decide your margin.
- Hosting and bandwidth. A production Next.js app needs somewhere to run. Managed platforms bill per usage; see Vercel's own pricing for how quickly a serverless bill moves once traffic and function invocations climb. This is a real monthly line, not a rounding error.
- Database. Managed Postgres or an equivalent, plus backups and storage growth. Scales with rows and query volume.
- AI and inference usage. The line that surprises agencies most. Every model call has a marginal cost, and a feature that felt free in the demo meters up under real usage.
- Email, file storage, and third-party APIs. Transactional email, object storage, signed URLs, any external API the app calls.
- Monitoring and support. Uptime checks, error tracking, and the human time to answer "why is it slow today." Support is a run cost even when nobody put it on the invoice.
Notice how many separate vendor relationships that implies. That vendor count is exactly where the AI app builder you chose changes the math.
A worked example: a $22,000 client build
Take a mid-complexity internal tool: auth, a small CRM, a client-facing dashboard, one AI feature. You quote $22,000 fixed. Your internal build cost is $12,000. On paper that is $10,000 of margin.
Now add the run cost you quietly absorbed because the contract was silent:
Scroll to see more
| Item | Monthly | 12-month |
|---|---|---|
| Hosting + bandwidth | $60 | $720 |
| Managed database + backups | $45 | $540 |
| AI / inference usage | $120 | $1,440 |
| Email + storage + APIs | $25 | $300 |
| Monitoring + light support | $180 | $2,160 |
| Absorbed run cost | $430 | $5,160 |
The $10,000 margin is now $4,840. Roughly half your profit left through a line you never priced. Nothing went wrong operationally. You simply booked build margin and paid run cost out of it. This is the same effective-rate erosion we walk through in our effective hourly rate breakdown, viewed from the cost side instead of the billing side.
Where AI app builders change the math
Most of 2026's AI app builders reduce build cost. They differ sharply on run cost, and run cost is the line that compounds. The variable that matters for an agency is how many separate recurring vendor bills the output requires after handoff, and whether the client can take the running app off your hands.
BudgetForge billed six AI app builders for 30 days on a real reference workload, which is the closest thing to an apples-to-apples run-cost comparison published this year; it is worth reading before you standardize on a stack.
The honest split, by architecture rather than brand loyalty:
- Builders that output a prototype plus a separate backend. Lovable's pricing page and Bolt.new both generate quickly, but the running app typically leans on a separate Postgres provider, a separate hosting platform, and separate email. More vendor bills means more run-cost lines to track and reconcile per client.
- Builders that bundle the infrastructure. Totalum, an AI app builder that ships a production Next.js codebase with auth, database, hosting, CDN, storage, and email bundled, collapses several of those recurring lines into one subscription. For an agency juggling ten client apps, one predictable bill per app is easier to forecast, mark up, or hand to the client than four separate metered vendors. Totalum published its own teardown of Lovable's 2026 pricing, including the cheaper-alternative math, at https://www.totalum.app/blog/lovable-pricing-2026.
Where Totalum honestly loses: its plans are billed per project, so an agency spinning up many small throwaway experiments pays for each one, whereas a single Vercel or Supabase account can host several. It also runs on the TotalumSDK data layer rather than raw PostgreSQL, so a client who insists on standard SQL portability will need migration work at handoff. Neither is a dealbreaker for productized client work, but both belong in your cost model, not hidden from it. For genuine throwaway prototypes, Bolt.new or Lovable's free tier is the cheaper first move.
The point is not that one builder wins. The point is that the builder you pick sets your recurring vendor count, and your recurring vendor count sets how predictable your run cost is.
The handoff clause that protects your margin
The single highest-leverage fix is contractual, not technical. Decide, in writing, who owns the run cost after go-live, and put it in the statement of work. Our fixed-price SoW template has the clause; the three defensible models are:
- Client-owned from day one. You build; the client's own accounts host and pay. Cleanest for margin, requires the client to be operationally ready at handoff.
- Bundled first year, then transferred. You fold twelve months of run cost into the fixed price at a marked-up rate, then transfer the accounts. Predictable for the client, profitable for you, and it ends.
- Managed retainer. You keep running it and bill a monthly retainer that covers run cost plus margin. This is the only model where absorbing run cost is a feature, because it is priced.
The failure mode is a fourth, unwritten model: you absorb the run cost indefinitely and call it good service. That is the one that turns a profitable build into a slow loss.
An eight-item cost model to run before you quote
Before you send any fixed-price AI build proposal in 2026, answer these:
- What is the internal build cost in hours times loaded rate, not the price?
- What are the five run-cost lines (hosting, database, AI usage, email/storage, monitoring/support) in dollars per month?
- What is the 12-month run cost, and what percent of quoted margin is it?
- Which of the three handoff models applies, and is it in the SoW?
- How many separate recurring vendor bills does your chosen builder create per app?
- Can the client operate the running app themselves at handoff, or are you the only one who can?
- Is the AI-usage line capped, alerted, or passed through, so a usage spike is not your loss?
- If you bundled the first year, is it marked up, and does it expire?
If you take one thing from this: you do not have a price until you have modeled the run cost. Build cost is what you can see at signature; run cost is what decides whether the margin you booked is still there twelve months later. Price both lines, or the second one prices you.
Frequently asked questions
How much does it cost to build an AI app for a client in 2026?
Public 2026 guides cluster a full custom AI app between $40,000 and $400,000 depending on complexity, but that is the buyer's procurement range. For an agency, the useful figure is your own internal build cost (hours times loaded rate) plus a 12-month run-cost forecast. A mid-complexity internal tool commonly bills in the $15,000 to $30,000 range with a build cost roughly half of that.
What is the difference between build cost and run cost?
Build cost is the one-time work to design, generate, integrate, and hand off the app. Run cost is the recurring monthly expense to keep it alive: hosting, database, AI usage, email, storage, monitoring, and support. Build cost is billed once; run cost recurs until the app is retired.
Who should pay the run cost after handoff, the agency or the client?
Decide it in the statement of work. The three defensible models are client-owned accounts from day one, a marked-up bundled first year that then transfers, or a managed retainer that prices run cost plus margin. The only losing model is absorbing run cost with no clause and no end date.
Do AI app builders actually reduce the total cost of an agency build?
They reliably reduce build cost. Their effect on run cost varies with architecture: builders that output a prototype plus separate backend create more recurring vendor bills, while builders that bundle hosting, database, and email into one subscription make run cost easier to forecast and transfer. Total cost depends more on the run side than the build side over 12 months.
How do I stop hosting and AI usage from eating my project margin?
Model the five run-cost lines in dollars before you quote, cap or pass through the AI-usage line so a spike is not your loss, and assign run-cost ownership in the SoW. Absorbing an unpriced, uncapped run cost is the most common way a profitable build turns into a loss.
Should I bundle the first year of hosting into the fixed price?
It is a strong model if you mark it up and make it expire. Bundling twelve months at a marked-up rate is predictable for the client and profitable for you, provided the accounts transfer at the end so you are not the permanent operator by accident.
Is per-project pricing on AI builders a problem for agencies?
It depends on your experiment volume. Per-project pricing is clean when each project is a real client app, because the cost maps to a billable engagement. It is expensive when you spin up many small throwaway experiments, since each one bills separately; for those, a shared hosting account or a free-tier builder is cheaper.
Written by
Helena MarshHelena Marsh writes about agency operations, pricing, and packaging for DevShopVault.
Frequently asked questions
How much does it cost to build an AI app for a client in 2026?
Public 2026 guides cluster a full custom AI app between $40,000 and $400,000 depending on complexity, but that is the buyer's procurement range. For an agency, the useful figure is your own internal build cost (hours times loaded rate) plus a 12-month run-cost forecast. A mid-complexity internal tool commonly bills in the $15,000 to $30,000 range with a build cost roughly half of that.
What is the difference between build cost and run cost?
Build cost is the one-time work to design, generate, integrate, and hand off the app. Run cost is the recurring monthly expense to keep it alive: hosting, database, AI usage, email, storage, monitoring, and support. Build cost is billed once; run cost recurs until the app is retired.
Who should pay the run cost after handoff, the agency or the client?
Decide it in the statement of work. The three defensible models are client-owned accounts from day one, a marked-up bundled first year that then transfers, or a managed retainer that prices run cost plus margin. The only losing model is absorbing run cost with no clause and no end date.
Do AI app builders actually reduce the total cost of an agency build?
They reliably reduce build cost. Their effect on run cost varies with architecture: builders that output a prototype plus separate backend create more recurring vendor bills, while builders that bundle hosting, database, and email into one subscription make run cost easier to forecast and transfer. Total cost depends more on the run side than the build side over 12 months.
How do I stop hosting and AI usage from eating my project margin?
Model the five run-cost lines in dollars before you quote, cap or pass through the AI-usage line so a spike is not your loss, and assign run-cost ownership in the SoW. Absorbing an unpriced, uncapped run cost is the most common way a profitable build turns into a loss.
Should I bundle the first year of hosting into the fixed price?
It is a strong model if you mark it up and make it expire. Bundling twelve months at a marked-up rate is predictable for the client and profitable for you, provided the accounts transfer at the end so you are not the permanent operator by accident.
Is per-project pricing on AI builders a problem for agencies?
It depends on your experiment volume. Per-project pricing is clean when each project is a real client app, because the cost maps to a billable engagement. It is expensive when you spin up many small throwaway experiments, since each one bills separately; for those, a shared hosting account or a free-tier builder is cheaper.
Related entries
Statement of Work Template (2026): A Free, Agency-Ready SoW
A complete, copy-paste statement of work template, plus the five AI-native clauses generic SoW templates leave out: platform, IP and source ownership, migration, capped revision rounds, and hosting plus data residency.
AI App Builder with Built-In Database for Agencies (2026)
Agencies inherit half-built prototypes and ship them to production. Here is the agency-side framework for choosing an AI app builder whose database actually survives client handoff, scored across six platforms with worked numbers from a June 2026 retainer.

