Building a home services app like Zigy: features, cost drivers, timeline

A home services app like Zigy is three pieces of software working as one: a customer app for booking, a partner app for the people doing the jobs, and a backend that runs bookings, dispatch, scheduling and payments. A focused first version is typically an 8-14 week fixed-scope build, and the real price comes from a written scoping call rather than a rate card.

We know this shape well because we built Zigy, a doorstep services platform in Dubai covering salon, spa, laundry and home cleaning. It is live on the App Store and Google Play.

The problem it solves

Before platforms like this, booking a home service in Dubai meant phone calls and WhatsApp messages. Customers had no single place to book, and the providers fulfilling the jobs had no tooling to manage schedules, jobs and earnings. A good app fixes both sides of that, not just the customer side.

Core features by app

The customer app handles booking across service categories. In Zigy that means salon, spa, laundry and home cleaning on iOS and Android. A customer picks a service, chooses a time, pays and follows the booking through to completion.

The Zigy Partner app is for service providers. It delivers job alerts, schedule management, earnings tracking and customer feedback. This app is easy to underestimate, but the platform only works if providers actually use it every day. Supply-side experience decides whether bookings get accepted and completed.

Behind both sits a Laravel backend. It runs bookings, provider dispatch, scheduling and payments. Dispatch is the part that turns a request into an assigned provider. Scheduling keeps providers from being double-booked. Payments tie the whole job to money moving correctly.

What drives the cost

Cost follows scope, and for a marketplace like this the main drivers are predictable. The first is the number of service categories and how different their booking flows are. A cleaning booking and a spa booking ask for different information and different time slots.

The second is dispatch logic. Sending a job to the nearest available provider is simpler than matching on skills, availability and customer preference. The third is payments, including how and when providers are paid. The fourth is whether you need an admin web portal for your operations team, which most real marketplaces do. Finally, extras such as Arabic support, loyalty or promotions, and extra integrations each add engineering and testing time.

Our job in scoping is to separate what the first release needs from what can wait. That separation is what keeps a launch inside the 8-14 week range.

Timeline and how we would run it

We work in four stages: scope, architect, build and ship, then run. Scoping maps the real workflows for customers, providers and your operations team. Architecture agrees the schema, API contracts and app structure up front so the build does not wander.

During the build you see weekly working software, not slide decks. The web portal, API and both mobile apps move together towards store release. After launch there is a 30-day fix window on fixed-scope projects, and a Build and run retainer if you want ongoing features and monitoring.

The apps are built in React Native, so iOS and Android come from one codebase. You own the source code and infrastructure access.

Operations deserve attention before launch. Someone needs to onboard providers, handle cancellations and resolve disputes, so the admin portal and the support process should be designed alongside the apps rather than after them.

If you are planning something similar, tell us the service categories and the city you want to launch in. We will come back with a written scope and price.