# Restoman **Restaurant infrastructure, built differently.** Restoman is a B2B platform that runs a restaurant's floor — orders, tables, kitchen and checkout — built by a team of four that I lead as CEO. It is live in its first venue, and it started as a school project that only worked for one restaurant. - Role: CEO. Product, design, and most of the code. - Period: 2025 — now - Status: Active - Work: Product, Full-stack, Design, Business - Site: https://www.restoman.app ## The problem A restaurant runs on information that will not sit still. Which table ordered what. What the kitchen has actually started. What has been paid and what has not. Who is allowed to void a line. Most venues hold all of that in a mix of paper, shouting, and a point-of-sale system that was designed before smartphones. It works, in the sense that people are fed. It fails in a specific way: nobody can answer a question about the last hour without walking somewhere and asking a person. The software that exists to fix this is either built for a chain of two hundred venues and priced accordingly, or it is a menu in a PDF. ## Where the idea came from Not from a market gap. From a worse version of it. In our third year of school, four of us built **Pedilo** — Simón Mersich, Oliver Jones, Nicolás Krymkiewicz and me. Simón had made something similar for a course, to replace the PDF menus restaurants were sending people, and we wanted to do it properly on the web. It went well and it had one hard limit: it worked for exactly one restaurant. You could add products and take orders. You could not create a second venue. The turn came at a dinner. Someone there saw the project and explained how shopping centres actually work — who runs them, who leases to whom, how the food court is managed as one thing. Walking home I realised the interesting version was not one restaurant: it was a **food court**, where a dozen venues share a floor, share customers, and share nothing else. Nobody builds for that, because it is nobody's obvious customer. So we stopped theorising and started talking to people who would actually know. I wrote on behalf of the Pedilo team proposing a platform where every restaurant in a centre could take and manage its own orders, track stock and see its own numbers, tied to a central site per centre and per operator. That email is the first written record of Pedilo becoming Restoman. ## The constraints Four people, none of them full-time, all of them still in secondary school. No funding. And one that shaped every decision: **the first client had to keep serving customers while we installed it.** Nothing could require the staff to stop and learn a system, and nothing could have a step that only works if someone remembers to do it. ## What it actually is Not one app. Four, in a Turborepo monorepo on Bun workspaces: - **`api`** — the whole domain. **Elysia**, typed end to end, with an OpenAPI document the frontends consume through **Eden Treaty**, so a change to a route is a type error in the dashboard rather than a bug in production. **Better Auth**, **Drizzle** over **Postgres**, **Redis**. - **`dashboard`** — Next 16 and React 19. What the business uses: organisations, venues, menu, orders, kitchen, the register, roles, billing. - **`diner`** — Next 16. What the customer uses. You get in by scanning the QR on your table. Works as an anonymous guest or with an OTP account, because asking someone to make an account before they can order a burger is how you lose the order. - **`landing`** — the public site. Plus shared packages that exist because two apps needed the same answer: `permissions` (the RBAC vocabulary and a pure resolver, used by both the API and the role editor, so the thing that grants access and the thing that draws the UI cannot disagree), `ui` (the design system — Base UI, CVA, Motion, tokens mirrored from Figma), `features` (feature flags), `schemas`, `i18n`, `logger`. ## What I decided Five calls I made and would defend. ### We wrote our own organizations and RBAC instead of using the auth plugin The plugin models a flat company: members, roles, done. A restaurant group is a hierarchy — group, venue, floor, station — and a permission has to inherit downward through it while **never** escalating upward or sideways. The alternative was keeping the plugin and modelling the hierarchy beside it, consulted after the plugin answered. It would have worked, and it would have meant two sources of truth for one question. Every check would have had to ask both and reconcile them, and the first time they disagreed we would have had a security bug rather than a rendering bug. So it is our schema, with inheritance resolved **per permission** rather than per role: not "a manager can do X" but "this permission inherits downward from the scope it was granted at". More code, and we own it. Worth it, because permissions are the one part of this system where approximately right and wrong are the same thing. ### A dish's position belongs to the relationship, not to the dish An item appears in several contexts — the menu, a section, a kitchen station — and can be ordered differently in each. Making position a column on the item forces one global order for everything. Making it a property of the context-item pair means **not ordering is simply inheriting**. That one is implemented and marked for rework. It works, and moving a single item writes N rows. I would rather say that here than have someone find it. ### The cache is fail-open, asymmetrically A cache miss degrades to a slower read. A cache error must never degrade to a wrong permission. And ephemeral tokens live outside the cache entirely, because they are not cache — they are state that happens to expire. ### Diner overlays portal into the venue's theme scope Each venue themes its own diner app. Modals rendered at the document root escaped that scope and came out unstyled. The fix is small; the rule it produced is the useful part, and it is written down so it cannot be rediscovered. ### The register is a screen for taking money, not a report Researched against Toast, Fudo and Mercado Pago before drawing anything. The thing all three get right is that the person at the till is under time pressure and everything on screen is either the amount or in the way. ## The team - **Me** — CEO. Product, design, and most of the code. - **Simón Mersich** — CTO. Architecture and backend. - **Oliver Jones** — COO. Sales and B2B onboarding. - **Nicolás Krymkiewicz** — CXO. Experience. It is also an academic project at ORT, with two tutors, and those are two different things on purpose. Someone else was part of the academic side of Restoman; it was always agreed and understood that they would not be part of the business and that none of their intellectual property would be used in it. That line existed before it mattered, which is the only time a line like that is worth anything. ## Where it is Live in its first venue. **They are not paying yet** — we are testing with them, in their service, with their staff. There are more waiting to join, and we are deliberately not letting them in yet. Onboarding a venue properly means being there while it happens, and four people cannot be in five places. Going slowly is the choice that makes the first ones work rather than the choice that makes the number look bigger. Looking for angel investment. The 500-venue figure in our original proposal is **projected capacity, not traction**. I would rather write that sentence than have an investor who knows the difference work it out for themselves. ## What I would do differently Start the design system before the screens, not after. Revisit ordering per context before it grew a second implementation on top of it. And write down what happens if someone leaves before the first month of revenue, instead of after. --- Page: https://eitanf.com/work/restoman · Español: https://eitanf.com/es/work/restoman.md · llms.txt: https://eitanf.com/llms.txt