QuickFixHub — Cross-Platform Service Marketplace
Full-stack, cross-platform service marketplace (React Native + Spring Boot) with customer, provider, and admin apps — booking, chat, verification, and payments.
Overview
A cross-platform marketplace that connects customers with verified local service providers — plumbing, electrical, cleaning, repairs — for on-demand home jobs. Designed and built solo, end-to-end: a React Native (Expo) app and a Spring Boot API serving three distinct product surfaces — customer, provider, and admin.
What it does
Customers discover providers by category, name or city, or a map radius search (device location plus Haversine distance), view profiles with ratings and pricing, request a booking, track it through a live status timeline, chat with the provider, and leave a tagged review.
Providers onboard a business profile, set service pricing and weekly availability, upload verification documents, and work incoming jobs from a dashboard (accept → en route → in progress → complete).
Admins review submitted documents in a verification queue (approve, reject, or request more), watch live platform stats, and issue refunds.
Architecture & engineering
- Stateless auth — short-lived JWT access tokens with rotating, DB-hashed opaque refresh tokens that can be revoked; Redis-backed login rate limiting; timing-attack-safe login to close an email-enumeration side channel; email-based password reset with single-use, attempt-capped codes.
- Guarded booking state machine — every transition is an ownership-scoped endpoint with per-transition timestamps, a 30-minute accept window with automatic expiry, and cancellation rules; the app renders a history timeline with no separate audit table.
- Transactional email over SMTP — welcome, password-reset, and security-alert mail sent asynchronously and best-effort, so a failed send never breaks the request that triggered it; a Mailpit container captures it all in local development.
- Schema discipline — 23 sequential Flyway migrations with Hibernate in validate mode, so entities and schema can never silently drift.
- Pragmatic search — Spring Data Specifications compose optional filters; radius search does an in-memory Haversine pass, the right trade-off at this scale and swappable later.
- Typed API client with automatic token refresh and single-flight retry on 401s.
- Dockerised local stack (PostgreSQL, Redis, Mailpit); OpenAPI/Swagger docs.
Notable constraints I designed around
- Staying on Expo Go (no custom dev client) meant no native map module and no OS push — I render maps through the Google Maps JavaScript API in a WebView and built an in-app, polled notification centre whose data model is already push-ready.
- Running Spring with open-in-view disabled surfaced lazy-loading and Hibernate flush-ordering pitfalls in DTO mapping and replace-all writes, which I fixed with explicit fetching and transaction boundaries.
Scope notes
Payments are a mocked ledger — a Payment row is created when a booking completes, which is enough for real receipts and admin refunds, and the schema was built to drop a real gateway in behind it. Chat and notifications poll rather than stream.