Skip to content
Alex ALAVO

Engineering Case Study · LeBonDon

Designing a tested multi-role platform for inventory, exchange and social distribution

LeBonDon manages stock, exchanges and distribution between associations, companies and beneficiaries. Its LeBonDestock module creates a complete B2B flow for discounted unsold inventory.

Role
Full-stack architecture, service-layer design, authorization, frontend implementation, automated testing and CI quality workflow.

System Responsibilities

  • SaaS
  • Testing

Technologies

  • Laravel
  • React
  • TypeScript
  • Inertia
  • Spatie Permission
  • Playwright
  • GitHub Actions
  • Docker

Verified Evidence

7 verified results documented below.

Overview

Associations, companies and beneficiaries operate with different permissions and goals, and the destocking flow crosses company submission, administrator evaluation and association purchase.

  • Manage inventory and donations.
  • Support association exchanges.
  • Track beneficiary distribution.
  • Enable company destocking.
  • Enforce role-specific permissions.
  • Protect critical end-to-end flows.

The problem

The platform serves actors with different permissions and operational goals. The destocking flow crosses company submission, administrator evaluation and association purchase, making correctness across roles essential.

Constraints that shaped the system

  • Multiple actor types.
  • Complex authorization rules.
  • Business logic should not accumulate in controllers.
  • Frontend and backend behavior must remain consistent.
  • Critical flow required reproducible browser testing.
  • Deployment needed automated quality gates.

System architecture

Laravel owns the domain and service layer, React and Inertia provide the interactive interface, Spatie Permission controls roles and Playwright verifies the complete business flow through reusable page objects and authenticated fixtures.

System architecture diagram: Browser (React + Inertia), Laravel Application, Service Layer, Spatie Permission, Database, Playwright E2E Suite.

client

Browser (React + Inertia)

Key engineering decisions

Strict service layer

Accepted

Business logic should not accumulate in controllers.

Keep controllers focused on HTTP concerns and move business operations into services.

Why

  • Easier tests.
  • Lower controller complexity.
  • Better reuse.
  • Clear ownership of domain behavior.

E2E Page Object Model

Accepted

The critical destocking flow required reproducible browser testing.

Represent user-facing areas through reusable page objects and fixtures.

Why

  • Reduce selector duplication.
  • Improve test readability.
  • Support stable CI execution.

Role-based authorization

Accepted

The platform serves actors with different permissions and complex authorization rules.

Centralize permissions using a proven authorization package and server-side checks.

Why

  • Consistent access rules.
  • Easier audit and maintenance.

Implementation highlights

  • LeBonDestock B2B destocking module for discounted unsold inventory.
  • Company submission, administrator evaluation and association purchase flow.
  • Role-specific permission enforcement across actor types.

Quality and operations

Testing

  • PHPUnit test coverage.
  • Playwright end-to-end coverage for the destocking flow.

Operations

  • Docker containerization.
  • Railway deployment.
  • GitHub Actions CI workflow.

Results and evidence

  • Implementation fact

    Multi-role authorization

  • Implementation fact

    Strict service layer

    Controllers kept small through service extraction

  • Observable capability

    Complete destocking flow implemented and tested

  • Implementation fact

    PHPUnit and Playwright quality coverage

  • Implementation fact

    Page Object Model for E2E tests

  • Implementation fact

    GitHub Actions CI workflow

  • Observable capability

    Docker and Railway deployment workflow

Lessons from the system

  • Critical workflows should be tested from the user's perspective.
  • Authorization belongs on the server even when the UI hides actions.
  • A service layer is useful when it reflects domain responsibilities, not when it merely adds files.