Internal notes on customers​

Every customer card in the CRM now has an Internal notes field. Only you and your team see it, never the customer. Use it for:

• Allergies and preferences ("red wine crianza, no dessert").
• Heads-up notes ("the husband always pays, not the wife").
• Context ("neighborhood VIP, attend personally").

It shows up on the customer card in Live service and on the reservation edit screen, so you see it before they arrive.

Allergen filter on the public menu​

Your guests can filter the menu by allergen (gluten, lactose, nuts, shellfish, eggs…) directly on the public page. You set them per dish when editing the menu. It is optional. If you flag none, the filter does not appear.

Wiki at wiki.restapro.es​

You are reading it right now. It is our public knowledge base with:

• Step-by-step guides for every product feature, written for restaurant owners (no technical jargon).
• FAQ with the 20 most common questions.
• Changelog (this one).
• Search that matches across all content.

And the Help button in the app's sidebar opens this wiki in a new tab. Pinche, the AI assistant, also uses it: ask "how do I do X?" and it searches here and returns links.

More in the wiki introduction.

What it does​

From Reservations → Pause online reservations you can block new reservations for a specific shift (breakfast, lunch, dinner, or the whole day) on a given date. The pause expires automatically when the day changes: if you do not resume it, tomorrow your site accepts reservations again on its own.

Why it matters​

• You do not touch hours or settings. The permanent configuration stays intact.
• The restaurant owner keeps creating internal reservations (walk-ins, calls, VIPs) during the pause.
• The guest sees a clear message: "At capacity, we'll see you without a reservation" with a button to call the restaurant.

Difference from extended closure​

More detail in the full service pause guide.

Security​

• JSON-LD escaping on the public menu to block injections from exotic dish names.
• Validation of external URLs before showing them on public pages.
• Image upload now rejects SVGs and caps size at 5 MB. Previously you could sneak in a scripted SVG.
• Public edit token signed with HMAC: nobody can edit someone else's reservation, even if they guess the ID.
• Idempotent Stripe webhook: if the same event arrives twice (Stripe sometimes retries), it only applies once.
• Rate limiting and access guards on six Gemini functions to prevent cost abuse.
• Roles: workspace-member-upsert no longer allows escalation to owner from a lower role.

Performance​

• Admin overview stopped doing N+1 when listing restaurants (it was one query each; now a single one).
• Sentry lazy-loaded: only loads when needed, not on every visit to the public home.
• date-fns in small bundle instead of the full package, saving about 80KB per load.

Resilience​

• Frontend auto-reload if a chunk preload fails after a deploy: the user does not see a broken screen, it reloads on its own.
• Snapshot of dist/ plus a quick rollback script to revert to the previous version if a deploy goes sideways.
• Reminders now respect the restaurant's time zone (they used to send in UTC and sometimes ran an hour early).
• Public stats cron rescheduled so it does not collide with backups.

If something felt slow or odd and you notice it no longer does, this was it.

"Events-only" workspace​

Not every business needs standard reservations. Some customers (catering, wedding venues, private event spaces) handle only group events. For them we built an events-only workspace mode:

• During setup, they pick "I only manage events" instead of the reservations flow.
• The Live service and Reservations screens are hidden.
• Group events becomes the main screen.
• Templates and emails adopt the language of events (quote, deposit, event date, expected number of guests).

If your business fits this, write to us at support@restapro.es and we will enable the mode. It is not a public toggle yet; we prefer to talk to each customer to fine-tune.

Redesigned landing​

We rewrote https://www.restapro.es from end to end:

• Real reservations counter instead of made-up numbers.
• Transparent comparison against TheFork: prices, commissions, what each one does better.
• Live demo showing the service screen without requiring signup.
• Wider layout (1536px) with condensed blocks; reads better on a large monitor without losing density.

If you were taking someone to the site to explain RestaPro, the conversation is now shorter: less jargon, more real screenshots.

Why we removed TheFork​

We learned this the hard way: when RestaPro was the source of the reservation, data was consistent and emails arrived on time. When a reservation came from TheFork, there were two sources of truth: sync drifted, reminders duplicated, and restaurant owners got complaints from guests receiving two confirmations for the same dinner.

The decision was: either fix it properly (weeks of work) or remove it. We chose to remove it and simplify. If you need TheFork, we still ask customers to keep it running in parallel and reflect those reservations as walk-ins in RestaPro.

If you still had a restaurant connected to TheFork, past reservations stay in history and new ones stop syncing. We flagged it via email and a backoffice toast.

Five UX sprints on live service​

After launching Live service, we ran weekly sprints to polish what you only feel when you actually use it:

• Sprint 1. Quick wins: tooltips, keyboard shortcuts, responsive layout on tablet.
• Sprint 2. General UX: copy review, clearer separators, visual weights.
• Sprint 3. Operational efficiency: fewer clicks to reassign, quick access to "mark arrived", critical-table highlighting.
• Sprint 4. Guest context: VIP badge and no-show counter visible at a glance.
• Sprint 5. TV view (mode for the dining-room display) and sound on new incoming reservation.

If you have not opened this screen in a while, try it now. It is a different thing.

More in the reservations guide.

Guests edit their reservation from the email​

The confirmation email your guests receive now includes an "Edit or cancel my reservation" link. When they tap it:

• They land on a simple screen on your public domain.
• They can change the time within available slots, or cancel.
• No account, no password to remember.

The link is signed with a unique token. No one else can touch the reservation, even if they know the ID. We covered the edge cases.

Alerts to multiple emails​

Until now, new-reservation alerts went to a single inbox. Now you can define multiple recipients in Settings → Alerts:

• You (you@restaurant.com)
• The floor manager (floor@restaurant.com)
• Anything else (a Slack-via-webhook-to-email bridge, a group, etc.)

If you set more than one, all of them get the alert at once.

Real-time toast​

If you have the backoffice open, when an online reservation comes in a toast appears in the corner ("New reservation: 2 people, 21:00"). No reload, no waiting for sync. It is realtime via Supabase, so it is instant.

Duplicate detection​

If the same guest tries to book twice for the same day (typical when the form double-submits or a request hangs on the network), RestaPro detects it and warns before inserting a duplicate. The backoffice flags it too.

More in the reservations guide.

What it does​

• Floor plan with the live status of each table: free, occupied, walk-in, blocked.
• Drag and drop to reassign reservations to tables during service. If capacity is tight, the system warns you before you drop.
• Flexible walk-ins — the big button to seat guests without a reservation, adjusting capacity on the fly.
• Service banner in the header with a summary of how the day is going (occupancy, upcoming reservations, alerts).
• Table blocking with a reason: "broken table", "reserved for a group at 22:00", "boss's birthday".

Who it's for​

For the floor manager and the shift lead. It is the screen open on the tablet behind the bar throughout service. No technical text, no training needed: if you have worked the floor, you get it instantly.

How it fits with the rest​

• Reservations is still where you do background management (create, edit, cancel).
• Live service is where you operate during the shift.
• Both screens look at the same database in real time, so there is no sync drift.

More in floor plans and the reservations guide.

Breakfast as a service shift​

Until now the service shifts were lunch and dinner. If your business opens for breakfast, there was no clean way to separate the morning service from the rest. Now breakfast is a shift in its own right:

• You enable it in Settings → Hours by setting the time range (typically 8:00–12:00).
• It has its own configuration (capacity, slots, assigned tables).
• Online reservations show it as a separate shift on the public page.
• Emails and automations can filter by shift: "send a promo only to breakfast guests", for example.

If your restaurant serves breakfast, you can finally separate it from lunch without workarounds.

Slots up to the last configured reservation​

There used to be a subtle behavior: if your last dinner hour was 23:00, the last bookable slot was 22:30 (because we left an "automatic" buffer). Result: people who wanted to book at 23:00 could not, even though your restaurant was actually accepting guests then.

Now slots run all the way to the exact time you configured. If you say the last hour is 23:00, 23:00 is selectable.

If you want to leave a buffer, you set it explicitly by changing the last hour to 22:30. More control, less magic.

New public menu​

The menu your guests see (through the QR or at restapro.es/r/your-restaurant) now:

• Truly responsive: reads the same on an iPhone SE as on an iPad.
• Accessible: keyboard-navigable, sufficient color contrast, screen readers handle it.
• Allergen filters: guests can filter by gluten, lactose, nuts, etc. You configure the data per dish when editing.
• Contextual empty state: if filters return nothing, suggestions to widen the search.

Group event proposals​

Your public page now shows a "Book for a group" button when someone wants to come with a large party. The guest:

1. Fills in a short form: date, party size, type of event, notes.
2. The proposal lands in your backoffice; it is not a confirmed reservation.
3. You approve, decline, or reply with a quote / alternative availability.

For large reservations (15+), this is a far better flow than a standard online reservation: it gives you time to coordinate with the kitchen, set a menu, request a deposit, and so on.

More in the group events guide.

Other small things​

• Reservations embed without a cookie banner (you handle it on your own site, no duplication).
• Deleting a reservation no longer requires typing exact confirmation text, just a button.
• Action tracking for the restaurant owner: we now know which screens you use and which are orphans, so we can polish them instead of guessing.

Pinche on Gemini 2.5 Flash​

Pinche now runs on Gemini 2.5 Flash instead of 2.0. You will notice it in:

• Speed. Responses start appearing about 30% faster.
• Reasoning. Better when you ask things like "what menu change would have the biggest impact on average ticket?" or "explain this to a new server".
• Cost. Equal or lower for us, so it does not affect your bill.

The change is transparent. Pinche still answers in Spanish, with the same management tools.

Centralized logs​

Errors from edge functions used to live in six different places: Supabase, Sentry, local nginx logs… Now they all flow into a single #logs channel via n8n:

• Any error or warning from any serverless function lands in Slack within seconds.
• If your restaurant shows odd behavior and you email us, we correlate it with the logs from that exact moment.
• We automatically filter out known noise (expected timeouts) so we do not spam the channel.

It affects you indirectly: when something breaks in production, we see it in minutes instead of hours.

Sentry tunnel via /m​

Some ad blockers block Sentry's domain outright, leaving us blind to frontend errors. Now the frontend sends errors to /m (a same-origin proxy on our nginx) that forwards to Sentry.

Result: we see 100% of the errors happening in the browser, even from users on aggressive uBlock Origin.

How they're built​

In Marketing → Automations, you pick:

1. Trigger. When the rule is evaluated: reservation created, reservation confirmed, reservation completed, customer hits X visits…
2. Conditions. As specific as you want: day of week, time slot, party size, source channel, first visit or not.
3. Template. Which email is sent. Five or six templates ship ready (thanks, reminder, win-back, discount code, first visit).
4. Delay. When it goes: immediately, 4 hours later, the next day, a week later…
5. Cap per customer. So you do not spam: maximum X emails from this rule per person.

Typical cases already running​

• "Thanks for your first visit" with 10% off the next one — for new guests.
• "We miss you" to guests who have not been back in 3+ months.
• "24h reminder" only for large reservations (8+) or for Friday and Saturday.
• "Happy birthday" a week early with a treat from the house.

Live preview + test email​

While creating the rule, you can see it rendered and send yourself a test email before activating. Spares you the embarrassment of an unresolved placeholder landing in a guest's inbox.

More in the automations guide and the campaigns guide.

Kiosk mode at /app/local​

If you have a tablet or small monitor behind the bar to run service, open /app/local. It is Live service in clean mode: no sidebar, no distractions, all the space for tables and reservations.

It works well on a horizontal tablet and on small wall-mounted screens. The idea is for it to become part of the restaurant's digital furniture, not something you open and close.

Description on menu categories​

In the menu editor, each category can now have a descriptive subtitle. Useful for:

• "Starters to share" → text: "Designed for 2-3 people, we bring bread to the center of the table"
• "Desserts" → text: "Made in-house every day"
• "Wines by the glass" → text: "A rotating seasonal selection, ask your server"

It appears on the public page below the category name. Adds texture without clutter.

Density pass​

We tightened density in these areas:

• Settings: shorter headers, reduced padding; long forms now fit on one screen.
• Reservations: thinner rows, better-balanced columns for lists of 100+ reservations.
• Dashboard: more compact cards; it used to take more space than it earned.
• General chrome: thinner top bar, sidebar with adjusted padding.
• Menu capacity and filters: less air between controls.

Result: 25 to 40% more information fits without losing legibility.

E2E smoke tests + public i18n​

Technical bonus: we added end-to-end smoke tests in GitHub Actions that test login + create reservation + view public menu on every commit. If a change breaks any of those flows, the commit does not merge.

Visual table editor​

In Settings → Tables you no longer need to list tables by hand. You get a canvas where:

• You drag tables from a palette (square, round, long).
• You assign minimum and maximum capacity.
• It supports multiple floors (terrace upstairs, dining room downstairs, private rooms apart).
• Each table has its zone and can be shown or hidden in online reservations.

When a guest books online, we see graphically which table is free directly on the reservation card, and we can assign it with one click.

Multiple menus per restaurant​

If your business has a lunch and dinner menu, daily special, weekend brunch… all of that fits in RestaPro now. Each menu:

• Has a name and a type (lunch / dinner / daily special / breakfast…).
• Appears as a tab on your public page and in the QR.
• Can be activated or deactivated per service without touching the others.

The menu editor switches between them with a selector at the top. It is the same screen, multiplied.

More in the tables and seats guide and the menu editor guide.

New public landing​

We rewrote restapro.es end to end. The big calls:

• "For restaurant owners" block at the top, not for investors or journalists.
• Real screenshots of the app, not Figma mockups.
• Visible pricing, no "contact sales". What the page says is what you pay.
• Transparent comparison with TheFork and Resy.

Complete legal pages​

restapro.es/legal now also includes:

• Cookie policy with a specific breakdown of which we use and which we do not (we run no third-party analytics on public pages).
• Legal notice with tax ID and registered address.
• Terms of service for end users (the guests who book).
• Personal data policy with clear GDPR rights.

Billing with Stripe portal​

If you pay for RestaPro, in Workspace → Billing you will see a "Manage subscription" button that takes you to the Stripe Customer Portal:

• Change payment method, download invoices, view history.
• It is Stripe's portal, not one we built. Card data never passes through RestaPro.

Security hardening​

A serious pass under the hood (invisible, but you feel it):

• Rate limiting on public endpoints so no bot can take down a restaurant's page.
• Strict input validation on public forms.
• CSP (Content Security Policy) tightened to limit which scripts can run.
• Security headers in nginx (HSTS, X-Frame-Options, X-Content-Type-Options).
• Webhooks signed with rotatable secrets.

Review marketing + test coverage​

As a bonus: we shipped the review marketing flow integrated with Google and pushed test coverage up to 72% to reduce regressions.

Discount coupons​

If you are running a promotion ("first month free", "20% for grandparents with family"), you can now create coupons from the panel and share the code. They apply at Stripe checkout and disable themselves on expiry.

Plan cancellation with reason​

If a restaurant owner decides to cancel, we ask for a reason in a short survey before processing the cancellation. Three benefits:

• The plan goes into pause, taking effect at the end of the period.
• We learn why you are leaving. It is more useful feedback than any anonymous NPS.
• If the reason is something we can fix (price, a specific feature), we reply by email before the cutoff.

AI assistant for marketing emails​

When creating a campaign in Marketing → New campaign, there is now a "Generate AI draft" button. You give it three things:

• Who it goes to (new guests / regulars / VIPs)
• What you want (fill Tuesdays, announce a new menu, win back lapsed guests)
• Tone (friendly, formal, playful)

It writes you a subject line, body, and CTA. You edit, make it your own, and send. Much faster than starting from scratch.

Public-page telemetry​

As a technical bonus: your public reservations page now counts views. It shows up in analytics so you can see whether SEO or ads are paying off.

How it works​

1. Pick a pre-made template (thank you + ask + direct link to your Google listing).
2. Set the delay (typical: 4 hours after the reservation, when the guest is back home with a coffee).
3. Activate the rule and RestaPro sends the email each time a reservation is marked completed.

The guest opens the email, clicks, lands on your Google Business profile, and leaves the review in under 30 seconds. If they say no or ignore it, nothing is lost. The guest about to complain usually does not respond to these emails anyway.

What makes this work well​

• 24h marketing block post-visit: if the person already received an email from you (reminder, confirmation), nothing else goes out the same day. No one feels stalked.
• Unsubscribe respected. A guest who opts out gets no more marketing emails, first time, no questions.
• Real tracking. The Google reviews dashboard shows how many reviews came in through this flow.

More detail in the review request guide.

What we shipped​

• URL importer. In Menu → Import from web you paste the public URL of your menu and RestaPro reads titles, descriptions, prices, and categories. You then review and fix whatever is needed.
• Import from Google Places. During restaurant setup, if it finds your listing, we pull phone, address, hours, and cover photo in one go.
• Copy hours to clipboard. A quick button to take your RestaPro hours to your website, social, or a printed sign.
• Quick actions on the dashboard. Three buttons to create a reservation, mark a walk-in, and open the menu without navigating the menu tree.

Why it matters​

Initial setup is where people drop off most. Reducing the time to "first dish visible on my page" from an hour to five minutes is the difference between starting to use RestaPro today or putting it off until next week (which almost never comes).

Take a look at the restaurant setup guide and the digital menu guide for the details.

Team roles​

In Workspace → Members you can invite people with three levels:

• Owner (you). Full control. Only one owner allowed.
• Admin. Manages reservations, menu, settings; cannot touch billing or delete the restaurant.
• Staff. Sees and manages reservations, marks walk-ins; no access to marketing or settings.

Every backoffice action respects those roles automatically. If a staff user tries to enter billing, they see a clear message instead of a technical error.

Profile editing + avatar​

In your account you can now change your name, photo, and email. Photos upload to a private bucket (not public), with RLS policies that only let you touch your own.

Public legal page​

restapro.es/legal with privacy, terms, and legal notice ready to go. If your advisor asks you to link them from your own site, they are already published.

More in roles and permissions.

What this v1 includes​

• Online reservations with a public page per restaurant (restapro.es/c/your-restaurant).
• Reservations backoffice to handle day-to-day work (create, edit, cancel, mark arrival and no-show).
• Digital menu with a public QR (restapro.es/r/your-restaurant).
• Dashboard with the day's overview.
• Auth with email + password.
• Multi-restaurant from day one: a workspace can hold several locations.

Philosophy​

RestaPro is built around three principles we will defend on every feature:

1. Spanish first, no shortcuts. No i18n, no English placeholders. Every word is written for someone who runs a kitchen, not for someone who runs APIs.
2. The restaurant owner should not have to read documentation to use the app. If a screen needs explaining, the screen is the problem.
3. The data belongs to the restaurant. CSV export, full deletion with one button, no lock-in.

Welcome. If you have spent time in hospitality and something does not match how you work, write to us. RestaPro is the youngest tool on the market, and that is exactly why it can change fastest to fit you.

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.