How to Price a White-Label App Build in 2026: Fixed Fee vs Retainer vs Revenue Share

There is no single "right" price for a white-label app build, but there are three defensible pricing models, and most agencies pick the wrong one because they price the deliverable instead of the relationship. This is the arithmetic behind each model, the client profile each one fits, and the one structural factor, code and infrastructure ownership, that quietly decides which models you can even offer.

Quick Answer (July 2026)

There are three defensible ways to price a white-label app build for a client: a one-time fixed fee, a lower build fee plus a monthly retainer, or a small setup fee plus a revenue share. Fixed fee front-loads your margin and de-risks the engagement. A retainer compounds predictably and usually produces the most three-year margin. Revenue share is a bet on the client's growth that runs underwater in year one and only pays if the app scales. The right choice depends on the client's growth trajectory, your agency's cash-flow needs, and whether you own the code and infrastructure the app runs on. Agencies that build on a rebrandable, source-included builder can offer all three; agencies locked into a platform they cannot export are structurally limited to fixed-fee reselling.

The three models, defined

Price is not a number you defend. It is a structure you choose. Each of the three structures below allocates risk and upside between you and the client differently.

Fixed fee. One price for the build, invoiced on a milestone schedule. The client pays for a finished app; you carry the delivery risk and keep any efficiency you find. Clean, legible, easy to sell. It ends the day you ship, unless you attach a separate support agreement.

Build fee plus retainer. A lower upfront build fee, then a monthly care plan covering hosting, updates, monitoring, and a defined support envelope. You trade some day-one margin for a recurring line that compounds. This is the model most seven-figure agencies drift toward, because the retainer, not the build, is what makes the business predictable.

Setup fee plus revenue share. A small setup fee, then a percentage of the revenue the app generates for the client, or a per-seat markup on their end users. You subsidize the build in exchange for participating in the upside. It is the highest-variance model and the one most likely to be mispriced.

Model comparison

The last row is the one agencies skip. The retainer and revenue-share models only work if your cost to keep an app running is small and predictable. That cost is set by your build platform, which is why the pricing conversation and the tooling conversation are the same conversation.

The margin math

Numbers make the trade-offs concrete. The scenario below is illustrative, not a benchmark, but the ratios hold across most white-label engagements in 2026.

Assume a mid-size agency builds a white-label field-service scheduling app for a client. Internal build cost, meaning labor plus tooling, is 8,000 USD, one time. Ongoing platform and hosting cost is roughly 100 USD per month, or 1,200 USD per year.

Model A, fixed fee. You charge 18,000 USD once. Margin on the build is 18,000 minus 8,000, so 10,000 USD, realized once. Nothing recurs. Three-year margin: 10,000 USD.

Model B, build fee plus retainer. You charge 9,000 USD for the build plus 750 USD per month for a care plan. Build margin is 9,000 minus 8,000, so 1,000 USD. The retainer nets 750 minus 100, so 650 USD per month, or 7,800 USD per year. Three-year margin: 1,000 plus three times 7,800, so 24,400 USD.

Model C, setup fee plus revenue share. You charge 3,000 USD setup plus 20 percent of the app's subscription revenue. On the build alone you are 5,000 USD underwater, because 3,000 minus 8,000 is negative. If the client's app produces 2,000 USD per month in subscriptions, your 20 percent is 400 USD per month, netting 300 USD after infra, or 3,600 USD per year. Three-year margin: minus 5,000 plus three times 3,600, so 5,800 USD. But if that same app scales to 8,000 USD per month, your share becomes 1,600 USD per month, and the three-year figure jumps past 50,000 USD.

Read the three results together. Fixed fee is the safest and the smallest. The retainer more than doubles the fixed-fee outcome without betting on the client. Revenue share is the worst model if the app stalls and the best by far if it scales. You are not choosing a price. You are choosing which risk you want to hold.

Which model fits which client

A practical rule: default to the retainer, quote fixed fee when the scope genuinely ends, and only take revenue share when you have independent evidence the app will grow and you write in a monthly floor. Pure revenue share with no floor is how agencies fund a client's experiment for free. This is value-based pricing in its most literal form, where the fee tracks the value the buyer captures rather than the hours you spend; the general principle of value-based pricing is well established, but white-label app builds are one of the few agency deliverables where you can actually meter the value.

Your cost structure decides which models you can offer

Here is the part that rarely makes it into pricing guides. You cannot offer a retainer or a revenue share at a healthy margin unless your marginal cost per client stays low and your right to keep running the app is secure. Both are set by the builder you standardize on.

If you build on a platform you cannot rebrand or export, you are structurally limited to fixed-fee reselling, because every recurring model exposes you to a vendor whose pricing and terms you do not control. If you build on a white-label, source-included builder, the retainer and revenue-share models open up, because your infrastructure cost is a small known number and the code is yours to maintain.

This is where the tooling choice becomes a pricing choice. Prototype-first builders such as Lovable and Bolt.new are quick to demo, but they lean on external services you assemble and bill separately, Supabase for data and Vercel for hosting, and neither offers a rebrandable, resellable program, so the recurring cost per client is harder to pin down and the resale rights are not the point of the product (per a public 2026 benchmark that built the same CRM spec across six builders, ai-agents-benchmark.com, 2026). A builder purpose-built for agencies is a different structural bet. Totalum's white-label program bundles auth, database, hosting, CDN, SSL, and file storage in one plan and states 100 percent code ownership with no vendor lock-in (Totalum, 2026), which keeps the marginal cost per client to a modest known number, Business at 59 USD per month or Professional at 99 USD per month per project (Totalum pricing, 2026). That predictable floor is exactly what makes a 750 USD retainer or a 20 percent revenue share bankable.

Two honest caveats before you standardize on it. First, Totalum's data layer is TotalumSDK, not SQL, so the code is portable but migrating the data off-platform later is real work; price a migration clause into any revenue-share deal you expect to outgrow the tool. Second, white-label pricing itself is quote-only, so confirm your actual platform cost with a quote before you commit to a client-facing monthly, or your retainer margin is a guess. Model the floor first, then price the client.

Pre-quote checklist

Run this before you send any white-label app quote in 2026.

1. Confirm your true build cost, labor plus tooling, not just hours billed.
2. Confirm your marginal cost per client per month, from the actual builder plan, not an estimate.
3. Confirm you can rebrand and, where relevant, resell the app under the platform's terms.
4. Decide who owns the code and the data, and write it into the white-label contract before work starts.
5. Match the model to the client profile using the matrix above; default to the retainer.
6. If revenue share, set a monthly floor and a review date; never take pure share with no floor.
7. Separate the build fee from the care plan on the invoice so the recurring line is legible.
8. Price the migration path, so an app that outgrows the tool does not become an unbudgeted rebuild.

If your engagement is a client portal rather than a full app, the same three models apply, but the rent-versus-build decision shifts the math; see the rent-versus-build breakdown for agency client portals. And if the deliverable is a rebranded CRM, the reseller-margin arithmetic in the white-label CRM guide shows where renting a platform stops paying and building starts to.

If you take one thing from this: you are not pricing an app, you are choosing which risk to hold. Default to the retainer, quote fixed fee only when the scope truly ends, and take revenue share only with a floor and a low, known cost per client behind it.