
If you are planning a home services marketplace in the mould of the big lead-generation platforms, the listings page is the easy part. The hard part is everything around it: getting customers, service providers and your own staff onto one system, moving money between them fairly, keeping conversations inside the platform, and giving providers a reason to keep paying you. This guide walks through how to build a home services marketplace with Laravel, React, Stripe and Twilio, using our work on HomePro Deals as the worked example.
We will cover the role model, the stack and why each piece was chosen, how payments and commissions flow, the real-time chat layer, and what we would tell anyone scoping a similar product before a line of code is written.
What a home services marketplace actually has to solve
The client came to us with a familiar problem. Access to home services was fragmented. Workflows were manual, transparency was limited, and there was no efficient way to track revenue across the different people involved. A homeowner looking for a plumber, the plumber looking for steady work, the sales staff signing providers up, and the charity partners sharing in revenue were all effectively operating in separate worlds.
That framing matters, because it tells you the product is not a directory. A directory shows providers. A marketplace has to coordinate a transaction from first enquiry to completed job, and then settle the money correctly for everyone who touched it. For HomePro Deals that meant five distinct roles in one ecosystem:
- Super Admin — runs the platform, sets commissions, and sees revenue across every party.
- Customer — searches services, books, pays, and chats with providers.
- Service Provider — receives leads, manages orders, and gets paid.
- Sales Representative — brings providers onto the platform and tracks their own performance.
- Charity Organization — participates through a revenue-sharing model.
Most marketplace briefs start with two roles. In our experience they rarely end there. Sales reps, partners and affiliates appear the moment the business needs to grow supply, so it pays to design the permission model for more than two sides from day one.
Choosing a stack: why Laravel, React and a separate Node.js chat module
The platform runs on a React front end built with Vite, a Laravel (PHP) back end with MySQL, and a dedicated Node.js module using Socket.io for real-time chat. Infrastructure sits on AWS EC2, with media on AWS S3. Stripe handles payments and Twilio handles SMS and notifications.
Laravel for the marketplace core
Laravel is a strong fit for marketplace back ends because so much of the work is business rules: who can see which order, when a commission is earned, what happens when a booking is cancelled. Its routing, policies, queues, Eloquent ORM and migrations let a team express those rules clearly and change them safely. MySQL suits the data well too — orders, payments, commissions and referrals are relational by nature, and you want transactions around anything that moves money.
React and Vite for five different dashboards
Five roles means five very different interfaces. A customer needs search and booking; a sales rep needs performance tracking; a super admin needs revenue views across everyone. React lets you share components (tables, order cards, chat panes) across those dashboards while keeping each one tailored. Vite keeps the development loop fast, which matters when you are iterating on five front ends at once.
Why chat lives in Node.js, not Laravel
PHP's request-response model is not built for holding thousands of long-lived connections open. Rather than force it, we built the chat as a dedicated Node.js service using Socket.io, which is designed for exactly that. The Laravel app remains the source of truth for users and orders; the chat module handles the persistent connections and message delivery. Splitting it out this way means the real-time load never competes with the marketplace API for resources, and either side can be scaled or deployed independently.
Use the tool that fits the workload. A mature PHP framework for business rules and a small Node.js service for sockets is a perfectly sensible pairing, not a compromise.
How to handle Stripe payments and commission distribution
Money is where marketplaces get complicated. On HomePro Deals, Stripe handles payment processing and the platform runs automated commission distribution, so each completed order is split correctly between the provider, the platform and, where relevant, sales reps and charity partners.
A few principles we apply on any build like this:
- Keep a ledger, not just a balance. Record every commission as its own row tied to an order and a recipient. A running total is impossible to audit; a ledger lets you answer any dispute.
- Make Stripe the source of truth for payment state. Update orders from Stripe webhooks rather than from what the browser reports, and make your webhook handlers idempotent so a retried event never pays someone twice.
- Calculate splits on the server, once. Commission percentages belong in configuration that the super admin controls, applied in one place in the back end — never in front-end code.
- Plan payouts and regulation early. If the platform pays providers directly, look at Stripe's marketplace tooling (such as Connect) and its onboarding and identity requirements before you design the flow, not after.
We go deeper on webhook design and gateway choice in our payment gateway integration guide.
Driving engagement: ProBucks credits, referrals and subscription leads
A marketplace lives or dies on liquidity — enough customers to keep providers busy and enough providers to serve customers quickly. HomePro Deals tackles both sides with mechanisms built into the product rather than bolted on.
A credit and referral system
The ProBucks credit system and referral rewards give customers a reason to return and to bring others with them. Technically, a credit system is another ledger: credits are issued, spent and occasionally reversed, and each movement should be recorded with its reason. Treat credits with the same care as cash. If a user can earn them, someone will eventually try to farm them, so referral rewards should be tied to real, completed activity.
Subscription-based lead generation for providers
On the supply side, providers subscribe to receive leads. That gives them a predictable pipeline and gives the platform recurring revenue that does not depend entirely on per-job commission. Subscriptions run through Stripe as well, which keeps billing, renewals and failed-payment handling in one system.
Charity revenue sharing and sales rep tracking
Charity organizations are integrated through a revenue-sharing model, and sales representatives get dashboards with performance tracking. Both rely on the same commission ledger described above. Building that ledger well once is what makes features like these cheap to add later.
Real-time chat, notifications and order management
Keeping communication on-platform is important for any home services marketplace. When customers and providers swap numbers and finish the deal elsewhere, the platform loses both the revenue and the record of what was agreed. Real-time chat over Socket.io makes in-app messaging fast enough that people actually use it.
Twilio covers the moments when people are not looking at the app: SMS and notification integration for new leads, booking updates and order changes. A provider who learns about a lead an hour late has usually lost it, so these alerts are part of the core product, not a nice-to-have.
Order management ties it together, running automatically from booking to delivery. Each status change is a clear state transition — requested, accepted, in progress, completed, paid — and payment, commission and notification logic hang off those transitions. Modelling orders as an explicit state machine early saves a lot of edge-case bugs later. Media such as job photos goes to AWS S3 with secure file handling, so the application servers on EC2 never carry the storage load.
What to consider before you build a similar marketplace
If you are scoping your own platform, here is the advice we give in early calls:
- Start with the money map. Draw every party who pays or gets paid and every percentage involved. That diagram drives your data model more than any screen design.
- Design roles for growth. You may launch with customers and providers, but plan the permission model so a third or fourth role is a feature, not a rewrite.
- Do not build chat inside a request-response framework. Use a socket-native service or a managed real-time product.
- Launch in one city or one category. Liquidity is easier to build in a narrow market. A generic national launch with thin supply rarely works.
- Be honest about build versus buy. If your model is a simple two-sided directory, an off-the-shelf marketplace script may be enough. Custom development earns its cost when, like HomePro Deals, you have multiple roles, custom commission rules and engagement mechanics that templates cannot express.
This is the kind of multi-sided product our SaaS product development team builds regularly. You can see the live platform at homeprodeals.com and the full breakdown in the HomePro Deals case study.
Frequently Asked Questions
Is Laravel a good choice for a home services marketplace?
Yes. Laravel handles the business-rule-heavy core of a marketplace well: roles, bookings, payments, commissions and queues. Pair it with a dedicated real-time service, such as Node.js with Socket.io, for chat, because PHP is not designed to hold large numbers of persistent connections.
How do marketplaces split payments between providers and the platform?
The payment is captured through a gateway like Stripe, and the back end calculates each party's share from configured commission rules, recording every split in a ledger. Payment status should be driven by gateway webhooks, and handlers should be idempotent so retries never double-pay.
What features does an app like Angi or Thumbtack need at launch?
At minimum: provider profiles, service search, booking or lead requests, secure payments, in-app messaging, and SMS or push notifications. Referral programmes, credit systems and subscription lead plans usually come next, once you know which side of the marketplace needs the most help.
Should I use Twilio for marketplace notifications?
Twilio is a common, reliable choice for SMS alerts on new leads and booking changes. Providers respond to SMS far faster than to email, which matters when leads are time-sensitive.
Planning a marketplace with more than two sides, or unsure how to structure commissions and payouts? Talk to us — we will walk through your money map and tell you plainly what the first version needs.
