Food franchisor·2025

A franchise operations platform built around one store record

Franchise records, store operations, compliance, and reviews sat in separate workflows. One platform now carries each store from application through audit and renewal.

Sector
Food and Beverage, Franchising
My role
Led architecture and full-stack delivery of the core franchise operations platform.
Stack
Laravel, Vue.js, Inertia, Tailwind, SQL, queued jobs, Excel workbook processing, S3 and local file storage

In 2025, a multi-site food franchisor needed one system to carry franchisee and store records from application through opening, day-to-day operation, review, and renewal. I led the architecture and full-stack delivery of the core franchise operations platform.

No platform connected the franchise network

Before this build, the franchisor had no unified platform connecting head office, franchisees, and individual store branches. Franchisee records, store operations, compliance, reviews, and reporting lived across separate files and processes.

A franchisee could operate several stores, but branch-level changes did not carry cleanly into reporting and follow-up. Important edits also lacked enough history to remain trustworthy.

The platform therefore could not be a directory of franchisees with a few forms around it. It needed to make each franchisee and store a durable operational record.

How I made the store record carry the workflow

I led the platform around two connected domain records: the franchisee and the stores they operate. The application establishes the franchisee record; each store then becomes the operational record teams use throughout its lifecycle.

I kept important changes as dated history rather than overwriting previous values without context. Reporting and operational follow-up could therefore reflect what was true at a given time, not only the latest state.

The same model supports the product's different views. Teams work from searchable operational records with documents and activity kept in context, while role and assignment controls limit access by responsibility.

Turning operational records into follow-up

Once the core records were stable, I led the workflows around them.

Documents and bulk imports feed the same records rather than creating separate sources of truth. Longer-running imports and exports move to queued jobs, with their outcome returned to the user when processing completes.

Dates and operational changes become reminders, dashboard views, and reports.

Royalty processing previously depended on failure-prone Excel macros. I converted that logic into queued application jobs that validate source files, perform the calculations, generate royalty workbooks, and record each batch outcome.

Keeping evidence behind every store rating

I built a guided, resumable review workflow across five operational areas. Assigned auditors record answers, question-level remarks, and captioned photos before the platform calculates area and overall scores. The complete assessment stays in the store's history, so teams can see the evidence behind each rating.

A foundation for the next operational workflow

By the end of the build, franchisee and store records were no longer just reference data. Documents, review history, reminders, reporting, imports, and royalty processing all attached to the same operational model.

That gives new workflows a clear place to join instead of becoming another file or side process. I led that core from its initial architecture through full-stack delivery.

A franchise operations platform built around one store record | Ryan Catapang