If you already have your menu posted on your own site or on Google Business, RestaPro can pull from there instead of forcing you to retype it.

A round of "ergonomics and compliance": if you are about to give your manager or floor lead access, it is now one click. And if your advisors ask, you have a public legal page ready.

Today we are publishing the first version of RestaPro. It is the result of months thinking about what a hospitality management tool should feel like when it does not fight you.

By late February we had a beta running well with eight restaurants and a decision made: we open to the public on March 19. That left us about two and a half weeks. It feels short. It was.

We did not want a big-bang launch with horns and confetti. We wanted a calm launch: any restaurant owner could come in, sign up, pay, and start working without surprises. Sounds modest. Implies a long task list.

In January we went from three friends to eight restaurants. The selection was not random: we wanted variety. A Castilian roast house, two neighborhood cafés, a group with two Mediterranean kitchens, a burger joint, a Japanese place, and a bar with heavy walk-up traffic. Deliberately different profiles. If it worked for all eight, it worked for almost anyone.

The deal was clear and in writing: you pay €0 during the beta. In return, you tell us what's broken, and we fix it within 48 hours or explain why we can't.

In mid-December came the first moment of truth: showing the product to real restaurant owners, not friendly relatives who say it looks lovely. We picked three restaurant owners we already knew from the interview rounds, willing to get their hands dirty. We gave them access, a promise of bug fixes within hours, and a bottle of wine for the trouble.

A week later we had a notebook full of things to fix. The feeling was the one you always get with first users: you realize many things you took for granted were not obvious at all.

In late November we made the first real commit. Until then there were only loose prototypes, design explorations in Figma, and a stack of notes. The first commit was the equivalent of writing "page 1" on a novel we had been thinking about for months: exciting and a little intimidating.

The most useful thing about those six prior months was not so much what we learned about the industry, but a rule we decided to impose on ourselves before typing a single character.

One of the first things we noticed in the interviews was that many operations have more than one location. We are not just talking about big chains; we are talking about a family group with two grills and a beer hall, or a small franchise with three sites in the same city. If the software forces you to create a separate account for each one and re-enter the data every time, hating it comes free.

So in October we spent a couple of weeks on a topic that sounds internal and dull but defines the ceiling of the product: how we model the data.

September was the moment to pick the technology. In many projects this conversation drags on for months; we wanted to close it in a week. The question was not "what stack is best?" but "what stack lets two people move fast and sleep at night in production?".

The short answer: Supabase and nothing else to start. No servers of our own, no Kubernetes, no Java. The long answer is this post.

By August it was time to stop theorizing and start picking colors. A design system is one of those things that seems minor until you touch it: get it wrong and you drag it for years. So we sat down with a couple of designers and spent nearly three weeks on something the original plan had down as "an afternoon".

The question we got asked most by friends in the industry was: why a vibrant blue instead of the terracotta red or olive green you always see in hospitality? Let's break it down.