RestaPro Team

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.

After the interviews came scoping. The hardest decision for a new product is not what it is going to do; it is what it is not going to do. We wrote it on a sheet with three columns: "yes", "not yet", and "never".

The "never" column drove the most arguments. But it saved us months.

Before coding anything, we set ourselves a limit: 30 interviews with restaurant owners before opening the editor. Taverns, grills, cafés, a couple of fine-dining kitchens, a three-location franchise. No rigid questionnaire; coffee, a notebook, and two opening questions: "What tool do you use today?" and "What drives you up the wall every week?".

We thought we would walk away with a long, scattered list. We walked away with three sentences that repeated almost word for word.

In mid-2025 we sat down with an uncomfortable question: do we really need another tool for restaurants? The market looks saturated. There are reservation systems, POS terminals, loyalty programs. And yet, every time we walked into a kitchen or stepped behind a bar, the same thing happened: the screen the manager was using looked like it was built in 2010.

We have spent eight years building SaaS for other industries. The founder's partner runs a restaurant in the city center, so the testing ground was already in place. After many late dinners spent talking it over, the conclusion was that it was worth a shot.