Bar do Bobi
Bobi Labs · personal build
Role
PM-builder · personal build
Duration
Ongoing, as a side project
Status
Live · one static file · no backend

The menu. Three filter cards, a carousel of drink ideas that each seed a real search, and 261 recipes underneath.
The problem
A home bar menu is a small problem with an interesting constraint attached. The content is genuinely useful (what can I actually make, in two languages, on a phone, standing in a kitchen) and the temptation is to reach for a framework, a database and a build pipeline to serve a few hundred recipes that change once a month.
The question worth answering was not how to build a recipe site. It was how much can be delivered without any of that, and where the honest ceiling of a single file sits.
The approach
One HTML file. 261 recipes across 13 categories in English and European Portuguese, with search, category and ingredient filtering, and a tracker that remembers what you have already tried. All of it runs client side.
No framework, no build step, no backend, and a single external request for fonts. Ten hand drawn SVG glass types rather than an icon dependency. State persists through localStorage behind a try/catch, so it degrades to a still-usable menu where storage is blocked.
The discipline is in what was left out. Every feature had to justify itself against the file staying editable by opening it, and the whole thing ships as roughly 185 KB of static output behind a CDN.
What shipped
- ▪261 recipes, 21 of them alcohol free, across 13 categories and two languages.
- ▪Client side search and filtering, plus a tried-it tracker persisted in the browser.
- ▪Ten hand drawn SVG glass types, no icon library.
- ▪Roughly 185 KB total, zero dependencies, zero build, deployed as static output.
Stack & decisions
One HTML file
Markup, styles and behaviour in a single document. The constraint is the point: it stays editable by opening it, and there is no toolchain to rot between edits.
Vanilla JS
Search, filtering, language switching and state, written directly against the DOM. At this size a framework would cost more than it returns.
localStorage
Wrapped in try/catch so a blocked storage API degrades to a menu that still reads and filters, rather than a blank page.
Outcome
- →A working answer to how far one file goes: a bilingual, searchable, stateful menu with no framework, no build and no backend.
- →Kept honest by the same rules as the client work. When the recipes were checked against canonical specs, four wrong ratios were found and fixed; wrong specs on a portfolio piece are a visible defect.
What you won't see in screenshots
A personal side project, built for its own sake. Nobody commissioned it and nobody paid for it. It sits here because the constraint is the interesting part, not because it is client work.
Have something we should ship?
60-minute scoping call, then a clear plan for how we'd approach it.


