On-demand Home Services App Development Cost and Features

TL;DR:

An on-demand home services app connects customers who need cleaning, plumbing, electrical work, salon visits or appliance repair with vetted providers who can arrive the same day or on a booked slot. A working platform is three products rather than one: a customer app, a provider app and an admin panel. A single-city MVP costs roughly USD 18,000 to 28,000 and ships in 10 to 14 weeks, while a full multi-city build with AI matching and dynamic pricing runs from USD 80,000 upward. The feature list is the easy part. On the on-demand and marketplace platforms Aalpha Information Systems has built, what decides whether the business works is supply liquidity, provider retention and stopping customers and providers from transacting off-platform.

What is an on-demand home services app?

An on-demand home services app is a marketplace where a customer selects a service, picks a time slot, is matched with a nearby provider, tracks that provider’s arrival and pays inside the app. The platform earns a commission or fee on each completed job. TaskRabbit, Thumbtack, Angi and Urban Company all run variations of this model.

The distinction that matters commercially is how much of the service the platform controls. A listing directory hands you a phone number and steps back. A full-stack platform recruits the provider, trains them, sets the price, guarantees the outcome and handles the refund when something goes wrong. The second model is far more expensive to operate and is the one that holds its take rate.

Which business model should you choose?

Four models dominate. Each changes what you build, so this decision comes before any feature list.

Lead generation is the simplest. A customer posts a job, providers pay to quote on it, and the platform never touches scheduling or payment. Revenue arrives per lead rather than per completed job, and it is the cheapest of the four to build.

An open marketplace goes further. Providers set their own prices, customers choose from profiles, and the platform takes somewhere in the region of 10% to 20% of each booking. A full-stack managed platform sets the price itself, recruits and trains the providers and stands behind the work, which is what supports take rates of 20% to 30% and also makes it the most expensive of the four to build by a wide margin. A single-service vertical, cleaning only or appliance repair only, sits between the two on both cost and take rate, usually 15% to 25%, because depth in one category strips out most of the catalogue and dispatch complexity.

The lead-generation model is the cheapest to launch because you never handle payment, scheduling or quality. It is also the least defensible. Providers churn as soon as lead quality drops, and customers have no reason to return to your app rather than call the plumber directly next time.

The full-stack model is where most of the durable value has been created. Urban Company charges partners in the region of 20% to 30% per booking depending on category and order value, according to its own partner communications and subsequent financial reporting. That rate is only sustainable because the platform supplies training, tools, insurance and demand. You cannot charge it while running a directory.

A single-service vertical is the right starting point for most new entrants. One category, one city, one provider pool. Expand after utilisation is proven.

What does the market actually look like?

Analyst estimates for the online on-demand home services segment diverge sharply, so treat any single figure with caution. Straits Research put the global market at USD 5.15 billion in 2024, growing to USD 19.65 billion by 2033 at a 16.04% CAGR. Market Research Future gives a similar base, USD 4.28 billion in 2024, reaching USD 22.3 billion by 2035 at 16.2%. Other firms publish numbers an order of magnitude higher because they count the entire offline home services economy, including every independent plumber and cleaner who has never used an app.

The useful reading is the ratio, not the absolute number. Online penetration of home services is still in the single digits in most markets. The addressable offline spend in the United States alone was around USD 97 billion in 2025 by Expert Market Research’s estimate. The opportunity is conversion of offline demand, not creation of new demand.

Why does a home services platform need three apps, not one?

Most cost overruns on these projects come from scoping only the customer app. A booking has three parties, and each needs its own interface. Skipping the provider app forces your operations team to phone providers manually, which caps you at a few hundred bookings a month.

• Customer app

Service catalogue with category pages, transparent pricing or instant quotes, address book with saved locations, slot selection, provider profile with ratings, live tracking on job day, in-app chat, payment and tipping, booking history, repeat-booking shortcut, cancellation and rescheduling, support and refund requests.

• Service provider app

This is where new platforms underinvest. A provider app needs onboarding with document upload, background verification status, skill and category selection, service radius, availability calendar, job alerts with accept or decline within a countdown, navigation handoff, job checklist and photo proof of completion, part and consumable logging, earnings dashboard with a per-job breakdown, payout history, penalty and rating visibility, and a training or certification module if you run a managed model.

Providers abandon platforms that make earnings opaque. Showing net earnings after commission, per job, on the same screen as the job list removes the single biggest source of provider disputes.

• Admin panel

Provider approval queue with document review, category and subcategory management, pricing and surge rules by city and slot, commission configuration by category and provider tier, booking monitoring with manual reassignment, dispute and refund handling, payout runs and reconciliation, promo and referral management, content management for the catalogue, and reporting across bookings, GMV, fill rate and provider utilisation.

The admin panel is typically 15% to 20% of total build effort and is the part clients most often try to cut. Cutting it moves the work to humans in spreadsheets, where it costs more every month forever.

Which features do customers expect in 2026?

Baseline expectations have moved since the first wave of these apps. The list below separates what customers now assume from what still differentiates.

Assumed as standard: upfront pricing before booking, same-day or next-day slots, provider identity and rating visible before arrival, live ETA, in-app payment, one-tap rebooking of a previous provider, and a refund path that does not require a phone call.

Still differentiating: photo-based quoting, where the customer uploads an image of the leaking tap or the room to be cleaned and receives a priced scope in under a minute. Subscription plans for recurring services, which lift repeat rate more than any discount campaign. Provider preference, letting a customer request the same person again and paying a small premium for it. Service guarantees with a defined remedy, for example a free revisit within 48 hours.

The single feature most worth building early is the repeat-booking shortcut. Acquisition cost in this category is high, and the second booking from an existing customer is where the unit economics turn.

Which AI features are worth building now?

AI belongs in three places on a home services platform: matching, pricing and support. Everything else is currently a distraction.

Matching decides which provider gets which job. A rules engine using distance and availability works at low volume. Above a few thousand bookings a month, a model that weighs provider rating in that specific category, historical completion time, cancellation history, travel time under live traffic and current utilisation produces measurably better fill rates. The downside is that it needs booking history to train on, so it is a phase-two build, not a launch feature.

Dynamic pricing raises slot prices at peak demand and discounts empty weekday mornings. It improves provider earnings and smooths supply. It also generates customer complaints, so it needs a visible cap and an explanation in the UI.

AI support handles the rescheduling, refund status and booking change queries that make up the bulk of tickets. Scoped to those three intents and with a clean handoff to a human, it removes real cost. Scoped as a general chatbot, it annoys people.

Photo-based scoping is the most interesting current application. A vision model reads a customer photo, identifies the likely job and returns an estimated duration and price band for a human to confirm. It shortens the path from intent to booking, which is where most drop-off happens. Aalpha builds these as part of its AI agent services work, usually after a platform has enough historical job data to validate the estimates against actual outcomes.

Demand forecasting is worth building only once you operate in more than one city. Before that, your operations lead can predict next week from a spreadsheet.

What technology stack fits an on-demand home services app?

On mobile, Flutter or React Native covers the customer and provider apps across iOS and Android from a single codebase. The cost of that is background location tracking, which is less reliable on cross-platform than on native and needs platform-specific work whichever framework you pick.

For the backend, Node.js with NestJS or Python with Django both handle the event-driven booking and dispatch flow well. Node needs discipline around long-running jobs, because dispatch retries and payout runs will otherwise end up blocking request threads.

PostgreSQL with the PostGIS extension is the database choice here, over MongoDB, without hesitation. Commissions, payouts, refunds and tax reporting are relational problems, PostGIS handles provider radius queries natively, and the denormalisation shortcut becomes a reconciliation problem around month four. It does need someone who understands indexing once the bookings table passes a few million rows.

Job alerts, live tracking and chat run over WebSockets or Firebase. Firebase is faster to build on, and its costs climb steeply past moderate volume, so model that bill before committing to it.

Google Maps Platform or Mapbox handles geocoding, routing and ETA. Both bill on usage, which is what catches teams out in month three when the customer app turns out to be polling provider positions every three seconds.

Payments go through Stripe, Razorpay or Adyen depending on market. What matters is not the headline rate but whether the provider supports split payouts to providers, escrow-style holds and refunds in your countries. Validate that in week one, because marketplace payout features vary far more by country than the pricing pages suggest.

Notifications need Firebase Cloud Messaging alongside an SMS provider, since a job alert has to arrive whether or not the provider has the app open. SMS pricing varies tenfold between countries and belongs in your running cost model rather than your build budget.

The admin panel is a React or Next.js web app. It is quick to build and easy to hand over to an operations team, and there is no meaningful trade-off to weigh on that one.

How much does it cost to develop an on-demand home services app?

On-demand home services app development costs between USD 18,000 and USD 150,000 depending on how many of the three apps you build, how many cities you launch in, and where your development team sits. The figures below assume an offshore team at a blended rate of USD 30 per hour and cover design, development, QA and release.

Cost by build tier

The MVP tier is the right choice if you have not yet proven that providers in your city will accept your commission. The trade-off is honest: an MVP built to validate demand usually needs 30% to 40% of its code reworked when you scale it, because the dispatch logic and payout model both change once real volume arrives.

Cost by module

Module estimates for the growth tier, at USD 30 per hour.

Discovery, architecture and the UX flows take 100 to 140 hours, or USD 3,000 to 4,200. UI design across the three interfaces adds another 120 to 180 hours, USD 3,600 to 5,400.

On the customer side, authentication, onboarding and document verification run 80 to 120 hours at USD 2,400 to 3,600. The service catalogue with search and filtering takes 90 to 130 hours, USD 2,700 to 3,900. The booking and scheduling engine is the heaviest customer-facing piece at 140 to 200 hours, USD 4,200 to 6,000. Quotation and pricing rules add 70 to 110 hours, USD 2,100 to 3,300. Payments, wallet, split payouts and refunds come to 110 to 160 hours, USD 3,300 to 4,800. Real-time provider tracking is 70 to 110 hours, USD 2,100 to 3,300. In-app chat with masked calling takes 60 to 100 hours, USD 1,800 to 3,000, and ratings and reviews 40 to 60 hours, USD 1,200 to 1,800.

The provider app, covering job alerts, availability and the earnings dashboard, runs 160 to 240 hours, or USD 4,800 to 7,200. The admin panel is the single largest line item at 180 to 260 hours, USD 5,400 to 7,800. Notifications and messaging infrastructure add 40 to 60 hours, USD 1,200 to 1,800. QA, device testing and store release close it out at 120 to 180 hours, USD 3,600 to 5,400.

Added up, that is 1,380 to 2,050 hours, or USD 41,400 to 61,500.

The booking engine and the admin panel together account for about a quarter of the build. Both are usually underestimated because neither demos well.

Cost by development location

The same scope produces very different invoices depending on where the team sits. Typical 2026 agency rates for mobile and backend engineers:

An Indian team bills USD 25 to 50 an hour, which puts a 1,700 hour growth-tier build at USD 42,500 to 85,000. Eastern Europe runs USD 40 to 75, or USD 68,000 to 127,500 for the same scope. Latin America is close behind at USD 45 to 80, working out to USD 76,500 to 136,000. Western European agencies charge USD 80 to 140, taking that same build to USD 136,000 to 238,000, and United States agencies USD 100 to 180, or USD 170,000 to 306,000.

Rate is not the only variable. A cheaper team that needs 2,400 hours costs more than a stronger team that needs 1,600. Ask any vendor for their hour estimate per module, not just a total, and compare those.

Native versus cross-platform

Building separate native iOS and Android apps for both the customer and provider sides adds roughly 55% to 70% to mobile development hours compared with a single Flutter or React Native codebase. On a growth-tier build that is an extra USD 12,000 to 18,000 at offshore rates.

Cross-platform is the default recommendation for this category with one real caveat. Continuous background location tracking on the provider app behaves differently on iOS and Android, and both platforms have tightened the rules. Budget for native modules on that one feature regardless of framework choice. Our comparison of iOS and Android development covers the wider differences, and the mobile app development cost guide has the underlying rate detail.

What does it cost to run after launch?

Running costs are where first-time founders get caught. Assume 5,000 completed bookings a month in one city.

Payment processing takes 2% to 3% of transaction value plus a fixed fee per transaction. Stripe charges 2.9% plus USD 0.30 on standard US card payments; Razorpay charges 2% on standard Indian transactions. On a USD 40 average order value across 5,000 bookings, that is roughly USD 7,000 to 7,500 a month, which comes out of your take rate, not on top of it.

Maps and geocoding on Google Maps Platform runs a few hundred dollars a month at that volume and scales with how often the customer app refreshes provider positions. Polling every three seconds instead of every ten will triple the bill.

SMS and OTP costs vary enormously by country, from under a cent per message in India to several cents in parts of Europe and Africa. At two or three messages per booking, budget USD 150 to 900 a month.

Cloud hosting for a single-city platform at this volume sits around USD 300 to 900 a month on AWS or Google Cloud. Apple charges USD 99 a year for its developer programme and Google Play charges USD 25 once.

Ongoing maintenance runs 15% to 20% of the original build cost annually. That covers OS updates, dependency upgrades, payment gateway changes and bug fixes, and it is not optional. An app left unmaintained for a year will break on the next iOS release.

Customer support and provider operations are the largest line and rarely appear in development quotes at all. Plan for one operations person per 3,000 to 5,000 monthly bookings until automation catches up.

How long does development take?

A growth-tier build runs 16 to 22 weeks from kickoff to store approval. A realistic phase breakdown:

Discovery and scope definition takes two to three weeks and produces the flows, the dispatch logic and the commission model in writing. Skipping it is the most common cause of the change requests that push projects over budget. Aalpha runs this as a separate product discovery engagement so the scope is fixed before development pricing is agreed.

UX and UI design across three interfaces takes three to four weeks, overlapping with backend architecture.

Core development runs eight to twelve weeks, with the provider app and admin panel built in parallel with the customer app rather than after it.

Testing and field trials take two to three weeks. Field trials matter here more than in most app categories. Put five real providers on the app for a week before launch, because location accuracy, notification delivery and battery drain only surface on real devices in real buildings.

Store submission adds one to two weeks. Apple reviews apps with background location use more closely, so prepare the justification text in advance.

How does an on-demand home services app make money?

Commission per booking is the foundation. Rates sit between 10% and 30%, with the higher end available only to platforms that control quality and supply demand. Set it at launch knowing you will struggle to raise it later; providers react badly to increases and organise against them, as Urban Company found in 2019 when beauty partners protested in Gurugram and the company subsequently cut its top commission slab.

Provider subscriptions replace or supplement commission. Providers pay a monthly fee for leads, visibility or zero-commission jobs. This works well in lead-generation models and badly in managed ones.

Customer memberships charge an annual fee for discounted rates, priority slots or free revisits. These lift repeat rate and prepay your working capital.

Featured placement lets providers pay for position in search results. It generates margin with almost no delivery cost, and it degrades match quality if you let it override rating.

Product and consumable sales are underrated. Urban Company derives roughly a third of its revenue from selling equipment and consumables to its partners, according to its financial disclosures. If your providers need supplies to do the job, you have a second business.

Surge pricing on peak slots adds margin and improves supply at the hours you need it.

How do the big platforms compare?

Urban Company runs the full-stack managed model across India, the UAE, Saudi Arabia and Singapore, earning from commission and from selling equipment and consumables to the partners it trains and equips itself. TaskRabbit operates an open marketplace in the US, UK, Canada and parts of Europe, where Taskers set their own hourly rates and the platform takes a service fee on each booking.

Thumbtack sells leads rather than bookings in the United States, with no booking or payment flow at all in most of its categories. Angi combines lead fees with advertising revenue against a review corpus built over two decades, and it owns Handy, which applies a managed commission model to a narrow cleaning-led category set in the US, UK and Canada.

The pattern is worth noticing. The US market settled on lead generation, the Indian market settled on full-stack. That reflects labour cost and provider fragmentation rather than any superiority of one model. Look at which conditions apply in your market before copying either.

What legal and compliance work is involved?

Worker classification is the first question and it has closed platforms. Whether your providers are independent contractors or employees depends on how much control you exert over pricing, scheduling and methods. The full-stack model that produces the best unit economics is also the model that most resembles employment, and several jurisdictions have legislated on this since 2020. Get local advice before you set your operating model, not after.

Background verification is a customer expectation and in some categories a legal requirement. Identity documents, address verification, criminal record checks where permitted, and trade licences for electrical and gas work. Build the verification status into the provider record and surface it in the customer app.

Insurance covers damage to customer property and injury to providers. Platforms that position themselves as neutral intermediaries still get sued when a technician floods a kitchen.

Payment compliance means PCI DSS if you touch card data, which is the argument for not touching it. Use a hosted gateway and keep card details off your servers. Marketplace payout rules, including KYC on providers receiving funds, vary by country and by gateway.

Data protection obligations follow your users. GDPR applies to EU customers, India’s DPDP Act to Indian ones. Location data collected from providers is a particular sensitivity, and continuous tracking outside working hours is hard to justify under either regime.

What usually goes wrong?

Supply comes first, not demand. A platform with customers and no available providers burns its reputation in the first month. Recruit and verify providers in one postcode before you spend anything on customer acquisition.

Platform leakage is the structural threat. A customer who likes their cleaner will take her number and book directly next month, and your commission disappears. The defences are practical rather than contractual: hold payment guarantees and revisit cover on-platform, make rebooking one tap, mask phone numbers, and give providers a reason to stay that is worth more than the commission they save. Contractual non-circumvention clauses are unenforceable in practice against consumers.

Provider churn runs high in this category. Providers leave when utilisation drops, when penalties feel arbitrary, or when earnings are unclear. Utilisation is the number to manage, and it argues for launching in a small geography with a small provider pool rather than a wide one with a thin pool.

Quality variance destroys the brand faster than anything else. One bad electrician generates refunds, a review, and a churned customer. The managed model exists to solve this and costs what it costs.

Cancellations and no-shows on both sides need a policy on day one, with the money flowing to whoever lost out. Retrofitting a cancellation policy after providers have been burned is much harder than setting one early.

Which numbers should you track after launch?

GMV and take rate together tell you revenue. Track take rate by category, because the blended number hides categories that are losing money.

Fill rate, the share of booking requests matched to a provider within your target window, is the operational health metric. Below 90% you have a supply problem, whatever your total provider count says.

Provider utilisation, jobs per active provider per week, predicts churn better than any survey.

Repeat booking rate at 90 days determines whether the business works. Acquisition cost in this category is high enough that a single-booking customer is almost always unprofitable.

Cancellation rate split by party, customer-initiated against provider-initiated, tells you which side of the marketplace needs attention.

CAC payback in months, measured against contribution margin rather than revenue.

Should you build custom or buy a white-label platform?

White-label home services scripts sell for USD 3,000 to 15,000 and can be live in weeks. For validating whether providers in your city will accept a 20% commission, that is a reasonable spend.

The limits arrive quickly. Commission logic, dispatch rules and payout flows are the parts every platform eventually needs to customise, and they are the parts white-label products hard-code. Source code quality varies wildly, most scripts are built on dated frameworks, and you inherit a codebase no one on your team wrote. Several of our software project rescue engagements have started with a client trying to extend a white-label platform past what it was designed to do.

The decision rule is simple. If your differentiation is the market you serve, buy and validate. If your differentiation is how the platform operates, matching, pricing or provider economics, build. A custom marketplace build costs five to ten times more upfront and is the only option that survives contact with scale.

FAQ

How much does it cost to build an app like Urban Company?

A platform matching Urban Company’s current feature set, including managed supply, training modules, dynamic pricing and multi-city operations, costs USD 80,000 to 150,000 at offshore rates and takes six to nine months. Urban Company’s own version took years and substantial capital to reach that state. A comparable first release, covering one city and two or three categories, is closer to USD 40,000 to 62,000.

Do I need separate apps for customers and service providers?

Yes. The two audiences need opposite things: customers browse and book, providers manage a work queue and their earnings. Some platforms ship a single app with a role toggle to save money at MVP stage, but app store review treats provider-side functionality differently and the combined app becomes unmaintainable within a year.

How long does it take to build an on-demand home services app?

Ten to fourteen weeks for a single-city MVP, sixteen to twenty-two weeks for a full three-app platform, and six to nine months for a multi-city build with AI matching. Add one to two weeks for app store review.

What is the cheapest way to launch?

One city, one service category, a white-label or MVP build, and manual provider dispatch by an operations person for the first few hundred bookings. Automate dispatch only after you know what the manual process actually does.

What team size does a project like this need?

A growth-tier build typically needs one product or business analyst, one designer, two mobile developers, two backend developers, one frontend developer for the admin panel and one QA engineer, working over four to five months. Teams smaller than that stretch the timeline rather than reduce the cost.

What commission rate should I charge?

Between 10% and 30%, set by how much of the service you control. Directory and lead models sit at the lower end. Managed platforms that recruit, train and guarantee providers can sustain 20% to 30%. Set it deliberately at launch, because raising it later reliably triggers provider backlash.

Which is better for this, Flutter or React Native?

Both work. Flutter tends to produce more consistent UI across platforms and better performance on animation-heavy screens. React Native has a deeper library ecosystem and an easier hiring pool. For a home services platform the deciding factor is usually which your team or vendor already knows well, since the location and payments work is the hard part in either.

How do I stop customers and providers from going off-platform?

Keep the things that only the platform can offer on the platform: payment protection, revisit guarantees, dispute resolution and one-tap rebooking. Mask phone numbers during jobs. Give providers enough consistent volume that the commission is cheaper than finding their own customers. Contract clauses do not work.

Can I add AI features later, or should they be in the first build?

Later, in almost every case. AI matching and demand forecasting need historical booking data to be worth anything, and you will not have it at launch. Build the data model so those features can be added, then ship a rules-based dispatch engine first.

Building it

Aalpha has been building marketplace and on-demand platforms since 2008, across 5,500 projects and 55 countries, with ISO 9001:2015 certified delivery processes and a 4.9 out of 5 rating from more than 215 Clutch reviews. Most engagements in this category begin with a two to three week discovery phase that fixes the dispatch logic, commission model and launch geography before a line of code is written, because those three decisions drive most of the cost.

If you are scoping an on-demand home services platform, talk to our team about a fixed-scope estimate, or read through our mobile app development services for how we structure these