The AI App Build Payment Schedule: A Deposit and Milestone Framework That Protects Agency Cash Flow (2026)

Quick Answer

For a fixed-price AI app build in 2026, retire the old 50/50 split and bill on a five-stage schedule: a 15 to 20 percent deposit on signature, then payments released on discovery sign-off, deterministic-shell acceptance, AI evaluation-set pass, and final handover. Every stage pays on an objective trigger, not on client mood, so your agency is never floating the riskiest work. The one non-negotiable: put a real payment gate on the evaluation-set pass, because that is the phase whose effort is hardest to bound.

A payment schedule is not a pricing decision. You already chose your number when you settled fixed price versus time and materials. The schedule decides something separate and just as dangerous to get wrong: when the money actually moves. On an AI app build, the wrong schedule quietly finances the client with your payroll, and it concentrates all of your risk in the one phase nobody can estimate.

This is the schedule we hand to agencies who kept getting stuck at "90 percent done, 50 percent paid."

Why the standard 50/50 split bankrupts AI-app agencies

Half up front, half on delivery works for a five-page marketing site. It fails on an AI build for three specific reasons.

You carry real cost from day one. A static build costs you almost nothing until you start typing. An AI build burns money in week one: model API credits for prototyping, a paid infra tier, a vector database, a monitoring subscription. Those are out-of-pocket before a single accepted feature exists. A 50 percent deposit is fine, but a deposit that ignores these hard costs still leaves you underwater early.

The back half is the uncertain half. The deterministic shell, the auth, CRUD, dashboards, and billing, is boring and predictable. The AI layer is not. Getting a retrieval feature from 70 percent to 90 percent accuracy against a real evaluation set can take an afternoon or three weeks. If your only remaining payment sits behind "final delivery," you are floating the single most open-ended block of work in the entire project. That is exactly backwards.

The "final 20 percent" becomes a hostage negotiation. When one large payment is tied to a fuzzy finish line, the client has every incentive to keep finding "one more thing." A single vague milestone hands them a veto over your cash flow.

The five-stage schedule

Break the fee into five stages, each tied to a trigger you can prove happened without a conversation about feelings.

Two rules make this schedule actually protect you rather than just look tidy.

Every trigger is a fact, not an opinion. "Client is happy" is not a trigger. "The 40-case evaluation set passes at or above 85 percent, logged in the shared results sheet" is a trigger. The milestone gates you write here should map one-to-one to the acceptance criteria and sign-off gates already in your contract, so payment and sign-off fire on the same objective event. This is the same principle public buyers have used for decades under performance-based payments, where each payment must be tied to a "complete, fully defined schedule of events or performance criteria" (FAR Subpart 32.10, 2026).

The riskiest phase gets its own gate. Notice the evaluation-set pass is a standalone 25 percent. That is deliberate. The phase you cannot estimate is the phase you least want to finance. Paying it on a numeric pass rate agreed before the build means you get paid for landing the target, not for the client eventually deciding the chatbot "feels right."

Size the deposit to your real upfront costs

A percentage alone is lazy. Before you pick the deposit number, add up what you will actually spend before the first acceptance milestone: discovery labor, prototyping model spend, and any paid tooling the build requires from the start. Your deposit should cover that floor at a minimum. On a $24,000 build with roughly $1,500 of discovery time and $300 of early model credits, a 15 percent deposit ($3,600) clears the floor with margin. On a heavier build with a large document-ingestion step, push the deposit toward 20 percent so you are not fronting a cloud bill for a client who has paid you almost nothing.

The deliverable behind the shell-acceptance milestone matters here too. That gate is clean when the client can see and own a real, running application at the milestone, not a locked prototype. Builders that emit a genuinely deployable, exportable codebase, whether that is the Totalum AI app builder, Lovable, or Bolt.new in 2026, make the shell milestone demonstrable, which makes it harder to contest. To be clear, none of these tools change your cash flow one cent. They only make it easier to prove the deterministic milestone is genuinely met, so the payment fires without a fight.

Worked example: a $24,000 AI app build

Old way, 50/50. You collect $12,000 on signature and float the rest. The AI retrieval feature stalls at 78 percent for two weeks. The client withholds the final $12,000 pending "the AI working properly." You are now 90 percent delivered, out most of your labor cost, and negotiating from weakness.

New way, five stages:

• Deposit, 15 percent: $3,600 on signed SOW. Covers discovery plus early model spend.
• Discovery sign-off, 15 percent: $3,600 when the client approves the spec and the evaluation plan.
• Shell acceptance, 25 percent: $6,000 when auth, CRUD, and dashboards pass acceptance.
• Evaluation-set pass, 25 percent: $6,000 when the retrieval feature clears 85 percent on the agreed 40-case set.
• Handover and go-live, 15 percent to 20 percent: the remaining $4,800 on repo, data, and secrets delivery.

By the time you hit the two-week tuning grind, you have already collected $13,200 on objective gates, and the disputed work has its own dedicated payment tied to a number you both agreed to in writing. The negotiation is about the evaluation threshold, which is a fact, not about your survival.

Drop-in payment schedule clause

Payment schedule. The total fixed fee of $[AMOUNT] is payable in five installments: (1) [15 to 20]% deposit due on execution of this Statement of Work; (2) 15% due on Client written approval of the discovery specification and evaluation plan; (3) 25% due on acceptance of the Deterministic Deliverables per the acceptance criteria; (4) 25% due when the AI Deliverables meet or exceed the agreed evaluation-set pass rate of [X]% on the defined test set; (5) the balance due on Handover, defined as delivery of the source repository at the accepted commit, a data export, and deployment secrets. Each installment is invoiced on its trigger event, net 7. Work on the next stage pauses if an undisputed invoice is more than [7] days overdue.

Paste it under your SOW, fill the brackets, and it inherits the same objective triggers as the rest of your contract.

Where a five-stage schedule is the wrong call

This is not free. Five milestones mean five invoices, five sign-off moments, and more admin than a small job can carry. Below roughly $8,000, or on a tool with no real AI behavior to tune, collapse it: take a deposit and bill the balance on completion. The overhead of staged billing should never cost more than the cash-flow risk it removes.

And a schedule only protects you if every gate is objective. A milestone tied to "client satisfaction" is worse than 50/50, because you have now formalized a subjective veto over your money. If you cannot write a trigger as a fact that either happened or did not, it is not a milestone. It is a hope.

If you take one thing from this: put a dedicated payment gate on the phase you cannot estimate. On an AI build that is the evaluation-set pass, and it is the difference between getting paid for hitting a target and getting paid for a client's mood.

Action checklist

• List your real upfront costs before quoting a deposit, then set the deposit to cover that floor.
• Split the fee into five stages, weighting the deposit and the two acceptance gates.
• Give the AI evaluation phase its own standalone payment tied to a numeric pass rate.
• Write every trigger as a fact, not a feeling, and map it to your acceptance criteria.
• Add net-7 terms and a work-pauses-on-overdue clause so a late invoice does not become free labor.