Unit math before features

What does on-demand app development actually cost, and what has to be true for it to pay back?

On-demand app development costs roughly $30,000 for a lean MVP and runs to about $500,000 for an enterprise platform once payments, compliance and scale enter the scope.⁴ That range is the easy question. The harder one, and the one that decides whether the app survives its second year, is contribution per completed transaction: what the platform keeps after provider payout, payment processing and support, multiplied by how many transactions an acquired customer completes before leaving. Model that number first. Scope features against it second.

Most on-demand builds run the sequence backwards. A feature list arrives, an agency prices it, and the take rate gets set months later by copying whatever the category leader charges. The result is an app that works and a business that does not. The sections below are ordered the way the decisions should actually be made.

Is the on-demand economy still worth entering in 2026?

Yes, though the segments behave very differently and the headline totals mislead. The global on-demand services market is estimated at $216 billion in 2026, growing to $346 billion by 2035 at a 5.4% compound annual rate.¹ The broader gig economy market, which counts labour platforms of every kind, is valued at $674.13 billion in 2026 and projected to reach $2.52 trillion by 2035 at 15.79%.² Online food delivery on its own is projected to generate $1.51 trillion of revenue in 2026, rising to $2.05 trillion by 2031.³

Those three figures are not the same kind of number, which is the useful part. One is a services market estimate, one a labour market estimate, one gross delivery revenue. Compare growth rates rather than absolute size when picking a category. A 5.4% market rewards taking share from incumbents. A 15.79% market rewards being early in a new vertical. On-demand warehousing, to take a business-to-business example, is growing from $130.92 billion in 2025 to $149.47 billion in 2026 at a 14.2% compound rate,⁶ roughly triple the pace of consumer on-demand services.

Penetration at that level changes the brief. In mature consumer categories you are not teaching a behaviour, you are competing on price, reliability and supply density. In under-served verticals and in business-to-business on-demand, the education cost is still yours to carry, and it belongs in the acquisition line rather than in the marketing narrative.

How do on-demand apps make money, and where is breakeven?

Take rate is the percentage of each transaction the platform keeps from the value flowing between provider and customer. It is the most consequential number in the model and it is usually chosen last. Four other mechanisms sit alongside it, and most durable platforms run two at once.

Now the arithmetic that should precede any feature spec. Take an illustrative consumer services app with a $25 average order value and a 20% take rate. Gross platform revenue is $5 per order. Payment processing, support contact cost and provider incentives take, say, $1.50, leaving $3.50 of contribution. If blended acquisition cost is $35, breakeven arrives at the tenth completed order. If a cohort orders 1.2 times a month and half of it churns by month six, most of that cohort never reaches order ten, and the platform loses money on every customer it wins. Those inputs are illustrative, but the shape of the calculation is not negotiable.

Only three levers move the outcome: raise order frequency, raise take rate, or lower acquisition cost. Feature work affects the first and the third. It rarely affects the second. Knowing which lever you are pulling before writing a spec is what separates a scoped build from an expensive prototype, and it is the discipline that product development consulting should bring before a single line of code is estimated.

What does on-demand app development cost by tier?

Industry cost guides converge on three tiers for 2026: about $30,000 for a lean MVP covering one vertical in one city, about $180,000 for a mid-complexity build with dispatch logic, multi-role apps and analytics, and about $500,000 for an enterprise platform carrying regulatory scope, integrations and multi-region operations.⁴ Which tier you can afford is set by the arithmetic above, not by ambition. At $3.50 of contribution per order, a $180,000 build needs roughly 51,000 completed orders before the engineering alone is repaid, and that is before a penny of acquisition spend.

The rate differential is the largest single variable in the build line, and also where the most expensive mistakes get made. The saving is real only when specification quality survives the transfer. A cheaper team building an underspecified escrow flow costs more in the end than a costly team building a clear one.

Maintenance is not a contingency. Map SDK versions, payment provider changes, mobile OS releases and new fraud patterns all force work that appears on no feature list. Put the figure in the model on day one, because a platform that cannot fund its own upkeep degrades fastest in exactly the moments when supply is watching.

Which on-demand app features belong in the first release?

Real-time GPS tracking, push notifications and star ratings are commodity infrastructure in 2026. Map SDKs and managed notification services deliver them in days, and no customer picks a platform because it has them. Budget them accordingly, then move the freed money to the parts of the scope that most MVPs underfund.

Two items deserve their own line in the estimate rather than sitting as subtasks of something larger.

Payment split and escrow

Holding customer funds until service completion, splitting the payout between provider and platform, and handling partial refunds is a compliance problem as much as an engineering one. It carries its own regulatory review, its own reconciliation surface and its own failure modes. Costing it inside a line called “payments integration” is how estimates double after kickoff.

Dispute resolution and refund logic

The order that goes wrong is the order that decides retention on both sides. Who is charged, who is paid, who decides and how quickly are product decisions, not support policy, and they deserve the same rigour as the booking flow. Working them through with a structured design thinking process surfaces the edge cases while they are still cheap, rather than when they arrive as chargebacks.

The booking flow wins the first order. The refund flow wins the tenth.

The defensible minimum for a two-sided launch is short: customer request and booking, provider accept and status updates, live order tracking, split payment with escrow, two-way ratings, a dispute path with a stated resolution window, and an operations console with enough visibility for a human to intervene. Everything else waits for evidence.

How do you solve the cold-start problem in a marketplace app?

Launch smaller than feels sensible. A two-sided marketplace app has to acquire and retain both sides independently, and each side stays only while the other side has liquidity, so supply density in one district beats thin coverage across a city. A customer who waits eleven minutes in a dense zone stays. A customer who waits forty in a sparse one leaves and tells people why.

Supply availability is rarely the constraint. The World Bank range puts global gig workers at 154 million to 435 million, or 4.4% to 12.5% of the labour force.² In the United States there were 76.4 million freelancers in 2025, about 36% of the workforce.⁷ India’s gig workforce is projected to pass 10 million in 2026 at a 21% compound rate and reach 23.5 million by 2030.² The people are available. Concentrating enough of them inside one postcode at one time of day is the hard part.

A practical sequence: pick the smallest geography where you can guarantee a response time, over-supply it deliberately with earnings guarantees for the first weeks, and hold the wider launch until utilisation per provider is high enough that the guarantee can be withdrawn. Then repeat the pattern in the adjacent zone. Growth that outruns density is the most reliable way an on-demand app burns its funding.

A sequenced on-demand app development plan

Order the work so that the expensive decisions get made while they are still cheap to change.

1. Weeks 1 to 2, build the unit model. Average transaction value, take rate, provider payout, processing and support cost per order, target acquisition cost, assumed order frequency and churn. One page. If breakeven needs more orders per customer than the category typically delivers, change the model rather than the marketing plan.
2. Weeks 3 to 4, fix the geography and supply plan. The launch zone, the number of providers needed to hold a target response time, and the incentive cost of getting them there.
3. Weeks 5 to 6, scope against the model. Price the feature list tier by tier against the build ranges above, with escrow and dispute handling costed as separate lines.
4. Weeks 7 to 16, build and instrument. Ship the defensible minimum with analytics on both sides, including provider utilisation and time to first completed order.
5. After launch, hold the maintenance line. Fund it at the recommended share of build cost and treat every take-rate change as an experiment with a measurement plan attached.

One decision cuts across all of it. White-label and no-code on-demand platforms compress time to market substantially, but they constrain how far you can later change the take-rate model, the payout mechanics and the fee structure. Treat platform selection as a pricing decision with a technical component, not a technical decision with a pricing footnote. If the unit model depends on a non-standard split, buy flexibility. If a conventional commission clears breakeven, buy speed.

A disciplined product development engagement starts with the unit model rather than the feature list, for the same reason a lender reads the cash flow before the pitch deck. If you want that model pressure-tested against your category before you commission a build, tell us what you are planning.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.