Skip to main content

The first commit and the rule that governs every screen

RestaPro Team
Product & Platform

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.

The golden rule​

It is written verbatim in the repository's README:

If a screen needs explanation, it is wrong.

It sounds obvious. It is not. Most management software we have seen requires a 30-minute onboarding call with a sales rep. That is not because restaurant owners are slow: it is because the product is opaque. Confusing labels, flows that fork without warning, buttons that say "OK" when they should say "Confirm reservation".

The rule forces us into several things:

  • Explicit text on buttons. No bare "Save". "Save menu", "Save table 12", "Confirm changes".
  • Empty states with instructions. When a screen is empty (no reservations, no dishes, no customers), you do not see a sad gray box. You see what you can do and a clear button to start.
  • Tooltips only for extreme cases. If you need a tooltip, the design is probably wrong and the flow needs rewriting.

What was in that first commit​

The first commit was not impressive. It had:

  • A folder structure with features/ per domain (auth, dashboard, reservations, menu, customers).
  • The skeleton of authentication against Supabase.
  • A working, ugly login screen, but enough to get going.
  • A layout component with the restaurant switcher up top.

And not much more. The point was not the code; it was that there was finally a place to write it.

What changed once we started typing​

There are decisions you can only make while coding, not before. Some that surfaced in the first weeks:

  • The menu editor had to support drag-and-drop blocks. In Figma it looked great; in code it took us two attempts to make it decent.
  • Reservation status was not four states, it was seven. Three more interviews were needed to confirm it.
  • The restaurant switcher could not reload the page: it had to keep the context of whatever you were doing.

How we measure if the rule works​

When someone outside the team tries a screen for the first time, we do not explain anything. We sit them down and watch. If it takes more than five seconds to figure out what to do, that screen does not pass. We rebuild it.

That practice keeps saving us today.

ESENCA