CONTEXT · EXPLANATORY

Why the laundry industry needs a shared software architecture.

The industry is becoming increasingly connected, but most integrations remain organized around individual pieces of hardware.

Status: DraftVersion: 0.1Updated: July 25, 2026

The laundromat is already a distributed system

A modern site may combine washers, dryers, controller boards, QR payments, cash acceptors, pumps, lights, sensors, POS terminals and cloud software. These components fail, reconnect and change independently.

Even a small store is no longer simply a group of machines. It is a distributed physical system with financial and operational consequences.

The recurring problems

01

Hardware dependency

Business applications know channel numbers, board IDs or vendor-specific messages.

02

Fragmented integrations

Payments, machines and peripherals each use unrelated models and error behavior.

03

False success

A message was sent, but the system cannot prove that the machine actually started.

04

Cloud fragility

Essential local operations stop when connectivity or a remote service fails.

05

Difficult replacement

Replacing one controller requires changes across POS, backend and operations.

06

Poor observability

Failures cannot be traced clearly through cloud, edge, adapter and physical layers.

Why existing APIs are not enough

APIs can connect two systems, but an API alone does not create a shared model. Two vendors may both expose a “start” endpoint while disagreeing on identity, state, retries, confirmation and failure semantics.

The architectural shift

FROMController-centric

The board or protocol defines the system.

TOCapability-centric

Assets expose stable software behavior.

FROMCloud-dependent

Physical actions require remote availability.

TOLocal-first

The site can safely execute and record operations.

FROMMessage sent

Delivery is treated as success.

TOObserved result

Execution and physical confirmation are distinct.

Why this matters commercially

SDL is not only a cleaner engineering model. It reduces the cost of change. An operator can add a payment provider, replace a controller, adopt a smarter machine interface or introduce a new peripheral without discarding the entire platform.

Technology providers gain a clearer integration point and can specialize at the application, edge, adapter or device layer.

Why begin now?

The project begins while the installed environment is still diverse enough to test real constraints: legacy relay control, industrial wired communication, embedded controllers, local POS systems and emerging digital machine protocols.

That diversity is useful. A specification designed only for ideal future equipment would not solve the migration problem faced by real operators.