Cash drawer counts
A rebuild of a buggy prototype that ends inaccurate paper cash counts: 8–10 staff count the drawer in the app, and every count is checked against Clover cash sales.
https://sammishin.dev/work/cash-drawer
- Role
- Lead designer and developer
- Status
- Live · used by 8–10 staff
- Stack
- Next.js, Supabase, Clover API
- How it’s built
- AI-assisted; I review and test every change
Customer and context
The tasting room staff at 14 Acres Vineyard & Winery — 8–10 people — who count the cash drawer, and the managers who rely on those counts. Cash sales are rung up in the Clover POS.
Counts happen at closing. The staff working up front count the cash, and the app works out the expected amount, verifies their count and tells them how much to move into overage.
Discovery
What they had: paper cash counts that weren’t accurate, and a buggy prototype meant to replace them.
The real problem: a staff member had built the first version with AI. It was constantly buggy, and the staff who used it complained about how it worked. So I asked each of them what their biggest pain points were, and rebuilt the app in Next.js around their answers.
Constraints
- Existing systems: the source of truth for cash sales is Clover, so every count is checked against Clover cash sales.
- Users: 8–10 staff use it, so it has to be quick to learn and quick to use during a shift.
- The first version: constant bugs and an interface staff complained about, so the rebuild had to be reliable and work the way each of them needed.
- Devices: it runs on the staff’s own phones.
- Timeline: the rebuild took 5 days.
What I shipped
I rebuilt the prototype in Next.js and Supabase. Staff enter the drawer count in the app, and every count is checked against Clover cash sales so any mismatch is flagged.
Two decisions shaped the rebuild:
- Starting cash comes from the last close. The app calculates the starting cash from the last time the register was closed, not just from the previous day’s ending cash.
- Overage is handled in the app. When the drawer is over, the app tells staff how much to put into overage. When they confirm they’ve moved it, the app deducts that amount from the drawer, so the next day’s count starts out accurate.
[Add: a screenshot of the count screen]
Rollout and training
I train staff on each system myself.
Switching from paper brought more accountability: every count is checked, so cash is handled correctly. It took staff several weeks to get used to, but they now close out several minutes faster than they did on paper, with more accurate counts.
Results
- 8–10 staff check their counts against Clover cash sales in the app.
- Every flagged mismatch has been under $1.
- Staff feedback on the rebuild has been positive: it saves them several minutes, and it has saved me hours of debugging compared with the first version.
What broke and what I changed
What broke: after launch, the Clover cash total was sometimes wrong. The value was cached, so staff saw an out-of-date number.
What I changed: the app now loads the Clover total fresh every time the page loads.
What’s next
- A simple report of mismatches over time, and of counts done in the app vs. on paper, as proof of adoption
- A public demo with seeded fake data and a “demo” banner, so anyone can click through it