Most of what I write about here comes from building relatively simple things a blog, a portfolio site, a service worker pattern in isolation. ServiceHub is the opposite: a full multi-sided marketplace, currently in testing, built to let people in Nigeria book local service providers, buy from a marketplace, request delivery riders, and chat with providers all inside one installable app, no app store required. It's the most complex thing I've built as a PWA so far, and it forced me to think about problems that don't show up in a single-purpose site.
What It Actually Does
At its core, ServiceHub connects three kinds of people in one app: customers who need something done or delivered, providers who do the work, and admins who keep the whole system healthy.
Book a provider: Customers search for nearby artisans and service providers, see real-time availability, and book directly in-app. Marketplace: A product storefront layered into the same app, so buying and booking share one identity and one wallet. Delivery & riders: Request a rider for delivery, tracked the same way a booking is. In-app negotiation & chat: Customers and providers can message and negotiate terms before confirming a job. Escrow-based payments: Funds are held until a job is marked complete, rather than paid out up front. Referral system: Built-in growth loop for both customers and providers. Geolocation matching Providers are ranked and surfaced by proximity, service radius, and coverage area, not just alphabetically or randomly.
Why Offline-First Actually Mattered Here (Not Just In Theory)
This is the part that connects directly to what I usually write about. A lot of "offline-first" advice including my own is written from the perspective of a content site: cache the shell, gracefully degrade, done. A marketplace app breaks that assumption immediately, because almost every core action is a write, not a read: booking a job, sending a chat message, accepting a negotiation offer. You can't "cache-first" your way out of someone trying to pay for a service on a spotty connection. That pushed the architecture toward: Optimistic UI everywhere a user takes an action: A booking request or chat message shows as sent immediately, then reconciles once the server actually confirms it. A real service worker strategy per surface, not one blanket rule, the provider map and search results are cache-friendly, but bookings, escrow status, and chat go straight to the network with a clear fallback state instead of stale cached data. An explicit offline page (offline.html) so a dropped connection mid-flow shows something intentional, not a broken blank screen.
Geolocation as a First-Class System, Not a Feature
Finding the "nearest available provider" sounds simple until you're doing it at scale. ServiceHub uses geohashing to index provider locations so proximity search stays fast without scanning every provider in the database, plus a separate service-coverage model, providers can define a radius, a list of cities, or mark themselves nationwide, and matching respects whichever model they've chosen. Markers on the live map are clustered client-side so the UI stays responsive even with a dense set of providers in one area.
Where It Stands Now
ServiceHub is still in the testing phase, the core booking, marketplace, chat, escrow, and geolocation systems are built and working, and the current focus is hardening the experience before a wider rollout: refining matching quality, tightening the notification system (push notifications and admin broadcast tools are both in place), and generally making sure the app holds up under real, messy usage rather than clean test conditions. Building something this multi-sided has been a different kind of challenge than a single-purpose site, the interesting problems aren't "how do I cache this asset," they're what does this system do when two people are negotiating a price and one of them goes offline halfway through. That's the kind of problem I'll probably be writing more about as ServiceHub moves closer to a public launch.