'
Most case studies end with a number. This one ends with something we removed.
The Port of Peri Peri is a Portuguese and Mediterranean flame-grilled chicken franchise with a genuinely devoted following, operating more than two dozen locations across eight states, from California to New York, with the heaviest concentration in the Chicago metro. If you've had the peri peri wings, you understand the expansion. The Port of Peri Peri is the fastest growing Peri Peri Franchise in the US. Franchise inquiries are open and the unit count keeps growing.
Growth is what created the problem.
What Monday looked like before
Royalties were calculated by hand. Every week, someone pulled sales for every location, applied the royalty rules to each one, and worked out what each franchisee owed. Then payments were processed manually, one at a time.
None of that is complicated work. It's just work, repeated every week, growing linearly with the number of locations. Twenty-something units means twenty-something calculations, each with its own rules to apply correctly, followed by twenty-something payment transactions.
The failure modes are predictable and they compound. A calculation error surfaces weeks later during a franchisee conversation, and now you're reconciling history instead of running the business. The person who knows the rules becomes a dependency. And every new location, which should be pure good news, quietly adds to a Monday that's already full.
There's a subtler cost too. When royalty reconciliation is manual, nobody runs it more often than they have to. Ad-hoc questions wait. A franchisee asking about a specific period becomes a project rather than a lookup.
What we built
A royalty platform that connects directly to the centralized POS systems and to Stripe.
Sales data flows in from POS. The royalty rules live in the platform rather than in a person's head or a spreadsheet formula. Calculations run automatically on a weekly and monthly cycle, and ad-hoc runs are available whenever a question comes up rather than requiring someone to rebuild a period by hand. Payment transactions execute through Stripe, including bank transfers, so the money movement is part of the same automated flow rather than a separate manual chore afterward.
Reporting came with it, which turned out to matter more than expected. Once the calculation is systematic, the numbers behind it become visible to everyone who needs them, including franchisees. Questions that used to require a phone call and a spreadsheet became something a person could look up.
The technical work here wasn't exotic. It was integration: getting POS data and payment infrastructure to talk to a rules engine reliably, on a schedule, without a person in the middle. That's most of what useful custom software actually is.
The part worth telling
We didn't launch it fully automated. Nobody should.
The first version required approval before payments went out. The system calculated everything, presented the results, and waited for a human to confirm before money moved. That's the right design when you're asking someone to trust a machine with payments to their franchise partners.
Then something happened that we think is the real outcome of this project. Over time, the approvals became a formality. The numbers were right, week after week. The person approving was confirming what they already expected to see.
So the approval step came out. Today the process is fully automated end to end, calculation through payment, with no manual gate.
That progression is worth naming because it's how automation should actually arrive. Not as a leap of faith on day one, but as a step that gets removed once it stops earning its place. The approval gate wasn't a limitation of the build. It was the mechanism by which trust got established, and its removal is the evidence that it worked.
What transfers to other operations
The specifics here are franchise royalties, but the shape of this problem shows up anywhere a recurring calculation sits between two systems that already hold the data.
Sales exist in POS. Payment capability exists in Stripe. The rules exist, written down somewhere. All three were present before we built anything. What was missing was the connection between them, and a person was serving as that connection every week.
That's the pattern we see constantly in food and multi-location operations. The data isn't absent. It's stranded in systems that don't talk, with a human bridging the gap manually and absorbing the cost as normal overhead. It's the same structural issue behind stalled AI pilots and traceability gaps, showing up in a different department.
The test is simple. Find the recurring task in your operation where someone moves numbers between two systems on a schedule. If the rules are consistent enough to be written down, and both systems have APIs, that task is a candidate. The question isn't whether it can be automated. It's whether the volume justifies the build yet.
For a franchise adding locations, the answer arrives on its own. Manual processes that work at ten units are a problem at twenty and a crisis at forty. Building before you hit the wall is considerably cheaper than building during.
If you're running a recurring calculation by hand and wondering whether it's worth automating, that's a conversation we're glad to have.
Our thanks to the team at The Port of Peri Peri, who were willing to let us describe this work publicly. If you're near one of their locations, the wings are worth the trip. You can find them at myperiperi.com.
