Scenario · Marketplaces & consumer apps

What it costs to build an app like Urban Company: a home-services MVP, week by week

The real cost to build an app like Urban Company in 2026: a salon owner's home-services MVP, what got cut, the 8-week build and every running cost.

By Akash Bansal, founding engineerUpdated 4 November 20268 min read

Illustrative scenario. The founder in this story is a composite, not a real client. The process, costs and decisions are drawn from builds I have done; names and business details are invented to show how a build like this typically goes.

Most pages that answer "cost to build an app like Urban Company" are written by agencies selling the build, and they quote between $40,000 and $300,000 or more over four to nine months (Appinventiv, vendor). That range is not wrong. It just prices the whole platform, and nobody needs the whole platform on day one.

I spent 2020 to 2025 as head of technology at Urban Culture, an at-home salon marketplace. We ran four apps (customer, partner, admin console and web) and grew to 500K registered users across six cities. This post walks through how I would scope and build the first version of that kind of business today, through a composite founder, with every running cost priced from the vendors' own pages.

Who the founder is and where she started

Call her Dana. She owns three hair and nail salons in Austin, Texas, with about twenty stylists and technicians. Since 2024 a growing share of her clients, mostly new parents and people booking for weddings, have asked for home visits. She has been handling them by Instagram DM, a shared Google Sheet and Venmo requests.

Her problem is not demand. Home visits already book out on weekends. Her problem is that every home booking costs her manager twenty minutes of back-and-forth, double bookings happen, and she wants to add vetted freelance stylists on top of her own staff. That last part is what turns a booking tool into a marketplace.

Do you even need a custom home services app?

Often you don't. If Dana only wanted to send her own employees to homes, a salon booking tool would cover it. Vagaro, for example, lists $30 a month for one calendar and $10 per extra calendar, with online booking included. Add a travel fee as a service line and you are done. Spend the $20K on marketing instead. The physio clinic booking story makes the same call: keep the booking software and build only what it can't do.

Custom software starts to pay when three things are true at once:

• You have two sides: customers and independent partners you don't employ, who need their own app, their own payouts and their own rules.
• Location drives the booking: which partner can reach which address, in which time slot, given where they were an hour earlier.
• The workflow is your edge: how you vet partners, what kit they carry, how you price by neighborhood. Off-the-shelf tools force you into their workflow.

Dana ticked all three, so the next question was who should build it.

Agency, freelancer, no-code or founding engineer?

She got two agency quotes, both above $80,000 with four- to six-month timelines, and both priced every feature on her wishlist. She tried Sharetribe, a capable marketplace builder at $39 a month to build and $199 a month live (billed yearly). It handled listings and payments well. It fought her on time slots, travel buffers between appointments, and a partner-side job flow, which are the core of a home-services business, and Sharetribe says custom frontend code is something you host yourself. A freelancer on a marketplace site quoted low but could not say who would own the cloud accounts.

She chose a founding-engineer setup: one senior engineer accountable for architecture, both apps, the backend and the launch, on a fixed quote after scoping. The way I work, she owns the repository and every cloud account from day one, gets a working demo every week, and gets written design docs and a handover at the end. That combination is the reason for the choice, more than the price.

Best for: a founder with real demand and a clear workflow who wants one person accountable. Not for: a founder still guessing whether anyone will book, who should run a no-code or manual test first.

What got cut from v1

The hardest week of any marketplace build is the scoping week, because it is mostly deleting things. Urban Culture eventually had a targeted coupon engine that lifted average cart size 16%, a partner loan-management system that lifted partner onboarding 30%, and a custom geolocation service that cut our Google Maps bill by 80%. All three were worth building. None of them belongs in a first version.

Manual dispatch is the cut that scares founders most. It is also the safest one. At twenty bookings a day a human assigns jobs better than an algorithm you have no data to tune yet, and the admin log of who got assigned what becomes the training data for automating it later. My separate piece on what to cut from a marketplace MVP goes deeper on this. Delivery has the same problem with couriers, plus substitutions, which the local grocery delivery build covers.

The 8-week build, week by week

Week 1: scope and data model

We wrote down the booking lifecycle (requested, paid, assigned, en route, in progress, done, cancelled, refunded) and who may move a booking between states. Every bug I have seen in a services marketplace traces back to a state nobody wrote down. The design doc was four pages and Dana signed it off.

Weeks 2–3: catalog, slots and payments

Service areas were drawn as a list of Austin zip codes, not a polygon editor. Slots were generated from partner availability minus a fixed 45-minute travel buffer. Payment is taken upfront by card. Because the service happens in a customer's home, Apple's rules require a normal card or Apple Pay flow here, not in-app purchase (App Store Review Guideline 3.1.3(e)), so Apple takes no cut.

Weeks 4–5: partner app and admin

The partner app does four things: show today's jobs, open the address in the phone's own maps app, mark "started" and mark "done". Opening Google or Apple Maps instead of embedding a live map in v1 removed a whole category of map-SDK cost and bugs.

Weeks 6–8: payouts, pilot, launch

Freelance partners are paid weekly through Stripe Connect. Dana's own staff ran real bookings for a week before any customer saw the app, which is where the surprises below came from.

What the build and running costs look like

The build is a fixed quote after scoping. My MVP builds start at $15,000; for this scope my rough estimate is $18,000–$24,000, depending mostly on how many payout and cancellation rules survive the scoping week. For your own marketplace, the app cost calculator gives a rough range from the apps and features you pick. The running costs are where founders get surprised, so here they are at an assumed 600 bookings a month at an average of $90.

Two things stand out. Card fees are the largest line by a wide margin and scale with revenue, so your commission has to cover them. And maps are free at MVP volume but not at scale: at Urban Culture the distance and geocoding bill grew enough that replacing it with our own geolocation service cut it by 80% with accuracy held. I wrote up how that worked. Build that the month the bill hurts, not before. The rest of the monthly bill, mostly engineering time, is in what app maintenance costs per month.

What went wrong in the pilot

• The travel buffer was wrong in both directions. 45 minutes was too long for adjacent zip codes and too short across the river at rush hour. The fix was a small zip-to-zip buffer table the manager edits, not a routing API.
• Partners forgot to tap "done". Payouts depend on that tap, so the admin panel got a "jobs still open after their end time" list and an SMS nudge to the partner.
• Cancellation policy was a business decision dressed as a bug. What happens when a customer cancels 90 minutes before? Dana had never written it down. We spent a demo call deciding refund tiers, which took longer than coding them.
• Store review took eight days, not two. One rejection asked for a demo partner login. Plan a buffer week.

What launch looked like

No press, no paid ads. Dana texted the app link to her existing clients who had asked for home visits, in two zip codes, with her own staff only for the first two weeks. Freelancers were added one at a time after a trial job. That is a deliberately small launch: in Lenny Rachitsky's interviews with 17 marketplace operators, 14 put almost all early effort into supply, and the series advises constraining by city or category first (Lenny's Newsletter). A home-services marketplace lives or dies on whether a good partner shows up on time.

The metric to watch in month one is not downloads. It is the share of bookings completed without a manager stepping in. That number tells you when it is time to build the next app or automate dispatch.

Checklist if you are where Dana was

1. Prove the demand by hand first: DMs, a sheet and a payment link are a valid v0.
2. If you have only one side (your own staff), buy a booking tool. Build only when partners, location and workflow all matter.
3. Write the booking state list before any code. Every state, every transition, who can trigger it.
4. Ship two apps from one codebase plus a thin admin panel. Defer the web app, chat, wallet and coupons.
5. Dispatch by hand until the assignment log shows a pattern.
6. Put the cancellation and refund policy in writing before week 3.
7. Own the repo, the Stripe account, the Firebase or cloud project and the developer accounts from day one.
8. Price your commission above card fees plus payout fees, or every booking loses money.

For a line-by-line view of where MVP money goes, see my 2026 MVP cost breakdown. If you have demand like Dana's and want one engineer accountable for the whole build, this is exactly the kind of work I do; here is how I work and what it costs.