Home/Case Studies/EazyLaundry
React 18 & Vite 5Supabase BaaSPL/pgSQL TriggersMonorepo Architecture

Architecting a Dual-Client Laundry & Dry-Cleaning BaaS Ecosystem in 2 Months

How Pixel Web Services helped EazyLaundry build a serverless, mobile-first dual-app platform using React 18, TypeScript, and Supabase PostgreSQL. Features real-time WebSocket state sync, database-enforced role exclusivity triggers, touch safety gestures, and zero backend maintenance costs.

Client

EazyLaundry

Industry

On-Demand Logistics & B2C Services

Duration

2 Months (MVP to Production)

Services

BaaS Architecture, Monorepo, DB Triggers

System Topology

Serverless Monorepo Architecture Overview

The platform coordinates three distinct user cohorts—Retail Customers, Delivery Riders, and Store Operators—through two React 18 SPAs (eazylaundry & eazylaundry-partner) connected to a unified Supabase PostgreSQL BaaS instance.

Architecture Flow DiagramBaaS + WebSocket Topology
┌────────────────────────────────────────────────────────────────────────────────────────┐
│                        FRONTEND APPLICATIONS (MONOREPO)                                │
│                                                                                        │
│  ┌──────────────────────────────┐              ┌────────────────────────────────────┐  │
│  │   Customer Web App           │              │    Unified Partner Portal          │  │
│  │   (eazylaundry)              │              │    (eazylaundry-partner)           │  │
│  │   React 18 + Vite + TS       │              │    Rider & Store Operator Views    │  │
│  └──────────────┬───────────────┘              └─────────────────┬──────────────────┘  │
└─────────────────┼────────────────────────────────────────────────┼─────────────────────┘
                  │ Delayed Auth OTP                               │ Post-Login Auto Route
                  ▼                                                ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│                        SUPABASE CLOUD BAAS PLATFORM                                    │
│                                                                                        │
│  ┌──────────────────────────────┐              ┌────────────────────────────────────┐  │
│  │   Supabase Auth Engine       │              │   Realtime WebSocket Channel       │  │
│  │   (Phone SMS OTP Broker)     │              │   (Instant Order State Push)       │  │
│  └──────────────┬───────────────┘              └─────────────────▲──────────────────┘  │
│                 │                                                │                     │
│                 ▼                                                │ Broadcast           │
│  ┌───────────────────────────────────────────────────────────────┴──────────────────┐  │
│  │   PostgreSQL 15 Database                                                        │  │
│  │   • Row Level Security (RLS) Policies                                           │  │
│  │   • PL/pgSQL Role Mutual Exclusivity Trigger (check_partner_type_exclusivity)  │  │
│  │   • Automated Payment Transition Trigger (update_payment_status_on_delivery)    │  │
│  └─────────────────────────────────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────────────────────────────────┘
PL/pgSQL Role Exclusivity TriggerPostgreSQL 15
CREATE OR REPLACE FUNCTION check_partner_type_exclusivity()
RETURNS TRIGGER AS $$
BEGIN
  -- Prevent rider profile from getting a store_id
  IF TG_TABLE_NAME = 'profiles' AND NEW.store_id IS NOT NULL THEN
    IF EXISTS (SELECT 1 FROM partners WHERE id = NEW.id) THEN
      RAISE EXCEPTION 'User is already registered as a delivery partner.';
    END IF;
  END IF;

  -- Prevent store user from creating a rider record
  IF TG_TABLE_NAME = 'partners' THEN
    IF EXISTS (SELECT 1 FROM profiles WHERE id = NEW.id AND store_id IS NOT NULL) THEN
      RAISE EXCEPTION 'User is already assigned to a store.';
    END IF;
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Auto Payment Transition TriggerPostgreSQL 15
CREATE OR REPLACE FUNCTION update_payment_status_on_delivery()
RETURNS TRIGGER AS $$
BEGIN
  -- Automatically transition pending payments on delivery
  IF NEW.status = 'delivered' AND OLD.status != 'delivered' THEN
    NEW.payment_status := 'paid';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trigger_update_payment_status
  BEFORE UPDATE ON orders
  FOR EACH ROW EXECUTE FUNCTION update_payment_status_on_delivery();
Risk-Based Quality Assurance

Automated Test Strategy & Coverage Breakdown

To ensure bulletproof financial processing and data security across multi-actor operations, the codebase uses a 4-tier risk-based testing roadmap combining Vitest, pgTAP, and Playwright.

Testing Scope / DomainTool / FrameworkTarget CoveragePrimary Focus
Financial & Tax CalculationsVitest unit tests100%Cart subtotals, GST tax, distance delivery fees, custom price on call
Role Auto-Routing & AuthReact Testing Library100%AuthContext post-login detection & partner type context
DB Mutual Exclusivity TriggerspgTAP Postgres tests100%check_partner_type_exclusivity() enforcement & RLS policies
Order Lifecycle & WebSocketsPlaywright E2E90%10-step multi-actor scenario across Customer, Rider, and Store contexts
01 The Challenge

Unorganized Laundry Logistics & High Friction

Traditional retail laundry operations in emerging markets suffer from severe fragmentation. Manual phone bookings, paper tags, lost garments, and uncoordinated Cash on Delivery (COD) handoffs lead to high customer drop-off and operator errors.

High Guest Checkout Drop-off

Apps requiring SMS OTP verification before users can browse pricing suffer from a 60%+ drop-off. Customers want clear pricing quotes first.

Role Conflict & Fraud Risk

In multi-actor networks, individuals attempting to act as both delivery riders and store operators introduce financial conflicts of interest and misallocated commissions.

Field Touch Errors

Riders navigating traffic on smartphones easily trigger accidental button taps, corrupting database order lifecycle states.

02 Our Approach

Modern Tech Stack & Architectural Decisions

We designed a serverless BaaS architecture using React 18, Vite, and Supabase PostgreSQL. Every component was selected to maximize speed, security, and developer ergonomics.

React 18 & Vite 5React 18 & Vite 5
Frontend Core

React 18 & Vite 5

Component-driven architecture with fast concurrent rendering for real-time order status UI updates and instant HMR development.

TypeScript 5.8 & Tailwind CSSTypeScript 5.8 & Tailwind CSS
Type Safety & Styling

TypeScript 5.8 & Tailwind CSS

Strict compile-time domain contracts across monorepo packages paired with responsive utility-first design tokenization.

Supabase (PostgreSQL 15)
Backend-as-a-Service

Supabase (PostgreSQL 15)

Relational data integrity, instant REST APIs, built-in phone OTP auth, Row Level Security (RLS), and WebSockets without backend overhead.

Playwright, Vitest & pgTAP
QA & Test Automation

Playwright, Vitest & pgTAP

Risk-based testing covering financial calculations (Vitest), PL/pgSQL exclusivity triggers (pgTAP), and multi-actor browser flows (Playwright).

03 The Solution

Implementation Phases & Key Features

The system was architected and delivered across three structured 2-week iterations, transitioning from core database schema modeling to real-time partner dashboard sync.

01

Domain Modeling & Schema Architecture (Weeks 1–2)

Modeled 7-stage order state machine, configured PostgreSQL Row Level Security (RLS) policies on Supabase, and wrote PL/pgSQL database triggers for role mutual exclusivity.

02

Customer App & Delayed Auth Funnel (Weeks 3–5)

Built the mobile-first customer web app (eazylaundry) allowing guest catalog browsing and cart building, delaying SMS OTP authentication to the final checkout step.

03

Unified Partner Portal & Real-Time Sync (Weeks 6–8)

Constructed eazylaundry-partner featuring post-login role auto-detection, touch safety slide-to-confirm gestures for riders, and desktop management tables for store operators.

Touch Safety: Slide-to-Confirm Pattern

To protect against accidental field clicks while driving or handling garments, critical order state updates on the rider app (e.g. claiming tasks, pickup confirmation, and COD collection) require a drag gesture (SlideToAction.tsx). Firing occurs only when the drag distance exceeds 90% of the track width.

04 Quantifiable Results

Business Impact & Operational Metrics

Deploying the EazyLaundry BaaS platform achieved immediate measurable wins across booking conversion rates, store throughput, and infrastructure maintenance costs.

Order Booking Time
Manual Calls & WhatsApp4+ Minutes
Delayed OTP Web App< 45 Seconds
80% Time SavedFrictionless guest checkout
Store Order Processing
Uncoordinated HandoffsPaper Receipts
Unified Partner UISingle Portal
3x SpeedupZero garment misplacements
Server Maintenance
Node/Go InfrastructureDedicated Servers
Supabase BaaS Model$0 / Month
Zero Ops Overhead100% Serverless Architecture
"By moving our core business logic directly into Supabase PL/pgSQL database triggers and deploying a delayed OTP guest checkout, Pixel Web Services enabled us to ship a production-grade dual-app platform in 2 months with zero recurring backend server costs."

EazyLaundry Engineering Team

Product & Architecture Leadership

05 Key Takeaways

Engineering Insights for Product Leaders

Four key architectural lessons for CTOs and engineering directors building modern multi-party logistics applications.

01

Leverage BaaS for Real-Time Multi-Actor Logistics

When building real-time apps requiring instant synchronization across customers, riders, and store operators, Supabase BaaS with PostgreSQL RLS provides a robust alternative to custom Node.js/Go middleware.

02

Push Core Business Rules to Database Triggers

Application-level checks can be bypassed by API calls or frontend bugs. Moving critical constraints—such as role mutual exclusivity and automated payment transitions—into PostgreSQL PL/pgSQL triggers guarantees total data integrity.

03

Delay Authentication to Maximize Conversion

For consumer-facing service platforms, allow guest browsing, catalog selection, and cart building before requiring phone OTP authentication. Pushing authentication to the final confirmation step dramatically reduces top-of-funnel drop-off.

04

Design Touch Safety Gestures for Mobile Field Workers

Field workers operating mobile devices in dynamic environments require UI mechanics designed for touch safety. Replacing standard tap buttons with slide-to-confirm touch drag gestures prevents accidental state transitions.

Ready to Build Your Serverless BaaS Ecosystem?

Whether you need real-time multi-actor sync, database trigger security, or high-conversion web workflows, our team delivers production-ready engineering in weeks.