Make every location run like your best one.
Operations platform designed for teams across multiple locations, currently deployed in production at one location, Walker's Doughnuts. Tasks, scheduling, and procedures in one place.
At Walker's Doughnuts, the things that made a shift run well were rarely written down. A manager knew how to handle a rush, and a senior staff member knew the fastest way to prep for the morning, and none of it survived when that person wasn't rostered on. Around the same time, our store slid from one of the better performers in the franchise toward the bottom of the leaderboard, and staff turnover was high. I can't say the ranking drop was caused solely by knowledge loss, but I saw first hand how much operational knowledge disappeared every time someone left.
Operational knowledge, standards, training, and workflows fragment across locations and staff, and disappear when someone leaves.
A shared operations platform for tasks, scheduling, procedures, tools, and staff coordination, captured once, reused by every shift.
“The success of one location should strengthen every location.” I didn't set out to build a SaaS product. I set out to fix this at one store, and FriendChise is still running that store today.
Timetable, tasks, procedures, and tools are built as separate systems sharing one organisation scoped data layer, so screenshots below reflect what a real shift actually sees.
Weekly and daily scheduling so staff know what they're doing without asking a manager. Overlapping shifts and roles are grouped into readable cards instead of a wall of stacked entries, which removes the constant "what am I doing today" interruptions that used to eat into a manager's time.
Recurring tasks, prep procedures, and recipes that used to exist only on paper or in someone's head are written once and searchable by anyone on shift. Tags, comments, and recurrence rules turn a scrap of tribal knowledge into something the whole team can trust.
Conversion tools, operational calculators, and item lists remove repetitive manual math from day-to-day work, the kind of thing that seems minor until you're the one doing it by hand every shift, and a big part of onboarding someone new quickly.
Each location runs as its own organisation with its own staff, schedule, and data, while a parent organisation can connect multiple franchisees and share brand level resources, the structure the platform needs before it can grow past one store.
I built and maintain FriendChise independently, owning the product direction, architecture, implementation, and ongoing development.
The project has grown to open source contributors. I review incoming contributions while continuing to lead the architecture, product direction, and production quality.
A business may already have hundreds of paper documents, recipes and dense procedures. Manually converting all of that into structured digital data creates a major barrier to adopting the system.
I built an AI supported tool that can scan or upload existing documents and convert them into structured, presentable task data inside FriendChise.
This reduced the amount of manual data entry required and showed me that simplifying the transition into the system was just as important as building the features inside it.
FriendChise was originally built as a web app, but frontline work happens in a fast paced environment where staff need information immediately. Even if the features worked well, opening a browser, finding the site, navigating back to the right place, or remembering where you left off added too much friction.
I realised the problem was not the functionality, but the form it was delivered in. A dedicated mobile app was better suited to everyday operational use because it gave staff direct access, preserved context, and separated work from their normal browser activity.
This led to FriendChise Mobile, where common workflows are faster to reach and better suited to use during an active shift.
The platform needed to support both an independent single store and a franchise network, without one org ever seeing another's data by default.
A self referencing parentId relation on Organization lets a parent connect multiple franchisees and share brand level resources, while every query is still scoped by orgId rather than relying on the UI to hide things correctly.
One data model supports both a single independent location and a franchise across multiple locations, with tenant boundaries that don't depend on the interface behaving correctly.
Owners, managers, and staff need different tools from the same system, and permission logic scattered across screens is exactly where multi tenant bugs hide.
Permissions are modelled as organisation scoped Role → Permission → MemberRole join tables, checked centrally in a shared authz layer rather than per page.
Each role only sees the tools relevant to its job, and permission checks are covered directly by the largest slice of the test suite (151 server-action tests) instead of being trusted to the UI.
If I started FriendChise again, I would begin with the smallest high frequency workflow, such as task and procedure lookup, and validate daily usage before expanding into broader scheduling and operational tooling. The product was intended largely for frontline staff, yet I initially invested heavily in the web experience and too much time went into polishing features before I knew whether they would remain important.
I would build less initially and focus first on the workflows staff used most often. I would make the product mobile first much earlier, invest sooner in AI supported tools that turn photos and documents into structured operational data, and ship smaller versions sooner so real usage could guide the next round of work.
The biggest lesson was that building more functionality was not always the same as making the product more useful. Reducing friction, capturing data more easily and validating real usage mattered more.
Web and mobile requests enter through different transport mechanisms, but both authenticate, validate and normalise input before calling the same shared business logic.
Server Actions and API routes are transport layers, not separate implementations of the product logic. Both authenticate and validate requests before calling the same shared business logic, which then accesses organisation scoped data. This keeps web and mobile behaviour consistent, avoids duplicated rules, and makes security and performance constraints easier to enforce.
Web and mobile use different authentication mechanisms, but both resolve into the same application logic and organisation context. This allows the two clients to share the same behaviour and data rules while presenting the information differently for desktop and mobile layouts.
Each page acts as the main coordinator for its feature. It loads the primary data needed for the initial render on the server, then passes only the relevant data into smaller components responsible for presentation and interaction. When a component needs additional data after the page has loaded, such as for pagination, infinite scroll or on-demand updates, it can request that data through an API route.
isParent.Major workflows are designed in Figma before implementation. This is used to define layout, interaction and responsive behaviour, but also to identify reusable patterns and component boundaries before code is written, so components aren't created ad hoc and duplicated later.
Uploads are validated before reaching Supabase Storage so the application only accepts file types and sizes that its workflows can process reliably.
Organizations connect directly with their parent/child Organizations, so a franchisee stays independent while a parent can connect and manage multiple locations.
Access flows from Membership to MemberRole to Role to Permission, all scoped to one Organization, so access never crosses tenant boundaries.
Tasks, timetables, rosters, tools, and menus each carry an orgId, so every query is scoped at the data layer, not the UI.
55 Prisma data models covering auth, organisations, tasks, scheduling, rostering, tools, menus, comments, and admin/audit data.
FriendChise uses automated testing and CI checks to protect critical workflows, access control, and production quality. Testing is concentrated on areas where failures could expose organisation data, bypass role permissions, or break important workflows.
Every pull request runs automated checks through GitHub Actions, helping maintain the same quality standard for my own changes and external contributions.
Particular attention is given to role protected features, protected routes, organisation scoped data, and actions that should only be available to authorised users.
Real usage across staff workflows, customer interactions, and public product exploration. Beyond the usage numbers, FriendChise has made everyday operations easier to maintain, teach, and share across the team.
Next.js 16 · React 19 · TypeScript · Tailwind v4 · shadcn/ui
PostgreSQL on Supabase · Prisma v7 · Supabase Storage
Auth.js v5 · Upstash Redis · Sentry · Vercel
Vitest · Playwright · GitHub Actions