Hospitality ops
Bar inventory app that weighs what you actually poured
Clipboard counts lie. A bar inventory app that talks to a Bluetooth scale turns the remaining bottle into a number you can order from. CodeLoop Studio built Koliko for that job: weigh, log, report — then decide what to buy and what is leaking as waste.
Case study
Koliko
Weigh, log, report. Flutter on the phone, Bluetooth on the scale, analytics for the buyer. Live inventory by weight — not a demo reel, not a Sunday spreadsheet.
Clipboard counts lie. Weight does not.
A bar inventory app that talks to a Bluetooth scale turns the remaining bottle into a number you can order from. Guessing by eye is not inventory. CodeLoop Studio in Sarajevo built Koliko for that job: staff capture a reading on the floor, not later in a spreadsheet. Quick captures, reliable weights, reports that support ordering, waste, and daily stock decisions.
Warehouse SKUs assume boxes on shelves. Bars deal with open bottles, pour variance, and a noisy floor. The workflow has to be weigh-and-go, then report. If you already own industrial scales, you need software that speaks the scale’s language. We do not pretend every Bluetooth sticker works.
Menus guests scan are a different product — restaurant QR menus. The stack that made Koliko possible on both stores is Flutter app development. Typical studio products take 3–9 months from idea to launch; a tight inventory MVP can be shorter when the device path is known. Written estimate within 24 hours via the online estimate.
Warehouse software assumes boxes. Bars assume open bottles.
A generic inventory SKU app wants a shelf, a barcode, and a quiet stockroom. A well is noisy, pours vary, and the remaining liquor is a weight — not a box count. Koliko combines a focused mobile workflow with Bluetooth-connected scales so staff capture a reading between tickets, then the office sees usage, waste, and what to order. That is why hardware comes first: which scale, which protocol, which shift pattern. We do not pretend every Bluetooth sticker talks. If you already own compatible hardware we integrate it; if not, we help you pick a device the protocol can actually use.
Flutter ships iOS and Android with one squad so bar and office are not supporting two products. APIs and reporting so purchasing is not retyping weights. Multi-site admin when a group needs it. A stack next to your POS when the docs exist — after the weigh-and-go loop is true. Hardware discovery is the long pole if the scale protocol is undocumented. Typical CodeLoop products take 3–9 months idea to launch; a tight MVP is shorter when the device path is known.
We work with operators and product teams in the EU and US, in English, with overlap hours. The product was built in Sarajevo for real venues, not as a city-only listing. Venue groups that need different hardware are a custom ops app, not a reskin. Menus guests scan remain a sibling product. Do not brief a warehouse tool and hope the well starts telling the truth.
What the floor actually needs
A scale the protocol can talk to
If you already have compatible hardware we integrate it. If not, we help you pick one. Discovery is the long pole when the vendor SDK is a shrug.
Capture between tickets
Shift-speed UX. Not a 12-field warehouse form. Staff will not fill a novel at 1am.
Numbers, not eyeballing
Bluetooth weight capture. Remaining liquor becomes a figure purchasing can use.
Ordering signal
Stock and usage reports. Fewer emergency runs. Not a raw dump of weights.
Waste you can brief on
Actionable history. Shrink that a manager can talk about on Monday, not a feeling.
Both phones
Flutter so iOS and Android staff share one product. Multi-site admin when the group needs it.
Jobs on the floor versus what the app does
| Job | Outcome |
|---|---|
| Count remaining liquor | Bluetooth weight capture. Numbers instead of a clipboard that lies after a busy Friday. |
| Plan the next order | Stock and usage reports for purchasing. The office sees what the bar weighed. |
| Cut waste | History you can act on. Pour variance becomes a conversation, not a mystery. |
| Custom for a venue group | Different hardware, multi-site admin, or a stack next to your POS. Koliko is the proof we have done beverage measurement; your variant is a scoped build. |
Hardware first, then Flutter, then the office
Which scale, which protocol, which shift pattern. Then one squad for both stores. Then APIs so the buyer is not retyping weights. We work with operators and product teams in the EU and US who need the same class of tool, in English, with overlap hours. The product was built in Sarajevo for real venues — not as a city-only listing.
If the scale protocol is undocumented, say so in the brief. That is calendar. We will tell you after discovery whether the device is viable. We do not promise every dongle.
Frequently asked
Related







