How RuteAppz Built a Custom Handyman and Home Services Marketplace for FIXIT

Project overview

FIXIT is an on-demand handyman and home-services marketplace. Customers request a home service from a mobile app, and independent service professionals, called Fundis, receive and accept those requests in a separate app. RuteAppz customized the software for FIXIT, covering the customer app, the Fundi app and the booking workflow between them.

What the marketplace had to handle

A home-services marketplace has to solve a few practical problems at once:

• Finding the right professional. A customer needs a technician for a specific kind of job, and a Fundi should only see work in their own trade.
• Coordinating requests. Several Fundis can see the same request, so exactly one of them must end up with the booking.
• Trust at the door. The customer and the Fundi need a simple way to confirm that the right person has arrived before work begins.
• Billing for the real job. Work can run longer than planned, and the final amount has to be fair and consistent for both sides.
• Getting paid. The customer needs a payment method that is familiar locally.

The RuteAppz solution

RuteAppz customized a booking-marketplace app base into two separate mobile apps for FIXIT. The customer app lets people request a service and follow it through to payment. The Fundi app, branded simply as "Fundi", lets professionals register under a service category, receive matching requests and carry out the job. A server-side workflow connects the two, so that acceptance, job start, approval and payment status are decided by the backend rather than by either app alone.

How a booking moves through the apps

The workflow below is taken from the customer and Fundi apps. A request is created, routed to matching Fundis, accepted by one of them, started with an OTP, approved by the customer and then paid.

Customer application

The customer app lets people request a home service and then follow the booking from start to finish. While the request waits for a Fundi, the customer sees it as open to matching Fundis; if none is available yet, the request stays pending. Once a Fundi accepts, the customer sees who was assigned and tracks the booking through the stages: request submitted, Fundi accepted, service started, work submitted for approval, payment, and service completed. The app needs the customer's current location in order to find matching Fundis.

Fundi application

The Fundi app is for the service professional. On first sign-in a Fundi chooses the single service category they work under, and requests are matched using that category. The service request inbox shows only live requests routed to the Fundi's own category. A Fundi can accept a request; if another Fundi accepted first, the request expires for them with a clear message. After arriving at the job, the Fundi starts the service, carries out the work and submits it for the customer's approval.

Request routing and matching

Requests are routed by service category, and the first matching Fundi to confirm receives the booking. The customer app sends the customer's current location when requesting a service so that matching Fundis can be found. The public FIXIT website describes requests going to available Fundis nearby; the distance and availability rules are applied on the server, which is outside the app code reviewed for this case study, so this page does not describe them in detail.

Job verification with a service OTP

To start a job, the customer's app shows a 6-digit service OTP once a Fundi has been assigned. The customer shares it with the Fundi only after the Fundi arrives, and the Fundi enters it in the Fundi app. A valid OTP verifies arrival and starts the service using server time. The OTP is never displayed in the Fundi app, and after too many invalid attempts the Fundi has to wait before trying again. The public website mentions "PIN / QR verification"; the apps use this 6-digit OTP, and this page describes only that.

Overtime and approval

If a job runs past the planned time, the customer app shows overtime pricing: the length of each overtime block, the number of overtime units, the rate per block and the resulting overtime charge. When the Fundi submits the work, the customer confirms that it was completed. The final amount used for payment is the one calculated by the server, not a figure typed into either app.

Payments

The customer app includes an M-Pesa payment flow built on the backend's authoritative payment state. The customer enters an M-Pesa phone number, receives a payment prompt on that phone and enters their PIN there. The app then waits for confirmation and shows one of several states: payment confirmed, booking released to the Fundi, service payment complete, failed, cancelled or timed out. It supports retrying and refreshing the status, shows a receipt, and holds a payment in a review state, blocking other payment methods, if the outcome is uncertain, with a prompt to contact support if money was deducted. The code supports both prepayment and postpayment modes. The apps were built from a booking template that also contains other payment gateway integrations; this case study does not describe them as part of the FIXIT service, and it does not state whether M-Pesa is operating in production today.

Technology

• Customer app and Fundi app both built with Flutter, with Android and iOS project builds.
• Firebase services for authentication, push messaging and crash reporting.
• Device location for finding matching Fundis.
• A backend API that holds the booking, OTP and payment rules.

The backend and admin panel were not part of the code reviewed for this case study, so no server framework, database, hosting or admin modules are listed here, and no store availability is claimed.

Capabilities and intended business benefits

What the platform was built to provide

• A customer app for requesting services and following each booking.
• A Fundi app with category assignment and a service request inbox.
• First-to-accept booking assignment.
• OTP-based job start, overtime pricing and customer approval.
• M-Pesa payment with backend-confirmed status.

Intended business benefits

• Faster matching between customers and the right trade.
• Fewer disputes over who is on site and when work started.
• More transparent billing for jobs that run long.
• A payment method that fits the local market.

These are the outcomes the platform was designed to support. No performance figures have been supplied for publication, so this case study makes no claims about bookings, reviews, ratings, customers, Fundis or revenue. It does not state how the platform is used today.

Related RuteAppz solutions

• Handyman Service Platform: RuteAppz's ready-made handyman and home-services marketplace software.
• Flutter development services: cross-platform mobile apps for Android and iOS.
• Android development services: custom Android apps.
• iOS development services: custom iPhone and iPad apps.