TipCalc - Designing a tip management system for an industry that runs on cash, paper, and habit
$1M in SaaS revenue · $8M in FSR bookings
Sole designer
November 2024 – ongoing
Prototype through pilot launch
— The setup
Tip-outs at full-service restaurants are still manual, cash-based, and error-prone. At the end of every shift, managers reconcile payouts by hand across dozens of workers, multiple job codes, and competing pooling rules. The process is slow, opaque, and a known source of wage disputes.
I joined as the sole designer on TipCalc in November 2024 to replace that with a cashless, automated system: managers review checks and shifts, then pay out tips to workers in real time. Within the first few conversations with Miller's Ale House, our pilot partner, one fact came up that ended up shaping almost every decision that followed: no two of their locations tipped out quite the same way.
— The partner: Miller’s Ale House
Miller's operates 80 casual dining locations with roughly 200 employees each. They ran on Aloha POS for credit card processing but had no system for tip distribution. Bartenders, bussers, and barbacks were paid out in cash at the end of every shift, with no paper trail and no accuracy guarantee.
The real complexity wasn't the cash handling, it was that Miller's needed two fundamentally different models running at once. Pooling, where the restaurant sets the rules and contributors and receivers are defined by job code. Sharing, where the server decides what gets distributed, role to role. Most tip software picks one model and asks the restaurant to adapt to it. Miller's needed both, sometimes in the same location, and a manager configuring it should never have to think in those terms to get it right.
No two tip philosophies are the same. That was the core UX challenge, and the reason almost nothing about this product could be templated.
Building a system a manager could trust without reading a manual
TipCalc is a system, not a single feature, and I owned it end to end: the rules engine, close-day workflow, custom tip split logic, held checks, roles and permissions, and the settings architecture holding it together. I presented directly to Miller's leadership, partnered with engineering through bug bashes and visual QA, and stayed involved through launch and ongoing iteration.
Some of the settings decisions needed more than a design pass, they needed alignment across people who each had a reasonable but different idea of where something belonged. One org-level setting, which POS integration a restaurant used, ended up driving UI branching across close day, payout timing, and error handling. Product, engineering, and our professional services team each had a different opinion about where that toggle should live. I facilitated that decision and documented a dependency matrix showing exactly what the setting controlled downstream, so the answer didn't have to get re-litigated every time someone touched a related feature.
The rules engine had to support tip pools and tip shares simultaneously, across different revenue centers, without the manager configuring it ever seeing the underlying complexity. I designed the full rules management experience: creating and editing rules, assigning job codes and distribution frequency, surfacing rule details in context, and validating that a rule couldn't be silently broken by a downstream change, like deactivating a job code that an active rule still depended on.
The moment that mattered most: close day
Close day is the highest-stakes moment in TipCalc. Managers are working against a clock, resolving errors and unblocking dependencies before payouts go out. I designed the dashboard's state model, incomplete, in progress, blocked, successfully closed, so that a single mental model for "what's wrong and what do I do about it" held across every tab, not just the close-day screen. The checklist sequences the work and surfaces blockers in context, so a manager never has to remember what's left or hunt for what's broken.
Product leadership later flagged this pattern as a candidate for home screen onboarding across the broader Branch product, not because it was flashy, but because it solved a problem that shows up everywhere: orienting someone fast inside a system with real stakes.
Proof: it shipped, and it's working
TipCalc launched to Miller's Ale House and is in active production, tied to two company-tracked metrics: TipCalc Revenue and Close Out Completion Rate.
$1M in SaaS revenue
$8M in FSR bookings
92% successful close rate as of April 2026, with continued improvement since
The close-day checklist pattern was flagged by product leadership as a candidate for home screen onboarding across the broader Branch product
The second test: Toast broke an assumption I didn't know I'd made
Miller's pilot validated the core system. Branch greenlit expanding TipCalc to Toast POS orgs, a different integration, different data flows, different timing constraints, and different pre-close-day behavior for managers.
A bad assumption, caught early
My first instinct was to treat Toast as a drop-in replacement for NCR: same header, same checklist, same button, just a new data source underneath. That broke almost immediately. NCR sends data in real time, so a manager is always looking at today. Toast delivers data through an overnight batch file, so a manager opening the dashboard in the morning is usually closing out yesterday, while today's file is still in transit.
The catch came from one specific edge case: the header said today's data wasn't ready, while the checklist and button were fully actionable, showing three previous unclosed days ready to go. Under the NCR model, that combination would read as a bug, header and button disagreeing with each other. Under Toast's model, it's correct. Today's pipeline status and which days can close are independent facts.
The fix
I redefined the header, the checklist, and the close-day button as three separately-driven states instead of one linked system, and documented the "looks broken but isn't" case directly for engineering so it wouldn't get quietly corrected into an actual bug during build.
From there, I designed the full Toast variant: four pre-close-day states (no data yet, processing, data ready with errors, data ready clean), a stacked-day experience for orgs with multiple unclosed days, error states specific to the Toast integration, and updated close-day copy that removed Refresh Data references no longer applicable to how Toast sends data.
I also built a full user journey map across every file ingestion state, making the end-to-end experience visible before engineering and PM aligned on requirements. Auditing it against the built screens caught a handful of places where a screen's name no longer matched its content, small drift that's easy to miss and exactly what leads an engineer to build against the wrong assumption.
Toast rollout in progress.
Closing the loop: we built this without the people who use it every day
TipCalc was designed and built for Miller's Ale House without direct input from site managers. With the product in production, I proposed and got approval for a post-launch research study to close that gap before we scale to Toast.
The study includes five moderated remote interviews with Miller's site managers, focused on Close Day flow, error handling, tip rule configuration, and terminology. Findings will inform TipCalc improvements and shape how we approach the Toast rollout.
I scoped the research, wrote the discussion guide, coordinated recruitment with PS, and partnered with our research team on synthesis.
What I'd do differently
I'd move user research earlier. TipCalc was designed and built for Miller's Ale House without direct input from site managers, and while the system worked, the research now underway into terminology and error handling should have happened before pilot launch, not over a year after it.
I'd also design for multi-integration from day one. TipCalc was built around NCR's real-time data model first, then adapted for Toast's overnight batch model. Some of that adaptation was straightforward, but parts of the settings architecture assumed a single integration pattern that Toast didn't fit. Building that flexibility in up front, even before Toast was a confirmed scope, would have saved real rework later.
Finally, I'd document design rationale as I went, not just the final states. A lot of the reasoning behind decisions like the close-day state logic lived in conversations and my own head rather than in the file itself. Making that visible from the start, instead of reconstructing it later, would make the work easier to hand off and easier for engineering to build against.