Built
- Four-language menu and public marketing website
- Service Radar and kitchen workflows
- POS and controlled payment test flows
- Distinct SQ metadata on three public pages
- Immutable release images and a scoped rollback
Pilot software · Public website updated on 31 October 20262026
FlowGastronomie
Restaurant software with one shared core and a public product demo
My role
Product architecture · Full-stack · UX · Testing · Deployment
flowgastronomie
Video11 Screenshots
01
Project overview
A venue can combine the table QR menu in four languages, Service Radar, POS, kitchen display, online ordering and its website on one core. Each venue chooses which functions it enables.
The public product website and a demonstration of Service Radar are available online. The software remains in pilot operation; fiscal LIVE and device acceptance are separate gates.
The October release gives the Albanian homepage, pricing page and Radar demo distinct browser titles and search descriptions. It leaves the large headings and visible page content unchanged.
A real Findbar case closes the correction loop: six duplicate browser-title/search-description fields were reviewed, implemented in Flow, checked privately, published with approval and checked again publicly. The new audit visited ten URLs and returned zero confirmed findings.
▶
Product walkthrough
02
Real product screenshots
Real product views, without mockups or stock imagery.
03
System architecture
Next.js
Guest, service, kitchen and owner interfaces
Fastify
Tenant-scoped application API
Domain rules
Shared operations and payment rules
PostgreSQL · Prisma
Persistent data and migrations
04
Project status
In active development
- Pilot validation and owner acceptance
- Fiscal and physical-device acceptance in their authorised environments
Planned
- Wider rollout after the remaining acceptance gates
05
Engineering decisions
Why one core?
Guest, service and kitchen views use the same operations data instead of keeping separate copies.
Why separate public website and pilot status?
A working product demo does not establish fiscal LIVE readiness or hardware acceptance.
06
Challenges solved
- 01Preserving existing business data during an application release
- 02Checking exact public page metadata without changing the visible page content
07
Technology stack
Application
- Next.js
- Fastify
- TypeScript
Data
- Prisma
- PostgreSQL
Delivery
- Docker
- GitHub Actions
- Vitest
- Playwright
08
What it demonstrates
A public product website with a working demo, plus a pilot application whose delivery and acceptance boundaries remain explicit.
Need a similar system?
I can design and build a solution around your workflow, team, and business goals.