Turning “why is the money off?” into a question with an answer.
A field-tested example of designing operational software around the way a multi-store lottery retailer actually closes a day—not the way a spreadsheet assumes it does.
The client and operational details are anonymized. The workflow constraints, product decisions and delivery process are real.
The problem was not a missing spreadsheet.
Each store needed a repeatable way to reconcile tickets, inventory movement, opening cash and the day's settlement.
Opening cash could not simply roll forward from yesterday, and pending inventory changes could not enter the formal ledger before approval.
The workflow had to stay understandable for people working at different locations while preserving a consistent source of truth.
The product also needed migration, permissions, privacy flows, deployment and post-launch inspection—not just screens.
From real workflow to reliable system
Product decisions that mattered
People handled the physical count. The system calculated sales from inventory movement rather than asking staff to re-enter derived numbers.
Unapproved inventory changes stayed outside the formal ledger until the relevant review step was complete.
The system was shaped around the questions that caused daily uncertainty, so discrepancies became inspectable rather than hidden in a spreadsheet.
Delivery included data migration, deployment, permissions, privacy considerations and the checks needed after launch.
What this case shows
NorthFoundry is not positioned as a generic coding vendor. The value is in understanding a messy workflow, deciding what the product should guarantee, and keeping the system reliable after it goes live.
Discuss a workflow ↗