Inspiration

Watching a friend open a small German restaurant, I counted the moving parts before they could take a single euro: a SumUp terminal, a POS system to subscribe to, a Lieferando contract to sign, a separate tablet for the kitchen, and a stack of logins nobody could keep straight. Each piece came from a different vendor, with its own hardware, its own monthly fee, and its own way of breaking. Getting started was harder than running the business.

I kept asking a simple question: what if everything a business needs to start selling lived in one platform, and the only hardware you needed was a tablet and maybe a phone that you might already have? Lose the phone? Buy any other one, log in, and you're back in. Lose the tablet? Borrow grandmas and you're back in business like nothing happened. That idea became Leviathan.

What it does

Leviathan is an all-in-one platform to get any business — restaurants, retail, services, concerts, event — selling fast, with everything in one place:

  • POS — turn an iPad or Android tablet into a full point-of-sale: catalog, cart, locations, live order workflow (open → paid → preparing → ready → done).
  • Payments — using Apple's Tap to Pay on iPhone entitlement, a phone is the payment terminal. If the tablet itself supports tap-to-pay it runs solo; if not (no NFC, older device), you pair a companion phone as the terminal. No rented hardware.
  • Delivery — businesses choose their channel: join the Leviathan Marketplace (a Lieferando-style app of local businesses) for free, or get their own branded app that we publish for them by automating an Expo app template and walking them through Apple Developer signup.
  • Device resilience — devices, POS stations, and terminals are all tied to the business account, not the hardware. Lose a device, log in on another, and you're running again in minutes. Hosting a crowded event ? No more lines at ticket booths, just give your volunteers login information and they can start selling tickets/merch from their very own phone.

The whole thing is a monorepo with three surfaces: a web back office for onboarding and management, the operator app that actually runs the business, and the marketplace app for customers.

How we built it

  • Monorepo: Turborepo + Bun workspaces — apps/web, apps/operator, apps/marketplace, and a shared packages/backend.
  • Backend: Convex as a single reactive backend and database. One schema powers all three apps, so a marketplace order and a POS order are literally the same orders rows — an online order shows up live on the kitchen tablet with zero sync code.
  • Auth: Clerk everywhere. Businesses are Clerk organizations (admin/member roles → permissions); marketplace customers are plain Clerk users. ConvexProviderWithClerk ties identity straight into every Convex query and mutation.
  • Payments: Stripe — Connect for onboarding each business as a connected account, and Stripe Terminal / Tap to Pay for in-person card-present payments, including a companion-phone pairing flow.
  • Web: Next.js 16 (App Router). Mobile: Expo Router + React Native (new architecture), with Expo's Tap to Pay entitlement plugin.

The marketplace gate is a nice example of reuse: a business goes live only when its leviathan_marketplace channel is ready, it has a marketplace profile, and it has an active location accepting online orders — all built on tables the POS already used.

What we learned

  • A shared data model beats integrations. Because POS, marketplace, and back office read the same Convex tables, "the order shows up on the kitchen tablet" was a query, not an integration project.
  • Clerk orgs map cleanly onto real businesses — staff, roles, and permissions came almost for free, and modeling customers as org-less users kept the two audiences cleanly separated on one auth system.
  • Tap to Pay collapses the hardware problem. Treating a phone as a detachable terminal meant "what hardware do I need?" shrank to "a tablet, and maybe a phone you already own."

Challenges we faced

  • Tap to Pay on iPhone requires Apple's proximity-reader entitlement and a custom Expo config plugin — and only certain devices qualify, so we built runtime detection to decide when a tablet can take payments itself versus when it needs a companion phone.
  • One backend, a lot of very different clients. Designing Convex functions that serve a Next.js back office, an operator tablet, and a public customer app — with the right auth boundary on each (org-scoped vs. public vs. customer-scoped) — took careful schema and permission design.
  • Merging a marketplace prototype into the monorepo. A standalone skeleton used mock customers and guest sessions; folding it in meant replacing all of that with real Clerk + Convex auth so customer orders flow into the same system the POS reads — without breaking the existing operator and web apps.
  • Device resilience as a first-class feature. Making "lose your phone, log back in, keep selling" actually true meant binding stations and terminals to the account and re-pairing gracefully, instead of trusting any single device.

Built With

Share this project:

Updates