ZaykaTap
ZaykaTap is a marketplace connecting food vendors and cafés. For cafés, it provides free QR menus, live ordering, and table management. For food vendors, it opens a targeted B2B channel to reach those exact cafés.
The problem wasn't the menu
Restaurants already had digital menus. They didn't have a simple way to turn them into live ordering systems.
Scene 1: The Café
Picture a busy café on a Saturday night. Customers are waving down staff just to get a menu. When they finally order, it's jotted on paper and walked to the kitchen. It's slow, error-prone, and deeply frustrating.
Scene 2: The Vendor
Meanwhile, food vendors are blindly trying to sell their supplies to these exact cafés with zero targeted reach. They rely on cold calls and physical walk-ins, entirely missing the venues that need them most.
I saw a massive gap in the market: solve the café's chaos, and you build the exact audience the vendors want to reach.
Three users, three different problems
Any solution had to survive the chaos of the real world and satisfy three distinct groups:
- Customers: They just want to order food. They don't want to download an app or pinch-and-zoom a static PDF on spotty 3G.
- Kitchens: They need chaos reduced. Live order tickets absolutely cannot get lost, and low-end tablets dropping Wi-Fi can't break the system.
- Food Vendors: They need targeted reach. They want to advertise and sell supplies directly to the cafés that need them most.
The MVP I actually needed
I could have built a massive restaurant management system. Instead, I focused on speed and a frictionless ordering flow. Competitors were offering clunky web apps that looked a decade old. Small cafés were priced out of enterprise POS systems.
I decided to build exactly what they needed, nothing more: QR menus, live ordering directly to the kitchen, basic table management, and simple analytics. It had to feel like a premium, native app experience for the customer, right in the browser.
Why cafés get the core product for free
I could have charged cafés a flat subscription from day one. Instead, I kept the entire core platform—unlimited orders, unlimited tables, and basic AI analytics—completely free.
That removed all friction for adoption. A café can sign up and digitize their entire operation without paying a dime. In the future, paid subscriptions will target power users who need premium capabilities:
Custom branded apps for top-tier venues.
Predictive demand and inventory forecasting.
Dedicated SLA and 24/7 direct assistance.
By giving away the core infrastructure, we rapidly onboarded cafés, building the precise, highly engaged audience that food vendors pay to reach.
When live orders changed the architecture
Live orders made stale data unacceptable. That pushed the architecture toward WebSockets and caching rather than repeated database polling.
If every customer phone and kitchen tablet hammered the database with SQL queries to check for new orders, the server would melt. Instead, when a customer pays, the order drops into the database once, then instantly fires through Redis to trigger a WebSocket event. The kitchen hears a “ding!” in milliseconds.
Structuring for scale without microservices
To keep the heavy B2B admin panels from slowing down the high-traffic customer frontend, I split the monolith across strict subdomains:
| Subdomain | Product Reasoning |
|---|---|
| api. | Centralized business logic. Handles RabbitMQ retries for payment webhooks to ensure zero dropped orders. |
| app. | Café dashboard. Kept completely separate from the customer frontend so heavy analytics queries don't impact ordering speed. |
| menu. | Aggressively optimized customer UI. Uses DOM virtualization to render massive menus instantly on cheap smartphones. |
What I deliberately left out
I ruthlessly cut server costs for edge cases to keep the product economically viable.
For example, generating pixel-perfect PDF menus with complex templates and QR codes is computationally heavy. I completely stripped that from the backend and shifted it to the client-side of the React Native app. The server doesn't even know it's happening.
Similarly, before a café owner's image upload ever hits my server, it's processed client-side and converted to WebP. This reduced initial payloads by 70–80%, improving the Time to Interactive (TTI) on 3G networks without increasing server load.
What building it taught me
Building a two-sided marketplace forced me to make pragmatic technical choices. I learned that technical constraints often drive better product decisions. Moving heavy image processing and PDF generation to the client-side wasn't just cheaper—it made the core backend significantly more resilient.
Most importantly, I learned that small businesses don't care about the tech stack or perfect code. They care if the kitchen tablet rings the instant a customer pays. If it works consistently, they trust it.
Achieved via aggressive client-side compression and DOM virtualization.
Internal testing showed massive drops in load by bypassing SQL polling for WebSockets.
Artifacts
Screenshots & diagrams coming soon
Architecture diagrams and product screenshots will live here.