01 OPERATIONS APP / CULTURAL BAR LIVE
Funez
A bar that ran on scraps of paper — stock, orders, the night's sheet. I designed and built the system that replaced them, with an AI assistant you can talk to with a crate in the other hand.
/ 01 / CONTEXT
The problem.
Cultura Funez is a cultural bar. Before this, it had no stock system: stock, orders and the night’s sheets all lived on scraps of paper.
I designed and built, on my own, the system that replaced them — an app the staff use on their phones during service, covering the whole circuit of a night: opening the cash, taking and charging orders, moving stock, paying out, and closing.
On top of it sits an AI assistant. You can ask it about the business, dictate to it, or photograph a supplier ticket and let it write the expense — and nothing it proposes is saved until a person confirms it.
/ 03 / PROCESS
Key decisions.
- 01
DESIGN + BUILD
The model proposes, a person confirms
The chat can create a product or log an expense, but it never writes to the database. The Worker only runs inference and holds no credentials; the tool definitions travel with each request, and whatever the model proposes is applied by the browser, through the same use cases as the buttons, only after someone says yes.
- 02
DESIGN
Designed for a bar at night
Whoever is using it often has a crate of beer in the other hand. So there's dictation, an undo for what was just done, fixes for entries mistyped at night, and products named the way people call them — nobody says "Cerveza Andes Roja". "Let it go for ten thousand" is understood as a price, because that's how it's actually asked.
- 03
FRONTEND
A photo of a ticket becomes an expense
Supplier tickets are photographed from the chat and the expense writes itself. A long ticket can be taken in two photos and read as one; a ticket with no date isn't guessed, it's asked about; and only the bar's items go in, once someone confirms. Which model reads tickets is set by config, not code.
- 04
FRONTEND
Business rules live in the domain, and are tested
The logic moved out of the Firestore rules into a domain layer with its own tests: stock can't go negative, something another item depends on can't be deleted, and a discount is spread across the order instead of being booked as a negative cost. The rules themselves have a separate suite run against the emulator.
/ 05 / RESULT
What shipped.
In daily use at the bar. Things that were never recorded before are now tracked, and the costs and analysis sections show how much money comes in, how much goes out and the gross profit left — with real costs stored and the best-selling items in view.
NOTE // No usage metrics yet — the impact is described by the team, not measured.
/ 06 / DEBRIEF