IbnKhafagah for Development SINCE 2018
Platforms & Services

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.

  • Client Felengaz
  • Delivered 2026
  • Our role Platform and module development plus the app APIs

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.

Core

Laravel 11 PHP 8.2 MySQL nWidart Modules

Interfaces

Passport REST API v1 Firebase Eloquent Spatial

Payments

Stripe PayPal Razorpay Paystack Flutterwave PhonePe MercadoPago

Operations

Twilio Fast Excel DomPDF Spatie Backup AWS S3