A production-grade booking template. Pick your industry at build time — restaurant, cinema, theater, parking, beach club or coworking — and ship it as your own branded app.
Every edition draws the same booking map differently: a restaurant floor plan, a cinema auditorium, a theater's price zones, a parking level, a beach club's rows, a coworking floor.
That map is the booking mechanic itself, running here on the page — the same grid re-drawn for each industry. It previews how the flow works; it is not the Flutter app, and nothing you press reserves anything.
Or try it now: download the Android demo — the restaurant edition, 21 MB, running on its bundled sample data. No account, no backend, and nothing you do in it leaves the phone.
See all 109 designed screensPre-launch: all 109 screens are designed and 47 of them are built in the app today, with the rest following. The live demo, the download and the docs are available now.
The codebase is the same underneath. What changes is the booking unit itself — the thing your customer is actually selecting.
Guests pick a table on a floor map, see which tables are free for their time slot, and book a party size directly against that table.
13 screensMoviegoers pick seats on a grid, screening by screening, with the taken seats greyed out and their own selection held until checkout.
12 screensSeats are grouped into zones with their own price tiers — stalls, circle, balcony — plus accessibility filters for step-free and companion seating.
13 screensDrivers pick a bay on a level from a live map, reserve it for a window of time, and get the bay number at checkout.
12 screensSunbeds are priced by row — front row nearest the water costs more than the back — and guests pick the exact bed, not just a zone.
12 screensMembers book a hot desk for the day or a meeting room by the hour, from the same calendar-style picker.
12 screensEvery edition shares the same core: onboarding, sign in, checkout, bookings, profile, notifications. Only the booking unit changes.
Every one of the 109 designed screens below was rendered straight from the Flutter design source at real device size — nothing here is a mockup or a stitched contact sheet. Tap any screen to open it full size.
The screens every buyer gets regardless of industry: onboarding, sign in, checkout, bookings, profile and notifications. 28 screens in this set.
Floor map, table detail and party-size booking flow for table reservations. 13 screens in this set.
Screening list, seat grid and seat-selection checkout for cinema ticketing. 12 screens in this set.
Zoned seat map with price tiers and accessibility filters for theater tickets. 13 screens in this set.
Level map and bay reservation flow for parking bookings. 12 screens in this set.
Row-priced sunbed map and beach club booking flow. 12 screens in this set.
Desk and meeting-room availability and booking flow for coworking spaces. 12 screens in this set.
The operator screens: reservation list, calendar, QR check-in and the tablet map builder used to lay out tables, seats, bays, sunbeds or desks. 7 screens in this set.
The finished foundation layer, and where the rest of the build is headed.
A single Flutter codebase on Dart 3.12 with flutter_riverpod 2.6 for state, structured so one industry's booking logic doesn't leak into another's.
Declarative routing on go_router 14.6 across onboarding, booking flows, checkout and the admin panel, with deep-linkable routes throughout.
The app runs end to end with no backend at all — every booking flow works against local mock data out of the box.
Auth, Firestore, Storage and Cloud Messaging are wired as an optional layer behind the same interfaces the mock data uses.
Both themes ship from one set of design tokens, so the app and the admin panel stay visually consistent in either mode.
Two shipped locales and right-to-left layout support, so the app doesn't break the day you add an RTL language.
A separate operator-facing side of the app: a reservation list, a calendar view, QR check-in for arrivals, and a tablet map builder for laying out the tables, seats, bays, sunbeds or desks that the customer-facing app books against.
The template price is the template price. What it cannot cover is other companies' billing: Firebase, your payment provider, and the Apple and Google developer accounts you need to publish an app are each priced by their own provider, and each can cost money beyond a free tier once your usage grows. Zeplo runs entirely on its mock data layer with none of them, so you only take on a bill when you choose to switch one on.
What Zeplo is today, in plain terms — including the parts that are not finished yet.
Yes. One licence covers the whole template — restaurant, cinema, theater, parking, beach club and coworking — plus the 28 core screens they share and the admin panel. You pick which industry a build targets; you are not buying six products.
Two, and you choose. Zeplo ships with a sample data layer, so every booking flow works end to end the moment you open the project — no account, no project, no configuration. When you want accounts and data that outlive the session, one flag on the build command switches it to Firebase Authentication and Cloud Firestore, with security rules, indexes and a seed script included and no server code to deploy. Both sit behind the same interfaces, so putting your own API behind them instead is one class, not a rewrite of the screens.
Dart SDK 3.12 and up, with flutter_riverpod 2.6 for state and go_router 14.6 for navigation. Models are generated with freezed and json_serializable.
Yes — it is one Flutter codebase targeting both. The project is set to Android minSdk 24 (Android 7.0) and iOS 13.0, so it covers the range both stores expect. You publish under your own developer accounts, with your own bundle identifier, branding and store listing.
A reservation list, a calendar view, QR check-in for arrivals, and a tablet map builder for drawing the tables, seats, bays, sunbeds or desks that the customer-facing app books against. Seven screens in total, shown in the Admin set above.
One licence covers one production site, plus a staging copy of it. A second live site needs a second licence. Full terms at webkodingtheme.com/legal/license.
Yes — a year of updates and support from the day you buy, by email from the developer who wrote it. The documentation ships inside the download.
Yes. The Android demo below runs the restaurant edition on its own sample data, with no account and no backend. Buying gets you the full Flutter source and the Firebase setup it talks to.
$38 once, not a subscription. Full Flutter source, unminified, on your own Firebase project. Paddle.com is the Merchant of Record.
Buy Zeplo — $38Or try it now: download the Android demo — the restaurant edition, 21 MB, running on its bundled sample data. No account, no backend, and nothing you do in it leaves the phone.