SaaS Product
Kajapont: Commission-Free Ordering for Restaurants
A multi-tenant ordering platform for Hungarian restaurants: their own storefront, a real-time kitchen dashboard, and a fixed monthly fee instead of a cut of every order.
Delivery marketplaces take 12 to 20% of an order when the restaurant delivers it themselves, and 25 to 30% when the courier is theirs. On the margins a kitchen actually runs on, that is most of the profit, and the guest ends up belonging to the platform rather than to the restaurant.
Kajapont is my answer to that. Every restaurant gets its own ordering page on its own web address, an installable dashboard the staff run service from, and a fixed monthly fee with no percentage taken. I designed and built the whole thing: the data model, the API, the authentication, the realtime layer, both storefront themes and every screen in the dashboard.
The backend is complete and verified, and the interface is close behind. There are no customers yet. Pricing, the onboarding flow and the trial are in place, and the product is being readied for its first restaurants.
Not public yet
I wrote the brief myself. Every restaurant I looked at had the same two options: hand a quarter of each order to a marketplace, or take orders by phone and lose the ones that come in while the line is busy. Kajapont is the third option, and the whole product follows from that single constraint, so the kitchen keeps both the money and the guest.
The guest orders in three screens, with no account and no app to install.
Prices are never trusted from the browser. The client sends item ids, option ids and quantities, the server recomputes the cart with the same shared function, and a mismatch comes back as a rejected order with a fresh quote instead of a wrong charge.
The kitchen runs the whole service from one board.
Both screens stay in step over server-sent events backed by database polling. Serverless functions share no memory, so an in-process event bus would have worked on my machine and nowhere else.
What the owner sees at the end of the week.
Decisions I would defend in a review.
Money is stored as whole minor units, never as a floating point number. Every dashboard query is scoped by restaurant id, because on a multi-tenant product that scoping is the security boundary and middleware is not. The storefront ships in two skins, a flat classic one and a playful brutalist one, from a single codebase and a single set of components. And the product sends no email at all: invitations, signup and password resets are one-time links the owner hands over in person, which removes a whole category of deliverability problems from a business that onboards its customers face to face.
| Layer | Choice |
|---|---|
| Framework | Next.js 15 · App Router |
| Language | TypeScript |
| Database | PostgreSQL · Prisma 6 |
| Auth | Own sessions (scrypt) · Google · Facebook |
| Realtime | SSE over database polling |
| Validation | Zod |
| Storage | Vercel Blob |
| Hosting | Vercel |
The business model is the same shape as the product: 19 990 Ft net per month for one restaurant, 29 990 Ft for two, and 9 990 Ft for each further one, plus VAT. Both plans include every feature, because a restaurant paying twenty thousand a month should never hit a wall inside the product. There is a 14 day trial after an in-person onboarding session, no card required.
Where it stands. The backend is implemented and covered by tests, the dashboard and storefront are built, and the remaining work is the last pass over the interface before the first restaurants are onboarded. Kitchen printing, NTAK reporting, card payment, weekly menus and SMS confirmations are specified and scheduled, not shipped. I would rather say that plainly than claim a finished product.