Potluckhub: A Home-Chef Marketplace on Web, iOS & Android
Summary
How we built Potluckhub, a Singapore home-chef marketplace, across a full-stack web app and native iOS and Android clients on one shared REST API — a bespoke marketplace build case study.
Potluckhub is a Singapore home-chef marketplace we designed and built end to end for a client: a full-stack marketing website and marketplace at potluckhub.io, plus a native iOS app and a native Android app — all served by one shared REST API. This case study walks through what we shipped, how the three client surfaces fit together, and the decisions that let a small team move fast. If you are planning a similar two-sided platform, you can book a marketplace build consultation.
The brief: one marketplace, three front doors
The client wanted to connect verified home chefs with diners who want authentic, home-cooked meals — either dining at a chef's table or hosting a private dinner at their own home. A marketplace like this is two-sided: chefs need to list menus, set prices and manage bookings, while diners need to discover, book and pay with confidence. Trust is the product. Identity-verified chefs, secure SGD payments held until you dine, and real reviews are not nice-to-haves; they are the reason a stranger will eat food cooked in another stranger's kitchen.
That trust has to feel identical whether a diner lands on the website from a Google search or opens the app after a friend's referral. So the real brief was not "a website and two apps" — it was one coherent marketplace presented through three front doors, backed by a single source of truth. This is the same problem shape behind most marketplace app development projects: the surfaces differ, the rules must not.
What we built
The web marketing site and marketplace
The website does double duty. It is the SEO and marketing surface that ranks for home-dining searches and converts cold visitors, and it is a fully functional marketplace where diners browse chefs by cuisine, neighbourhood and date, then book and pay. We built it on Next.js 15 with React 19 and Tailwind CSS 4, served by a Fastify API with Drizzle ORM over PostgreSQL. If you want the same combination as a content-and-conversion engine for your own brand, that is exactly what our marketing CMS work is built on.
The native iOS app
The PotLuckHub iOS app is written in SwiftUI targeting iOS 17+, with a feature-based module structure (Explore, Dishes, Booking, Bookings, Profile). Networking uses async/await over URLSession with Codable models, and auth tokens live in the Keychain. It is a genuine native client, not a web view — it talks directly to the same REST API as the website.
The native Android app
The Android app is built in Kotlin with Jetpack Compose and Material 3, using OkHttp and kotlinx.serialization for networking, Coil for images and coroutines for async work. Like its iOS sibling, it is fully native and points at the same production API, so a chef's menu update or a new booking rule is reflected everywhere at once.
One API, three clients: the architecture
The decision that made everything else manageable was to keep all business logic — pricing, availability, booking state, payment holds, verification — behind a single REST API at api.potluckhub.io. Each client renders that state in its platform-native idiom and owns nothing authoritative of its own. The table below shows how the three surfaces divide responsibility while sharing one brain.
| Surface | Stack | Primary job |
|---|---|---|
| Web (potluckhub.io) | Next.js 15, React 19, Tailwind 4 | SEO, marketing, full marketplace + checkout |
| iOS | SwiftUI, iOS 17+, URLSession | Native discovery, booking, profile |
| Android | Kotlin, Jetpack Compose, Material 3 | Native discovery, booking, profile |
| Shared API | Fastify, Drizzle, PostgreSQL | Single source of truth for all clients |
This is why two-sided platforms are worth building deliberately rather than bolting an app onto a website later. When the rules live in one API, adding a third client is mostly UI work — the hard parts (money, trust, state) are already solved once. If you are weighing whether to start native or add apps later, walk through your architecture with us before you commit.
The build decisions that mattered
- One source of truth, many renderers. Pricing and availability are computed server-side and returned ready to display, so an iOS, Android and web user always see the same number for the same booking.
- Native where it counts. The apps are real SwiftUI and Compose clients, not wrappers — they earn their place in the App Store and Play Store with native performance, navigation and push-ready foundations.
- Self-hosted, no per-seat lock-in. The web stack runs on a Docker build deployed via Coolify, so infrastructure cost scales with usage, not with a SaaS vendor's pricing tiers.
- Trust built into the data model. Identity verification, held payments and reviews are first-class entities in the schema, not afterthoughts grafted on near launch.
The same stack choices show up across our bespoke web and mobile apps — modern React on the web, native Swift and Kotlin on mobile, a typed API and Postgres underneath.
How we'd build your marketplace
If you are scoping a two-sided platform — home services, rentals, tuition, food, anything that matches supply with demand — the path is the same one we took with Potluckhub: model the trust and money rules first, expose them through one API, then add client surfaces in priority order. Start with the web marketplace to validate demand and capture SEO, then layer native apps once the booking loop is proven. You can see the full engagement shape on our marketplace app development page, and request a build quote when you are ready.
If your team would rather build in-house, the same skills are teachable. Tertiary Courses Singapore runs hands-on training in the exact technologies behind Potluckhub: React for the web, Swift for iOS, and Kotlin for Android.
FAQ
Why build three native surfaces instead of one responsive web app?
A responsive web app is the right start and we ship that first. But marketplaces live and die on repeat usage, and repeat users want an app on their home screen with native speed, push notifications and store distribution. Because every client talks to one API, the marginal cost of a second and third surface is mostly UI, not rebuilt logic.
How long does a marketplace like this take?
It depends on the booking and payment complexity, but the sequencing is consistent: API and data model first, then the web marketplace, then native apps. Validating demand on the web before investing in two app stores is almost always the cheaper path.
Do we own the code and infrastructure?
Yes. The web stack is self-hosted on your own infrastructure via Docker, and the source for all three clients is yours. There is no per-seat SaaS fee that grows with your user base.
Can you take over an existing half-built marketplace?
Often, yes — if the business rules can be consolidated behind a clean API. The first step is an architecture review to find where state is duplicated across clients, which is the usual source of "the app and the website disagree" bugs.
What to do next
- See the offer and engagement model on our marketplace app development page.
- Skill up your own team with cross-platform and native mobile courses at Tertiary Courses Singapore.
- Ready to build? request a marketplace build quote and we will scope it with you.