Side is a local café and wine bar. It is also the first tenant of a product that did not exist when the project began.The original brief was concrete: create the brand, design the public website, and give a real venue a simple way to accept reservations. But once the work moved beyond the homepage, the shape of the problem changed. What looked like a custom hospitality website was really the beginning of a reusable reservation and venue-management system.
ProjectSide
VenueCafé and wine bar
RoleFirst tenant
FoundationOnce UI
Starting with a real place
Side was not invented to demonstrate a booking product. The café already existed, with its own atmosphere, daily operation, and customers. The digital work had to begin with that reality.
The public experience needed to feel warm, elegant, and distinctly Side: ivory and beige surfaces, black editorial typography, sculptural interiors, and a visual identity that could move naturally from daytime coffee to evening wine. The Hungarian-first website brings together the venue, its story, menu, and reservations without making visitors learn a new interface.
That part of the project is intentionally bespoke. Side should not look like a software template wearing a café logo. Its brand, content, and customer-facing experience belong to the venue.
The brief became a system
A reservation form is easy to draw. The system around it is where the real product begins.A venue needs to receive a request, understand when the guest is arriving and how many people are coming, decide whether the booking can be accepted, and keep the answer connected to the reality of the room. Once those decisions need to happen every day, the project is no longer only a website.The scope expanded from a public reservation flow into the foundations of a venue-management product: a reusable application for handling bookings and the floor behind them. Side became its first tenant—not a fictional demo account added after the software was built, but the real environment shaping what the software needs to become.This distinction matters. Features are not being chosen from an abstract SaaS checklist. They emerge from a venue that already has customers, opening hours, tables, staff, and an operating rhythm.
Build the specific thing, keep the reusable layer
The project has two layers.The first is specific to Side: the identity, the public website, the language, the tone, and the way the venue presents itself. These should remain recognizably theirs.The second is reusable: the reservation logic, management interface, floor-management patterns, Once UI components, and the underlying platform technology. Those can become infrastructure for the next café or restaurant without turning every venue into the same brand.That separation changes the economics of custom work. A few months ago, this level of effort could buy one tailored website. Now it can buy the website and help create the software behind the business. The first client receives something shaped around a real operation; the next client benefits from a system already tested by one.
One foundation for the guest and the operator
Once UI made it practical to treat the public website and the management application as parts of the same product without forcing them to look identical.
On the guest side, the system provides the layout, typography, responsive behavior, localization patterns, forms, and interaction primitives needed for a polished hospitality website. The brand can stay restrained and editorial because the structural decisions are already handled.On the operator side, the same foundation can support denser application patterns: booking lists, status controls, date and time inputs, tables, panels, and the navigation required for day-to-day management.The value is not that the café website looks like a dashboard. It is that both surfaces can share a reliable design and engineering language while being composed for completely different jobs.
Designing from use instead of assumption
Side is an early-stage product story, not a finished scale story. The reservation and floor-management system is still being built, and its first meaningful test is whether it works for the venue that caused it to exist.That is an advantage.Starting with a real tenant creates constraints that a concept cannot supply. The interface has to make sense during service, not only in a product screenshot. The booking flow has to feel simple to a guest who does not care what software sits behind it. The system has to respect the venue's existing habits before asking the venue to adopt new ones.
Every piece of friction can become product knowledge. Every repeated manual step can become a candidate for the reusable layer. And every venue-specific request tests whether the platform has found the right boundary between configuration and custom work.
From a project to a product
Side shows a path from service work to software that does not begin with inventing a market in isolation.Start with one business. Solve its actual problem carefully. Keep the identity specific, extract only what deserves to become infrastructure, and let the first tenant shape the system before trying to sell it to the hundredth.The result is more than a café website and more grounded than a generic reservation prototype. It is a real venue becoming the first chapter of a reusable product—built with Once UI from both sides of the counter.
Updated by lorant.one 22 days ago
