Skip to main content

A multi-tenant operations platform

I modeled a company.

Employees, projects, approvals, assets, leave, billing — a launched multi-tenant SaaS, modeled as one coherent system. The page opens with the model, not a screenshot.

Visit My Tracker
  • Backend Engineering
  • API Architecture
  • SaaS Platform Development
  • Multitenancy & Billing Systems
Tenant workspaceEmployeesLeaveProjectsApprovalsBilling / PlansAssets

// the model, in daily use

The same model, alive in a workday.

Every node in that graph becomes a surface a real company touches daily. The product UI is the team's; the model underneath — the tenancy, the modules, the routed workflows — is mine.

Execution // projects · tasks · insight

My Tracker dashboard — active and overdue task counts, working-hours, a project-health ring, and an activity feed.
// tenant.dashboard — KPIs, project health, activity
A project's Kanban board — Todo, Progress and Completed status columns with task cards.
// projects.kanban — custom status workflow

Platform & operations // analytics · billing

Project analytics — a date-ranged view of finance totals and tasks-behind for a project.
// projects.analytics — health, hours, cost
The tenant's subscription — an active plan with usage limits and the feature set gated by that plan.
// billing.subscription — Stripe plans, feature gating

// underneath: the platform

Go under the surface.

The dashboard is what a tenant sees. This is what runs it — the same model, one layer down.

  1. 01

    Multitenancy

    A landlord/tenant database split — every company isolated in its own workspace, resolved by domain. spatie multitenancy + permission.

  2. 02

    Feature-gated plans

    Capabilities switch on per plan tier — what a tenant can reach is gated by the plan it is on.

  3. 03

    Stripe billing

    Subscriptions through Cashier — plan lifecycle, proration, and limits wired to Stripe.

  4. 04

    Audited end to end

    spatie auditing across the domain — every status change on every request leaves a logged trail.

// the engine, made visible

A request routes itself.

Payment, VAS, asset, purchase, and subscription requests all flow through one routed chain — each gate a state in an audited machine. Here is a purchase request finding its way to done.

  1. Requested
  2. Manager
  3. Revenue Assurance
  4. CEO
  5. Owner
  6. Completed
A purchase approval detail — Manager and Revenue Assurance gates approved, CEO/Owner/Completed pending, beside the request status and its audited gate log.
// approvals.form — a request + its audited gate log

// scale, honestly

A system with real surface area.

Every figure here is code-derived — the shape of the model, never a tenant's data.

110
migrations
~75
domain models
53
notification types
3
plan tiers
  • Laravel 10 API
  • Blade admin
  • Sanctum
  • spatie · multitenancy / permission / auditing
  • Cashier · Stripe
  • Redis
  • SES
  • Pusher