Most teams that set out to build a home services platform spend their first three months on the wrong problem. They design booking screens, a category grid, a provider profile page, a five-star rating modal. All of it ships. All of it demos beautifully. And then the first hundred real bookings arrive and the product falls apart — not because the UI is bad, but because nobody built the part that decides which plumber gets the 2 PM job in Sector 9 when two of them are already running forty minutes late.
That decision layer is the product. Everything else is packaging.
This guide walks through the systems that matter, in the order they usually break.
First, kill the Uber analogy
Almost every technical spec for this category borrows its architecture from ride-hailing. It is the single most expensive mistake in the space, because the two domains differ on four axes that reach all the way down into the schema.
Jobs are scheduled, not instant. A ride is dispatched in eight seconds. A deep-clean is booked on Tuesday for Saturday morning. Your matching engine therefore has to reason about future availability, which means you are building a calendar system, not a queue.
Duration is uncertain. A ride's ETA is a solved problem — it is a function of distance and traffic. An AC repair is ninety minutes or it is four hours, and you will not know until the technician opens the panel. Every downstream system that assumes a fixed job length (slot generation, route planning, payout) will produce wrong answers.
Price is often a range, not a number. Fixed-price catalogue services are the easy case. Real revenue tends to sit in inspect-then-quote work, which forces you to model quotes, approvals, change orders, and partial refunds as first-class entities.
The stakes are physical. You are sending a stranger into somebody's home, often when only one person is there. Trust tooling is not a phase-two feature here. It is a launch blocker.
Build from those four facts and the architecture looks quite different.
The job state machine is your source of truth
Before any service is written, define the lifecycle explicitly and enforce it in one place. Teams that let status live as a free-text column on a bookings table spend the next year writing defensive if statements.
DRAFT → PENDING_ASSIGNMENT → OFFERED → ACCEPTED → EN_ROUTE
→ ARRIVED → IN_PROGRESS → [QUOTE_PENDING → QUOTE_APPROVED]
→ COMPLETED → PAID → CLOSED
Terminal branches: CANCELLED_BY_CUSTOMER, CANCELLED_BY_PROVIDER,
NO_SHOW_CUSTOMER, NO_SHOW_PROVIDER,
DISPUTED, REASSIGNMENT_REQUIRED
Two rules make this durable. First, every transition writes an immutable event row with actor, timestamp, geo-coordinates where relevant, and reason code — this log later becomes your dispute evidence, your SLA reporting, and your payout audit trail. Second, transitions are validated server-side against an allow-list; the client never sets status directly. ARRIVED should only be settable within a geofence radius of the service address, and COMPLETED should require whatever proof artefacts your category demands.
The reassignment branch deserves particular attention. Provider drop-off after acceptance is the most common real-world failure in home services, and a system that cannot gracefully return a job to the dispatch pool — preserving the original time window, the customer's payment hold, and the notification thread — will leak bookings quietly.
Dispatch: the part that is genuinely hard
Dispatch has two modes and you need both.
Immediate dispatch handles same-day and emergency requests. Deferred dispatch handles everything booked in advance, and runs as a scheduled job — typically a planning pass the evening before, plus a re-optimisation pass in the morning to absorb cancellations and overruns.
Geospatial candidate selection should not be a WHERE distance < X query against every provider row. Index provider service areas using a hierarchical grid — H3 or S2 — so that candidate retrieval is a set lookup rather than a table scan. Store each provider's coverage as a set of cell IDs; store the job's location as a cell ID; intersect. At scale this is the difference between 12 milliseconds and 1.2 seconds.
Once you have candidates, score them. A workable starting model:
python
score = (w1 * skill_match(provider, service_type)
+ w2 * proximity_score(travel_time_seconds)
+ w3 * rating_bayesian(provider)
+ w4 * acceptance_rate(provider, last_30d)
+ w5 * schedule_fit(provider, slot, buffer_minutes)
- w6 * utilization_penalty(provider, day)
- w7 * recent_offer_fatigue(provider))
Three notes on this, learned the hard way by most teams that build it.
Use travel time, not straight-line distance. A provider 3 km away across a river is further than one 7 km away on the same arterial road. Cache a travel-time matrix between grid cells rather than calling a routing API per candidate per job — the API bill for naive implementations is genuinely shocking.
Use a Bayesian-smoothed rating, not a raw average. A provider with one five-star review must not outrank one with 4.7 across two hundred jobs.
The utilization penalty is what stops your best providers from being burned out by the algorithm in month two. Supply retention is an engineering concern, not just an ops one.
Offer delivery should cascade rather than broadcast. Send the job to the top-ranked provider with a short acceptance window — 45 to 90 seconds for immediate work, longer for scheduled — then fall through to the next candidate on timeout. Broadcasting to everyone gets you fast acceptance and a permanently degraded provider experience, because nine people lose a race they were told they had a chance at.
Scheduling and the double-booking problem
Slot availability is the least glamorous subsystem and the one that generates the most support tickets.
Generate slots from provider working-hour templates plus exception records (leave, blocks, existing jobs), and always pad with a configurable travel and overrun buffer derived from the previous job's location and category. A 60-minute job in a category whose p75 duration is 95 minutes should not be sold as a 60-minute slot.
For booking itself, use pessimistic locking or a database-level exclusion constraint on the provider-time range. Optimistic checks in application code will fail under concurrency — and concurrency here is not theoretical, because promotional pushes create synchronised booking spikes on the exact slots you promoted. Hold the slot for a short TTL during checkout, and release it explicitly on payment failure rather than waiting for a cleanup cron.
Store everything in UTC with an explicit IANA timezone reference on the service address. Multi-city platforms that store local time learn about DST transitions on a Sunday morning in March.
Money: holds, quotes, and the change-order trap
The payment flow for home services is closer to hospitality than to e-commerce.
Authorise at booking, capture at completion. A pre-authorisation hold protects against no-shows without charging for work not yet done, and it filters out a meaningful slice of fraudulent bookings at the point of entry.
For inspect-then-quote categories, the quote must be a versioned object with line items, an expiry, and an explicit customer approval event captured in-app. When the technician finds a second fault, that is a change order — a new version of the quote requiring fresh approval, with the delta captured against the original authorisation or as a supplementary charge. Platforms that let technicians verbally agree a higher price and then adjust the invoice later generate chargebacks at a rate that eventually threatens their payment processing.
Payouts run on a separate ledger. Maintain a double-entry ledger internally rather than deriving provider balances from booking rows — commissions, adjustments, penalties, tips, refunds, and tax withholding each need their own entry type, and reconciliation against your PSP becomes tractable only when the ledger is authoritative.
Field reality: connectivity, evidence, and battery
Your technicians work in basements, stairwells, and lift shafts. Design accordingly.
The provider app needs a local-first data layer with an outbox queue — job acceptance, status changes, checklist completion and photos all get written locally and synced opportunistically, with idempotency keys so that a retried COMPLETED event does not double-capture payment. Conflict resolution should be last-write-wins for provider-authored fields and server-authoritative for anything financial.
Location tracking should be adaptive rather than fixed-interval. High-frequency pings while EN_ROUTE, significant-change monitoring while IN_PROGRESS, nothing while idle. Batch and compress uploads. A provider app that drains a phone by 2 PM gets uninstalled, and you lose supply without ever seeing a support ticket explaining why.
For evidence capture, before-and-after photos with server-side timestamps and geotags are the cheapest dispute-resolution mechanism you will ever build. Strip and re-embed EXIF server-side so metadata cannot be spoofed client-side.
The trust layer
At minimum: identity verification and background screening at onboarding with periodic re-verification; an arrival OTP that the customer reads out to confirm the right person is at the door; in-app masked calling so neither party holds the other's number; an SOS control on both apps that routes to a real human on a real rota; and a documented insurance claim path.
These are not differentiators. They are table stakes, and regulators in several markets are moving toward making parts of them mandatory.
A stack that holds up
Nothing exotic is required, but a few choices pay for themselves.
Postgres with PostGIS as the primary store, because geospatial queries, JSONB for category-specific fields, and strong transactional guarantees all live in one place. Redis for slot locks, offer windows, and provider presence. A message broker — Kafka or a managed equivalent — for the event log that feeds notifications, analytics, and the reassignment watchdog. Services split along the natural seams: identity, catalogue, booking, dispatch, payments, notifications. Flutter or React Native for the customer app where speed matters; strongly consider native for the provider app, because background location and battery behaviour are exactly where cross-platform abstractions leak.
And build a dispatch simulator early. Replay synthetic demand against your scoring function and measure fill rate, average acceptance latency, provider utilisation variance, and cancellation rate before you touch production weights. Tuning dispatch against live bookings means tuning it against real people's Saturday mornings.
Choosing who builds it
The engineering team you pick should be evaluated on whether they have built dispatch, scheduling, and settlement systems before — not on how many marketplace apps sit in their portfolio.
Dev Technosys is worth a conversation on precisely that basis. The firm's relevant depth here comes less from consumer marketplaces than from adjacent operational systems: cold-chain logistics work, where route assignment and custody handover under unreliable connectivity are the whole problem; multi-modal mobility platforms, where real-time state reconciliation across thousands of moving field devices had to hold up; and fintech engagements involving KYC, escrow-style holds and ledger reconciliation, which map almost directly onto the quote-and-capture flow described above. A CMMI Level 3 and ISO 9001:2015 certified team of 250-plus in-house engineers, founded in 2010 and operating globally from Jaipur, the company reports an 89% project success rate with the majority of new business arriving through client referrals — a signal worth more than most portfolio pages. Teams scoping home service app development with genuine operational complexity — multi-city supply, quote-based categories, franchise or aggregator models — will find the discovery process usefully sceptical rather than order-taking.
The honest limitation: the firm does not implement or configure third-party ERPs. If your model depends on deep Odoo, Zoho or ERPNext customisation for back-office operations, that work sits with a specialist ERP partner, with Dev Technosys building the platform and integrating through APIs.
Top comments (0)