3Smiles is in production. The marketing site is live at 3smiles.eu, the restaurant back office at app.3smiles.eu, and the Azure infrastructure is running with real subscriptions, real transactional e-mail and real restaurant data. It is the first business application FlorisNexus has delivered that is not a showcase website — and a good occasion to describe honestly what such a project takes.
The problem: a trivial request costs a walk across the room
In a restaurant, most guest requests are tiny: the bill, a jug of water, a missing fork. The cost isn't in doing them — it's in transmitting them. A guest raises a hand, tries to catch an eye, waits. A waiter crosses the room just to hear the request, then crosses it again to fulfil it.
So the starting point was this: there is no direct channel between the table and the team. With three non-negotiable constraints. No hardware to install — the button box sitting on every table is a competitor's answer, not ours. Nothing for the guest to download — a restaurant cannot ask a couple in their thirties to install an app to order water. And above all: do not replace human contact, just spare it the pointless round trips.
What 3Smiles actually does
Every table carries a QR code. The guest scans it with their phone camera — no install, no account, no password — and lands on a screen listing the services this restaurant offers. They pick one. The waiter responsible for that area receives the request instantly, on a tablet or phone, with the table number.
It is not an online menu, and there is no food ordering: the product solves the call channel, not the order taking. Behind it, the owner gets a full back office: establishments, areas (terrace, main room, upper floor), tables, the list of services they want to offer, team members, and their subscription. All of it in three languages — French, English and Dutch — because a Belgian restaurant serves all three in a single evening.
Why this was not a showcase website
We published a guide comparing showcase websites and business applications. 3Smiles is the textbook case of the second, and the boundary shows in four signs.
There is state to maintain. A service request is created, taken on, completed or cancelled. A guest session opens on scan and closes later. A showcase site remembers nothing.
There is real time. A notification that arrives thirty seconds late is useless: the guest has already raised a hand.
There are several customers inside one product. Each restaurant is a tenant that must never see another tenant's data.
There is money. A monthly or annual subscription, failed payments, invoices, VAT.
Each of those four points multiplies the work compared to a showcase site. That is why "website or application?" is not a vocabulary detail: it changes the budget, the timeline, and what has to be maintained for years.
The technical choices — and what each one protects
3Smiles runs on .NET 10, with a guest front end and a back office in Blazor WebAssembly, real time over SignalR, a single Azure SQL database, and Azure infrastructure fully described in Bicep. None of it is fashion; each choice protects something specific.
SignalR rather than periodic refreshing: the request reaches the waiter's screen within seconds, without the app polling the server for nothing.
One database, isolated by tenant identifier rather than one database per restaurant: isolation filters are applied globally at the data access layer, which makes "forgetting to filter" genuinely hard — and lets us deploy once for every customer.
Microsoft Entra External ID for identity: no passwords or tokens stored by us, MFA available, and an attack surface delegated to Microsoft instead of rewritten in house.
Stripe for subscriptions: no card data ever passes through the application.
Bicep for infrastructure: production is described in a versioned file, with a separate test environment alongside it. That is what makes it possible to test an infrastructure change without experimenting on a restaurant that is mid-service.
Belgium first, then Europe
3Smiles starts on the Belgian market: that is where the first restaurants are, and it is the market the project owner knows. But the product is not built to stop there — and that shows in the architecture, not in a pitch. A single multi-tenant instance serves every customer, so one more country is not one more deployment. The interface is trilingual from day one, because retrofitting languages later is the most expensive version of the exercise. Stripe bills in more than 40 countries. And because the infrastructure is described in Bicep, it can be redeployed in another Azure region without being rewritten.
The order is deliberate: prove the product in a Belgian dining room, then expand across Europe — and why not further. Products that try to address the whole world on day one usually convince no one in particular.
What the floor changed about the product
The most instructive part of the project isn't the architecture — it's the list of things no specification had anticipated.
The order of the areas. The area list was sorted alphabetically. Consequence: an owner whose main room is called "Terrace" always saw it in the last column of the waiter screen, with no way to move it up. An owner-defined order had to be added.
Arrows, not drag and drop. To reorder that list, the developer reflex is drag and drop. Bad idea: the matching events never fire on touch in most mobile browsers, and this back office is used on a tablet, standing up, on the floor. Two arrows do the job and work everywhere.
Rescanning the QR code. A guest rescans the code halfway through the meal, or the person next to them scans the same table. Session and request lifecycles took several passes before they were right in all those cases.
The declined payment. An expiring card must not cut off a restaurant's service in the middle of a busy evening: a grace period was added to billing. The right technical answer to a failed payment is rarely "block immediately".
Going into production is not the same as deploying
This is the lesson I take away most from the project. The code had been working for a long time when the production launch began. What actually filled that phase was invisible to users:
A dedicated sending domain. Invitations were going out from an auto-generated Azure address — exactly the kind of sender a restaurant owner files as spam without opening. Moving to an address on the client's own domain required a dedicated subdomain and clean e-mail authentication DNS, so as not to break the existing professional mailbox.
The back office kept out of search engines. The application had neither a robots.txt nor an equivalent header — and the absence of that file allows crawling rather than forbidding it.
Security headers that are actually served. The showcase site's headers were correctly written but never served in production, because the configuration file was not inside the published folder. Written ≠ deployed: you have to check against the production URL.
Sizing and migrations. Moving production onto the right hosting tier, and making sure a database migration cannot be applied to production ahead of time.
The legal foundation. Terms, privacy policy, legal notice and a data processing agreement in three languages, with timestamped, versioned acceptance on the manager's first sign-in. On a product that processes data on behalf of other businesses, that is not an end-of-project formality.
None of this shows up in a demo. All of it blocks a real launch. If a supplier tells you a business application is "finished" without having discussed these subjects, it isn't.
What we measure, and what we don't have yet
The 3Smiles site is measured like all our projects, in production, with Lighthouse: 97 performance, 97 accessibility, 100 best practices and 100 SEO on desktop; 86, 96, 100 and 100 on mobile (median of three runs, 10 August 2026). We publish those numbers raw, including when they are unflattering, on our portfolio page.
What we will not publish today is usage figures: waiting time saved, requests handled per service, guest satisfaction. The product has only just entered production. Those measurements will exist once they have been observed on the floor, over several weeks — not before. An invented or extrapolated number is exactly the detail that discredits everything else in a case study.
What this project says about yours
If you are self-employed, a shop owner or an SME manager in Belgium, and you have identified a specific friction in your trade — a call that never reaches the right person, information retyped three times, a schedule kept on paper — three lessons from this project apply to yours.
Start from the friction, not from the feature. 3Smiles does not do "everything a restaurant might want". It removes one round trip. A narrow, genuinely useful scope ships; a wish list never does.
The floor always beats the mockup. The most important corrections in this project came from a tablet held in one hand in a dining room, not from a meeting.
Budget for the invisible phase. Domains, e-mail, security, GDPR, billing: put it in the timeline from the start, or it will push your launch back by weeks.
And one last thing FlorisNexus does not compromise on: the infrastructure and the accounts stay in the client's name. The 3Smiles Azure subscription belongs to the project owner, not to us. You must be able to change supplier without changing product.