Project Overview

This product is a multi-tenant food ordering and restaurant operations platform. At the surface level, it allows customers to browse restaurants, review menus, place orders, make payments, and track delivery progress. Behind that, it provides the administrative tooling needed to run the business: tenant setup, subscription billing, restaurant onboarding, menu governance, delivery zone management, delivery partner coordination, and document verification.

The platform is intended for several user groups at once. Super admins oversee the overall system. Tenant admins manage a portfolio of restaurants under a subscription plan. Restaurant staff handle menus and order execution. Delivery partners manage fulfillment. Customers use the API-driven ordering flow. That combination is what gives the system its depth: it exists not just to take orders, but to support the operational model around them.

Quick Summary

Project Type: Multi-tenant restaurant commerce and operations platform
Platform: Web admin platform with API endpoints for customer and delivery flows
My Role: Project Manager / Product Manager
Team Size: N/A
Duration: N/A

Problem

The problem this platform is solving is broader than online ordering. The platform shows a business that needed a way to manage multiple restaurant entities, each operating under a tenant structure with subscription-based access. That creates a layered operational challenge.

At the business level, the platform needed to support onboarding new restaurant operators, collecting and verifying compliance documents, controlling access based on subscription status, and coordinating delivery across geographies. At the workflow level, it had to connect several roles that do not think the same way: operations teams, restaurant teams, delivery partners, and end customers.

Without a platform like this, much of that work would likely be fragmented across spreadsheets, messaging, manual approvals, and disconnected ordering tools. The codebase brings those activities into a single operating system for the business.

Goal

Success for this project looked like creating a single platform that could support the full lifecycle of a restaurant network:

onboard tenants and restaurants
verify required business documents
manage menus and menu changes
enable customer ordering and payment
coordinate delivery assignment and status updates
enforce role-based and subscription-based operational access

In practical terms, the goal was to move from isolated workflows to a connected platform where commercial activity and operational governance lived in the same system.

My Contribution

I worked on this as the Project Manager / Product Manager, which meant my focus was on shaping the product around real operating needs rather than treating it as a narrow feature build. I helped drive the definition of the major workflows, align priorities across multiple areas of the platform, and keep the scope coherent as the system expanded from ordering into subscription management, onboarding, delivery operations, and admin controls.

A project like this requires more than a backlog of screens. The important work is making sure the workflows make sense together. That includes questions like when a tenant should be blocked for non-payment, what documents are required before a restaurant becomes active, how menu changes should be handled safely, and how delivery assignment should behave when availability changes in real time. My role was to help turn those operational questions into a product that engineering could implement in a structured way.

What stood out in this project is that it demanded product ownership across both business and technical concerns. The system design reflects a system with many moving parts, and the value came from keeping those parts connected rather than optimizing any one screen in isolation.

Tech Stack

Frontend

Blade templates Used for the multi-role admin interface and operational screens. This fits a product where server-rendered back-office workflows matter more than a highly dynamic SPA.
Vite Used to compile frontend assets cleanly for modern deployment workflows.
Tailwind CSS and custom admin assets Used to support UI styling, with a mix of custom scripts and packaged admin components for dashboard-style interfaces.
Vanilla JavaScript Used for focused interactions such as form behavior, dynamic city loading, and upload-related UI.

Backend

Laravel 12 The core application framework. It is a strong fit for a platform that needs routing, validation, middleware, authentication, queue-ready patterns, and rapid admin development.
PHP 8.x Supports typed, modern Laravel application code and the service-oriented structure in the repository.
JWT Auth Used for API authentication, especially for customer and delivery-partner flows.
Session-based auth Used for the web admin side, where role-based dashboards and internal workflows are server-rendered.

Infrastructure

Docker Used to package the application for consistent deployment.
FrankenPHP and Caddy Used as the runtime and web server combination, with gzip/zstd compression and production-oriented PHP settings.
Railway The platform includes deployment configuration for Railway-based cloud deployment.
Laravel Pulse Included as a sign that runtime monitoring and application visibility were part of the intended operational setup.

Integrations

Stripe Used for payment intent creation and payment confirmation flows.
File storage for restaurant documents Used to support onboarding and compliance workflows around uploaded business documentation.

Testing

Pest / PHPUnit Included in the project setup as part of an intended automated test strategy.
Observed state The visible committed test coverage is currently very light, and I could not run the suite locally from the available checkout because vendor dependencies were not installed.

Architecture Notes

The application is organized around a fairly classic Laravel application structure, but it also shows an attempt to separate concerns through services, repositories, DTOs, actions, middleware, and scoped models. That matters because the product surface is wide. There are different controllers and route groups for admin flows, restaurant operations, guest registration, delivery partner actions, and public API endpoints.

One architectural decision that stands out is the tenant-aware model layer. There is a TenantContextService, tenant-scoped traits, and middleware that sets tenant context based on role or active session state. That gives the platform a foundation for keeping data partitioned while still allowing super-admin behavior such as tenant switching.

Another important design choice is the combination of role-based access and payment-based access. The system does not just ask who the user is; it also asks whether the tenant is in good standing before allowing access to operational features. That is an architectural reflection of the business model, not just a security feature.

The codebase also shows maintainability decisions around reusable domain pieces:

service classes for business logic
repository abstractions for data access
DTOs for structured input handling in parts of the menu domain
action classes for menu version save and rollback flows
middleware for tenant identification, role checks, API response shaping, and subscription enforcement

From a scalability perspective, the relational model is indexed around tenant, restaurant, status, geography, and dates. Delivery and restaurant lookup flows also use latitude and longitude, showing the team was thinking about operational queries, not just CRUD storage.

What I Built

Tenant Subscription and Access Control

Purpose
This part of the platform manages the commercial relationship between the platform and each tenant. It defines subscription plans, billing periods, upgrade logic, and whether operational features should be accessible.

Engineering challenges
The challenge here is that billing does not live in isolation. Subscription state directly affects whether a tenant can manage restaurants, use admin tooling, or continue normal operations. That creates a strong dependency between finance logic and product access.

Implementation highlights
The tenant model includes plan definitions, billing calculations, upgrade cost logic, payment history relationships, and active-subscription checks. Middleware then uses that state to gate feature access and redirect users toward payment flows when required.

Business value
This turns the platform into a managed SaaS-style product rather than a one-off admin tool. It also ensures that monetization and access control are part of the same operating model.

Restaurant Onboarding and Compliance Workflow

Purpose
This system supports onboarding restaurants into the platform while handling the paperwork needed before activation.

Engineering challenges
The hard part is not uploading files. It is designing a workflow that tracks document types, status, verification history, rejection reasons, expiry handling, and restaurant activation state.

Implementation highlights
The platform includes document upload, edit, download, verification, bulk approval/rejection, expiry reporting, and automatic restaurant approval when required document sets are complete. The workflow also captures review metadata and admin notes.

Business value
This reduces operational ambiguity during onboarding and gives the business a more structured way to manage compliance before a restaurant starts transacting.

Multi-Role Administration Model

Purpose
The platform serves super admins, tenant admins, location admins, restaurant staff, delivery partners, and customers, each with different permissions and dashboards.

Engineering challenges
Role complexity tends to grow quietly. The risk is ending up with overlapping permissions, inconsistent navigation, and fragile route protection.

Implementation highlights
The route layer is segmented by role and workflow. Middleware handles authentication, tenant context, and role checks. The application also supports super-admin tenant switching, which is useful in a multi-tenant operating environment.

Business value
This creates a clearer operational boundary between platform oversight, tenant management, restaurant execution, and delivery fulfillment.

Purpose
Menu management goes beyond simple item CRUD. This platform supports categories, item variations, bulk updates, analytics hooks, restaurant-specific menu inheritance, and saved menu versions.

Engineering challenges
Menus are operational data. Mistakes affect pricing, availability, customer experience, and restaurant execution. Safe change management matters.

Implementation highlights
The platform includes menu categories, item variations, bulk update routes, import/export paths, and explicit save/rollback actions for menu versions. That shows the team understood that menus need both flexibility and recoverability.

Business value
This makes the system more practical for real restaurant operations, especially where menus change often or need coordination across locations.

Order Processing and Payment Flow

Purpose
This module handles customer orders from validation through item creation, payment record creation, and delivery preparation.

Engineering challenges
Order flows have to balance correctness and speed. The system needs to verify customer ownership, validate item references, calculate amounts, and keep order, payment, and delivery state aligned.

Implementation highlights
Order creation is wrapped in a transaction, creates both order and item records, initializes order status tracking, generates payment records, and calculates delivery preview information before assignment. The payment layer supports Stripe-backed intent creation alongside order-linked payment history.

Business value
This provides the transactional backbone of the product and connects the storefront experience to the operational system behind it.

Delivery Coverage and Dispatch Logic

Purpose
This part of the platform manages whether a location is serviceable, what delivery fee applies, and which delivery partner should take the order.

Engineering challenges
Dispatch systems have messy edge cases: missing coordinates, out-of-range addresses, unavailable partners, rejected assignments, and shifting delivery state.

Implementation highlights
The system supports polygon-based delivery zones, distance-based fallback pricing, nearest-partner selection using coordinates, assignment acceptance and rejection, manual reassignment, status progression, and partner location updates. There is also explicit handling for cases where assignment needs to wait for availability.

Business value
This closes the gap between taking an order and actually fulfilling it, which is where many ordering platforms become operationally difficult.

Key Engineering Challenges

One challenge was the sheer workflow overlap. Customer ordering, tenant billing, restaurant onboarding, and delivery operations all influence each other. The code reflects a system that had to behave like both a customer product and an internal operations console.

Another challenge was permissions. This is not a single-admin system. It has multiple internal and external user types, tenant context, and payment-dependent access rules. Designing those boundaries well is essential because mistakes affect both security and day-to-day operations.

Data consistency is another clear concern. Orders, payments, order statuses, and delivery assignments all have to stay aligned. The code uses transactions in key areas, but it also shows the natural complexity of keeping several state machines synchronized.

Geographic logic is also meaningful here. Restaurant discovery, delivery coverage, fee calculation, and partner assignment all depend on coordinates and service boundaries. That moves the system beyond standard CRUD and into operational decision-making.

There is also evidence of a product evolving in place. Some areas appear more mature than others, and there are signs of iterative implementation rather than a one-shot build. I actually think that makes the project more realistic. Real platforms grow unevenly, especially when they are solving active business problems.

Outcome

Based on the repository, the platform became more than a restaurant listing or ordering application. It evolved into a broader operating platform that ties together tenant administration, subscription management, restaurant approval, document control, menu operations, order processing, payments, and delivery fulfillment.

The most important outcome is unification. Instead of treating onboarding, ordering, and fulfillment as separate concerns, the system brings them into one product model. I would be careful not to overstate business results without metrics, but it is reasonable to say the platform was built to reduce operational fragmentation and create a more controlled end-to-end workflow.

Why This Project Matters

This project matters in my portfolio because it shows the kind of product work I enjoy most: software that sits close to real operations and has to make business rules tangible. I was not looking at a simple feature backlog. I was helping shape a product that had to support multiple roles, a subscription model, operational approval processes, and a live order-to-delivery workflow.

What I find compelling about it is the breadth. It touches product strategy, platform design, workflow clarity, monetization logic, compliance, and fulfillment operations. Even from a product management perspective, this is the kind of work that benefits from strong technical understanding because the real tradeoffs sit in architecture and process, not just UI decisions.

What I Learned

This project reinforced how important it is to think in systems, not features. When a product spans billing, onboarding, menus, orders, and delivery, every decision has downstream effects. A small workflow change in one area can create operational load somewhere else.

It also taught me that access control is often a product design problem, not just an engineering one. In this platform, permissions and subscription state are part of the business model itself. Getting that right affects usability, revenue protection, and operational trust.

I also enjoyed seeing how much product value lives in back-office workflows. Customer-facing ordering is visible, but the deeper platform value comes from the admin and operational systems that make the business sustainable. That is a useful reminder for how I evaluate product complexity and delivery priorities.

Finally, this project is a good example of growth through complexity. It pushed me to think more carefully about how to structure work across multiple modules, how to connect business rules to product behavior, and how to keep a broad platform coherent as it evolves.

Multi-Tenant Food Ordering and Restaurant Operations Platform