Reune Digital
Reune Digital · 2024 — present · Head of Product · Design · Brand
Head of Product. The brand, the landing page and the design system are mine.
A management system for Brazilian restaurants, taken from an idea to a funded company. Orders, tables, till, stock, kitchen and delivery in one place, with five sales channels landing in a single queue.
Research first: more than thirty restaurants visited before anything was drawn. I am Head of Product, and the brand, the product design and the landing page are mine.
Reune is a management system for Brazilian restaurants: orders, tables, till, stock, kitchen, delivery and the books, in one place. It started in 2024 as an idea, went through research and a prototype, took investment, and is now a working SaaS product sold in four tiers. I set the direction and the standards, and I drew most of what a customer actually sees.
The company
- Started: 2024 (idea to funded company)
- Restaurants visited: 30+ (before the first screen)
- Screens: 74 (in the panel)
- Backend modules: 60+ (counted from the code)
- Decisions logged: 46 (across ten fronts)
- Plans: 4 (Essencial to Empresarial)
What the market looked like
Brazilian restaurant software was legacy. The systems worked, in the sense that they eventually produced a number, but they were built by people who had never watched a till at eight on a Friday. Dense grids, function keys, no thought given to who was actually holding the mouse.
That is a strange gap to find in an industry this large, and it is the whole reason Reune exists. The bet was not a better feature list. It was that a restaurant owner with no patience and no training budget would switch systems for one that simply made sense on the first day.
Thirty restaurants
Before anything was drawn, I visited more than thirty restaurants. Not interviews in a meeting room: kitchens, tills, service, the part of the evening where everything happens at once.
That is where the product actually came from. You cannot invent the moment a waiter retypes an app order into the till, or the argument at closing time about which channel the money came from. You have to stand there while it happens, and then design so it stops happening.
The four contexts
Almost every decision in the product depends less on the screen than on where the person is standing when they use it. Four conditions of use that cannot be compared to each other, and the split the rest of the work comes out of.
| Context | Device and condition | What hurts |
|---|
| Salão | Tablet, standing, one hand. Rush, noise, changing light, a finger rather than a cursor | Finding the right table in two seconds without mistouching |
| Caixa | Desktop, seated, queue waiting, money involved | Precision. An error costs money and trust |
| Produção | Large screen read from a distance, hands busy or dirty | Reading from far away and knowing what is running late |
| Gestão | Desktop or phone, outside the rush, long session | Trusting the number and taking it out of the system |
The classic mistake in this kind of product is to design everything for Gestão, who is the one asking, and ship it to Salão, who is the one using it all day.
Internal UX research, section 1
Five channels, one queue
The single decision the rest of the product hangs off.
iFood, 99Food and aiqfome bring in the delivery apps. Goomer and Wabiz bring the digital menu, the table QR code and the self-service totem. All of it lands in the same panel as the order taken at the table, tagged with where it came from. Nobody retypes an app order into the till, stock comes down the same way whatever the source, and the end of day adds every channel into one report.
States the product invents
The database stores what happened. An operation needs to know what is pending, and that is almost never a column. Four states that exist only because the product derives them.
- Table needs clearing. The backend has no such status: a table returns to available when the bill closes. The state is born in the front end, watching the transition from occupied-with-a-bill to free-and-empty, and it lives in localStorage so it survives a refresh. It fades on its own, so a forgotten table does not become permanent visual noise
- Table colour comes from the bill. The block colour is computed from open bills rather than the raw status field. Served is deliberately neutral, because a served table asks nothing of anyone and should not compete with one that is waiting
- Audit trail from timestamps. The audit screen reconstructs history from entity timestamps instead of requiring a log table that was filled in from day one. The backend resolves the entity name before the handler, so the trail says which user was deleted rather than users #365
- RFV by quintile of its own base. Recency, frequency and value are ranked against that restaurant’s own customers, not a fixed threshold. A neighbourhood place and an all-you-can-eat have incomparable visit rates, and a fixed cut would misclassify both
Where the software meets the kitchen
The part most competitors leave to the notebook next to the tablet: scales, buffet counters, ovens, paper.
- Scale over a serial port. Reads a real URANO POP-S live, with two separate tare values because they are two separate problems: the standing weight of the dish, and zeroing whatever container is on the plate right now
- Buffet lanes on a rotation timer. Cold and hot stations, each with a timer that says when the food needs checking. No till models this, and exposed food has a deadline
- Prep runs with the browser closed. Recipes can repeat on a schedule. A cron writes the stock movement whether or not anyone has the panel open, because kitchen prep happens at six in the morning
- Table timer as a business rule. It starts when the first order is delivered and orders are still outstanding, and clears itself when none are. What matters is how long the table has been waiting, not how old any single order is
- Stock labels in millimetres. The on-screen preview uses the same builder as the final PDF, so what you see is literally what prints. It fills what the system knows and leaves a blank line for what it does not, because a pen still works
Where an order is born
Several front doors into the same bill. The decision was to privilege none of them.
- A WhatsApp bot that reads a filled-in template. The parser tolerates accents and case, and matches each line against the menu in three passes: normalised equality, then contains, then starts-with. Unmatched items go back to the customer to resend. It deliberately avoids the normal ticket path, which demands an open till and a human attendant, because the bot has neither and has to work when the till is shut
- The floor map as a grid of targets. Explicitly not a floor plan. Large blocks coloured by state, sized to be hit quickly with a thumb on a tablet
- Customer lookup by phone. Search used to be by name only. The real case is answering the phone, where the caller says a number, not the name on file. Registering a new customer now happens inside the order rather than abandoning it
- Bulk entry at end of shift. Recognises that paper exists. Rather than pretending every order passes through the system live, it gives a fast way to reconcile the tickets that did not
- Availability that propagates. Pausing an item removes it from the digital menu, the PDF, the waiter app and the till, and makes order creation refuse it, including through the bot
What the marketplace owns
The most unusual decision in the system is a piece of restraint. A customer who arrives through iFood, 99food, Goomer, Keeta, WAbiz or aiqfome does not become a contact you can message. The marketplace owns that relationship, and the product says so out loud: the contact appears with the name and phone masked. You can see what they are worth, how much they spent, which channel and when. You cannot call them. Unmasking costs a few cents per contact.
The vocabulary is deliberate too. The word "lead" is kept away from this screen, because there is a separate Leads screen for imported people who have never bought. Calling someone with three purchases a lead would blur two different things in the head of whoever is using it.
The owner’s arithmetic
The calculator is the one screen that manages nothing. It replaces the paper an owner did the sums on before setting a price.
- Price with platform fees built in. Five tabs: selling price after commission, the same dish compared across channels, cost of goods, break-even, and the fees themselves. Comparing one dish across channels is the sum that decides whether being on iFood is worth it, and no till asks it
- Fees stored per restaurant. The built-in constants are market reference with a checked-on date, used for the first visit and the reset button, because marketplace commission is negotiated case by case
- Tax notes as drafts. An invoice can be saved without going to the tax authority and issued later from the list
- Reports built to leave. CSV export and a dedicated print stylesheet. The hypothesis is explicit: the manager does not want to look at the dashboard, they want the number out of the system and into an accountant’s inbox
- A billing banner that cannot be dismissed. It sits above the header and pushes content down rather than floating over it. A warning that scrolls away is not warning anyone
The system outside the tab
The premise that changes everything: during service the panel is in the background. The operator is in WhatsApp, in iFood, in another program. A notice that only exists inside the page notifies nobody, and for a while that was the bug. Orders arrived and nobody knew.
So alerts now run in three layers, including operating-system notifications that surface over any other window. The sounds are synthesised on the spot from a few oscillators rather than shipped as audio files, which means a different sound per event type and no downloads. That is information through the ear, not decoration: the operator knows what arrived without looking.
Design system and access
Less about pretty components, more about not deciding the same thing again on every screen.
- One home for chart chrome. Axis, gridline, tooltip, bar radius and width ceiling moved out of the screen that was already the de facto reference and into a shared module, so style divergence stops being possible by accident
- Every empty state has an exit. The same block had been copied into three screens with three different greys. A dead end with no action never lets someone find out the tool does that thing
- Skeletons instead of spinners. Analysis screens load into the shape the content will occupy, so nothing jumps in front of someone who is reading
- Visible focus, with one exception. A global focus ring, suppressed on form fields where it drew a second rectangle inside the one already there. Label and field association on the profile screen was missing entirely, which is a defect rather than pending polish
- Permission per tab, not per screen. Screens with internal tabs now check tab by tab. Existing groups would have locked current customers out on the switch, so the profiles had to be backfilled before release
- Front-end permission is a navigation map. It is declared in the file as navigation, not as protection. Anyone calling the API directly is stopped by the backend guard, which is where the rule actually holds. Confusing the two is the classic hole: hide the button, leave the route open
The method
The least visible part, and probably the most durable: the product records why each decision was made, including what was wrong before and what is still unresolved.
- Comments explain the decision. The header of each file describes the problem that existed and what was deliberately left out, rather than restating the syntax below it
- Hypotheses marked as hypotheses. The research document separates what was observed from what was assumed, and closes with a section saying plainly that none of it has been watched with a real user of this product yet
- Risks declared before anyone complains. The heuristic review lists what should break, ordered by risk rather than by effort. An export button that opens a print dialog is first, because it promises a file and delivers something else
- Instrument before shipping. Baselines are defined ahead of the change: time from free table to order created, share of orders with an identified customer, drag error rate measured as a move undone within five seconds
The most reliable signal is not what someone says in a test. It is what they do when they think nobody is watching. For example, still using the notebook next to the tablet.
Internal UX research, section 4.4
What is still open
Carried over from the internal review rather than tidied away, because these are the ones a usability test should go after first.
- Export to PDF. The label promises a file and opens the browser print dialog. First candidate for testing
- Colour on the floor map. Colour is the main carrier of meaning. There is an icon and a short label to soften it, but the research marks this as needing to be checked with a user rather than assumed
- Missing print client. Without QZ Tray installed the message needs to say what to install
- Automatic tax issuing. A failure is swallowed into a log. The manual path is the reliable one and stays recommended until the automatic one reports on screen
The pricing ladder
Four tiers, priced annually, each one gated on what a restaurant of that size genuinely needs rather than on arbitrary limits. Getting this ladder right is product work, not a spreadsheet exercise.
| Plan | Monthly, billed annually | For |
|---|
| Essencial | R$ 242,99 | Small operations that need the basics without complexity |
| Profissional | R$ 341,99 | Restaurants expanding, with more visibility and control |
| Premium | R$ 467,99 | Larger operations, from the order through to the till |
| Empresarial | On request | Chains and franchises needing a bespoke setup |
Annual billing carries a 10 per cent discount. The top tier adds WhatsApp conversations, a self-service totem, audit, and market and popularity analysis.
The brand
I designed the wordmark: REUNE with the U replaced by a red circle holding a fork and knife. White ground, charcoal text, one red doing all the shouting.
- Primary red #D81F1F: Logo mark, buttons, accents
- Landing accent #C91818: The red as it ships on the site
- Charcoal #1E1E1E: Text and dark bands
- Section ground #F6F6F4: Light sections against white
The landing page
Designed and built by me, in Portuguese, at reunedigital.com. It has to do sales work, not just look like a product site.
- Live product in the hero. The dashboard is shown running rather than described, so the first thing a visitor sees is the thing they are buying
- The integrations section. Argues the one-queue idea directly, since that is what competitors cannot match
- Eleven niche pages. Pizzaria, lanchonete, hamburgueria, delivery, doceria, açaí, bar, marmitaria, japonês, franquias, each aimed at how that owner searches
- A working blog. Practical pieces on pricing a dish, closing the till and marketplace versus own delivery, written for the owner rather than for the algorithm
What I do here
This is the project where the roles stopped being separable.
- Head of Product. Direction, roadmap, scope and the calls about what ships and what waits
- Design. The product itself, the design system behind it, and the standards the team works to
- Brand. The logo, the palette, the voice, and being the face of it publicly
- Front-end. The landing page is my design and my code
Open the landing page
SaaS, Product Strategy, Research, Brand, Front-end