TheHandyMan: a home-services marketplace for Morocco

TheHandyMan is ShipFastDev's home-services marketplace for Morocco: customers browse services such as plumbing, electrical work, cleaning and gardening, compare prices in Moroccan dirhams (MAD) and book a time slot with a provider. The customer and provider screens are built and the backend handles accounts and authentication; connecting the two is the next stage. It is not public; a demo is available on a call.

What a customer can do

• Browse by trade. The home page lists popular categories (plumbing, electrical, cleaning, painting, gardening, carpentry, appliance repair, moving), and the services page filters by category.
• Compare offers. Each service card shows its price in MAD (per session or flat rate), its usual duration and its rating, for example a regular house cleaning or a deep clean.
• Book a slot. The booking page lets the customer pick a date and an available hourly slot, enter the service address and check a booking summary with the price, duration, scheduled time and provider.
• Manage an account. Register, log in, reset a forgotten password by email, and follow bookings and payment methods from a dashboard.

What a provider gets

The provider side was specified in a short product requirements document before it was built, with three features:

• A public profile with business details, service areas, credentials (with document uploads) and a photo gallery of past work.
• "My Services" to add, edit, pause or delete services. Each service has a category, description, duration, photos, a status (active, paused or draft) and a pricing model: fixed, hourly, a price range, or on quote.
• Availability settings: a default weekly schedule of time slots, date overrides for holidays or blocked hours, and a buffer time between jobs.

Providers also get a dashboard with metrics, activity and reviews.

What was built

• Frontend. Next.js 14 with the App Router, TypeScript and Tailwind CSS; React Query for data fetching, Zustand for state, React Hook Form with Zod for form validation, and FullCalendar for schedule views. i18next is in place for the planned Arabic, French and English versions.
• UI first, with a mock data layer. Pages call hooks, hooks call a service layer, and the service layer currently returns mock data. When the API is ready, only the service layer changes; the pages stay as they are.
• Backend. NestJS with TypeScript and PostgreSQL through TypeORM. It provides registration, login and profile endpoints with JWT authentication and route guards, a password-reset flow by email, a service-provider data model, Swagger API documentation, request logging, a global error filter, and health and metrics endpoints.
• Planned architecture. The repository's README sets out separate services for users, booking, payments, messaging, reviews and admin, with an admin panel to verify providers.

How it is kept reliable

• Password reset done carefully. Reset tokens are random, 64 characters long, expire after 30 minutes and work once. The "forgot password" endpoint returns the same message whether or not the email exists, so it cannot be used to discover accounts, and new passwords must meet complexity rules.
• Account data. Passwords are hashed, never returned in responses, and incoming data is validated against typed rules.
• Schema changes through migrations. Production databases change only through TypeORM migrations, which run on deployment; the quick synchronisation script is for development only. TypeORM's own documentation says that synchronising the schema automatically is unsafe in production once there is data in the database.
• Tests. Jest unit tests for the authentication service, end-to-end tests for the registration, login and profile flow, and Jest with Testing Library on the frontend.
• Repeatable environments. Docker Compose for local development (with pgAdmin for the database), production Dockerfiles, Nginx with HTTPS in front of the API, and deployment to Fly.io through a GitHub Actions workflow.

Recent releases

The repository has 17 commits between 20 March and 24 May 2025.

• 24 May 2025: provider features (profile, services and availability) with their hooks and mock data, provider dashboards, reviews and payment methods, and clearer error messages on the sign-in forms.
• 2 May 2025: user and provider dashboards with metrics and activity, booking management and service reviews.
• 27 April 2025: service images with a fallback component and preloading, and data hooks for bookings and services.
• 6 April 2025: database migrations, the service-provider model, request logging, health and metrics endpoints, and the authentication documentation.

Where it goes next

The provider requirements document lists the next step: connect the provider screens to the real API, then the booking flow that checks provider schedules. If you are scoping a similar marketplace, How to scope an MVP and How much does an MVP cost cover the decisions involved, and the Driveway Morocco case study shows a booking product that is already live. More projects are in the portfolio.

Frequently asked questions

Is TheHandyMan live?

No. It is not public, and the screens currently run on mock data. A demo is available on a call.

How are prices set and shown?

Prices are shown in Moroccan dirhams (MAD). Each provider chooses a pricing model per service: a fixed price, an hourly rate, a price range or a quote.

How do providers control when they can be booked?

They set a weekly schedule of time slots, block specific dates or hours, and add a buffer time between jobs. Customers then pick a date and one of the available slots.

Why build the screens before the backend was finished?

The product requirements chose a UI-first approach with a mock data layer, so the customer and provider journeys could be built and reviewed without waiting for every API. Only the service layer needs to change when the backend is connected.

Sources

1. NestJS documentation, NestJS, accessed October 2026
2. Next.js documentation, Vercel, accessed October 2026
3. How migrations work?, TypeORM, accessed October 2026
4. Continuous deployment with Fly.io and GitHub Actions, Fly.io, accessed October 2026
5. FullCalendar documentation, FullCalendar, accessed October 2026