Skip to main content

The two weeks before opening the doors

RestaPro Team
Product & Platform

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.

What we closed in those two weeks​

Here are the big items that landed in the home stretch:

  • Automated HTTP smoke tests. A script (npm run smoke:http) that checks the critical routes return the right status code after every deploy. Nothing fancy, but enough to catch dumb regressions.
  • Minimal E2E coverage. Three critical flows verified manually before each release: full signup, public reservation creation, menu editing and publishing.
  • Complete legal page. Terms of service, privacy policy, cookie notice. We worked with a lawyer who specializes in SaaS to avoid copying dubious templates. Glossing over this was not an option.
  • Billing with Stripe portal. We did not reinvent the wheel: Stripe's customer portal handles subscriptions, payment methods, and invoices. We just integrated checkout and webhooks.
  • Security hardening. RLS policy audit, service-role review, secret rotation, alerts on 500 errors. The dull but essential stuff.

The day we almost broke the database​

There was a scare, of course. Four days before launch, a migration touched a large table and blocked queries for 90 seconds. In real production, that is an eternity. The beta noticed, but no one was doing anything critical at that moment. Immediate decision: from then on, no migration goes out without a written rollback plan reviewed by two people.

That rule still stands today.

What we left out on purpose​

The temptation to add "one more feature" before launch is enormous. We had to say no to several things:

  • Full dark mode. The styles were ready but not thoroughly tested.
  • TheFork integration. We knew we would do it, but not on day one.
  • Native mobile app. The responsive web covered 95% of cases.
  • Automated SMS marketing. Email first, SMS later.

All of that ended up shipping in the following weeks, as you can see in later posts on this blog.

The day before​

On the night of March 18 we activated payments in production, ran a final deploy, and let the smoke tests run. Zero errors. We closed the laptop with that strange feeling of having reached the starting line after running half a marathon. The actual launch, with its own stories, is told in the first post on this blog: "RestaPro opens its doors".

From that day on, RestaPro stopped being a project and started being a tool used by real people every night.

ESENCA