The point of software here is never to replace the till. We build ordering that lands on the same kitchen ticket, catalogs that keep up with a supplier's price list, and ticketing for a two-screen house that is dark some nights.
For a food distributor running purchasing and inventory across QuickBooks, e-commerce, and spreadsheets
The problem
The catalogue ran on spreadsheets sitting beside the accounting software: the master item list, seasonal replenishment maths, price change workbooks, promotion tracking, receiving. Fourteen hundred and forty-seven items across a hundred and seventeen suppliers, with 396 of them out of stock. The logic that decided what to buy lived in the workbooks and in one person's head. The owner put it plainly: he wanted it out of his head and into a platform.
What we built
An item master you can search, filter and actually trust, with an audit trail showing before and after on every change. An intake form for new items. Pricing batches that read a supplier's price list, match it against the catalogue, show live margin on every line, and print the price change letter that goes to customers.
Where it stands
The matcher refuses to be clever. It tries vendor part number, then manufacturer number, UPC, SKU and exact name, and anything ambiguous falls through to a person instead of being guessed. The same rule holds at the accounting boundary: nothing reaches their books without a human approving it first. The replenishment engine is the next piece of work.
EntertainmentBuilding now
Ticketing and concessions platform for a cinema
For a two-screen independent movie theater
The problem
Tickets were sold by sending people to a third-party storefront, and everything else ran on the phone and the counter. The copy on the old site tells you how it worked: call ahead to reserve seats, we hold them until ten minutes before showtime. Concession orders were called out by transaction id, which is not something a human being can shout across a lobby.
What we built
The front page is the showtime board, one poster case per screen, times as live chips, with a designed closed state because a two-screen house is dark some nights and an empty grid reads as a broken website. Guest checkout in four fields. The confirmation page is the ticket. Then a door scanner, a counter register, a lobby kiosk and a prep board for the people making the food.
Where it stands
Order numbers are short and daily, because somebody has to shout them. The kiosk deliberately takes no payment: it places the order and prints a number, and the customer pays at the counter. Devices send item ids and quantities and never prices, so every total is recomputed on the server. Stock moves are an append-only ledger with a guarded update, so two tills cannot sell the same last box of candy.
RestaurantsBuilding now
Ordering, reservations and feedback platform
For a single-location full-service restaurant
The problem
The website was a brochure, and everything that mattered happened somewhere else: ordering, the menu and gift cards on a third-party store, reservations on a review site, and the printed menus being rebuilt by hand in a design tool. Some of the food photography was nearly three years out of date and showed sides they had stopped serving.
What we built
Ordering that lands on the same kitchen ticket as an order taken at the counter, because the point was never to replace the till. Menus with day parts and the same required and optional option groups the POS uses. A market section with per-state shipping rules. A menu builder that lays out print sheets, so the design tool comes out of the loop.
Where it stands
The POS stays the source of truth for the catalogue and the site never writes back to it, enforced in code rather than by convention. Money is integer cents and tax is basis points, so nothing rounds twice. Every order line snapshots its own name, price and tax treatment at the moment of sale, so last month's order never re-totals itself when this month's prices change.
