↓ Skip to main content
Hakan Ates

Washbee — B2B Laundry Management API

·370 words·2 mins
Freelance NestJS TypeScript PostgreSQL TypeORM JWT
Hakan Ates
Author
Hakan Ates
I build full-stack applications and LLM-powered tools.
Table of Contents
A subscription-based backend for laundry companies: one multi-tenant API where each company manages its own customers, per-unit services, and orders.
Order creation flow from the Washbee app design
The app design for the order flow the API models: per-unit services, per-service extras, line items with totals, and pickup scheduling. UI design by the client’s UX designer.

Highlights
#

  • Designed and delivered a multi-tenant subscription backend for laundry companies as a solo freelance build (NestJS, TypeScript, PostgreSQL).
  • Modeled per-unit service pricing (per kg, base price, estimated turnaround) plus per-service addons like express 24-hour delivery.
  • Delivered 26 REST endpoints across 6 resource groups, from auth and tenant management through a daily-workload view (GET /orders/today).

How it works
#

flowchart LR
    LC[LaundryCompany
tenant] --> SV[Services
priced per unit]
    SV --> AD[Addons
e.g. express 24h]
    LC --> CU[Customers
VAT and billing details]
    SV --> LI[Line item
service + qty + addons]
    AD --> LI
    CU --> OR[Order
pickup/delivery, status,
payment status]
    LI --> OR
    OR --> TD[GET /orders/today
day's workload]

Case Study
#

Problem. A freelance client wanted to sell laundry-management software to multiple laundry companies as a subscription. Each company needed its own isolated slice of customers, pricing, and orders behind a single API, with basic and premium tiers they could switch between.

Approach. I made LaundryCompany the tenant root of the whole domain model. Every authenticated account resolves to exactly one company (GET /laundry-companies/my/company) and all reads and writes are scoped through it, which keeps tenant isolation a property of the model rather than a per-endpoint afterthought. Pricing lives on services (per-unit, e.g. per_kg, with turnaround estimates) with addons attached per service, and an order is a set of line items with pickup and delivery datetimes plus order and payment status. Schema changes went through TypeORM migrations, with docker-compose supplying Postgres for local runs. The app’s UI design came from an Italian UX designer on the project; my side of that collaboration was iterating on the screens with him and keeping the design aligned with the backend and the admin UI.

Outcome. Handed off to the client as a complete, documented build: 26 endpoints across auth, laundry-companies, customers, services, addons, and orders, with the API collection as the handover artifact. The client owned the launch from there.

Stack
#

NestJS, TypeScript, PostgreSQL, TypeORM, JWT bearer auth, REST/JSON, docker-compose.