Felengaz — Home Services Marketplace
A home-services marketplace with four parties: customer, provider, the provider’s serviceman, and admin. It runs two patterns — booking a pre-priced service, or posting a job that providers bid on. Built across 20 independent modules.
Overview
Marketplace connecting customers with home service providers: service categories and requests, technician pricing and offers, with apps on both stores.
01The challenge
Home services are not priced one way: hourly cleaning has a known rate, but "fix a leak" cannot be priced before it is seen. A platform that forces one pattern loses half the market.
The fourth party complicates it: a provider may be a company with servicemen, so a booking is assigned to a specific person, the rating attaches to them, and the wallet belongs to the company.
On top of that, a recurring service (a weekly subscription, say) is not one booking but a series with a change history and reschedulable dates.
02What we built
We built both patterns side by side: a priced service booked directly, and a post that providers bid on for the customer to choose. Each pattern has its own module, and both end in the same booking entity — so finance, ratings and tracking work across both.
Recurring bookings became an entity with their own details, repeat history, reschedule history and status history, so a change is documented rather than written over the previous state.
The serviceman is an independent role with their own app and routes: only the bookings assigned to them, while the wallet and payouts sit at provider level. Zones decide who serves where and at what price.
We split the system into twenty modules (bookings, bids, services, providers, payments, chat, promotions, zones and more), so each can evolve without opening the rest.
03The outcome
The platform serves both priced services and open jobs in one app, so no category of demand is pushed outside it.
The serviceman works in their own app without seeing their company’s finances, and the provider manages their own wallet and payouts — roles separated by hard boundaries rather than by agreement.
What the system does
The modules that were delivered and put into daily use.
-
01
Two demand patterns: a priced service booked directly, and an open job that providers bid on.
-
02
Four roles: customer, provider, the provider’s serviceman, and admin — each with its own app and permissions.
-
03
Recurring bookings with repeat, reschedule and status histories plus additional information.
-
04
Operating zones controlling coverage and pricing, plus service categories, variations and tags.
-
05
Full finance: wallets and transactions, partial payment, offline payment, cash collection and withdrawal requests.
-
06
Provider subscription packages with limits, features and a usage log.
-
07
Channel-based chat with attachments, Firebase notifications, and reviews with replies.
-
08
Promotion: coupons, campaigns, discounts, paid advertisements and loyalty points.
-
09
Business reporting: bookings, earnings, expenses, providers and transactions — plus search analytics.
-
10
Twenty independent modules that can each evolve on their own.
Technologies used
What this system is actually built on — not a generic list.