01Case study

TidyOps

Scheduling, staff and invoicing for cleaning businesses, rebuilt from a low-code platform onto infrastructure Zero One controls.

Sector: Field services · Cleaning
Year: 2026
Stack: TanStack Start · React · TypeScript · Express · PostgreSQL 17 · Docker · nginx · Cloudflare

02The problem

TidyOps runs the day-to-day of cleaning businesses: who works where tomorrow, what got done on site, who owes what. Its first version was built on a hosted low-code platform, a managed backend with a generated front end. That got the product running. It also meant the core of the business sat on someone else's servers, behind someone else's pricing, with a ceiling on what could be built next.

A platform dependency is a quiet liability. The vendor can reprice, get acquired or retire the product, and each of those decisions lands on you with no appeal. For software that schedules tomorrow's shifts and issues this month's invoices, that risk sits in the wrong place. The job was to take the platform out from under TidyOps and put infrastructure Zero One controls in its place, without touching what the software already did well.

03What we built

Three containers replaced the platform: a web front end, an API, and a PostgreSQL database. TanStack Start, React and TypeScript at the front, Express behind it, PostgreSQL 17 for data, Docker, nginx and Cloudflare around the lot. It runs on a single virtual server behind its own TLS certificate, with a separate development environment, and deploys with one script. No service sits in the stack that can lapse or reprice.

Authorisation lives in the database, not in application code. Tenant isolation is enforced by PostgreSQL row-level security: more than forty policies keyed to the current user, set on every request by the API. A query that forgets its filter returns nothing. Not an error page, and never another company's data. Most multi-tenant products enforce this in application code and hope every developer remembers. Here, the schema refuses.

In the product

Scheduling and dispatch. The office sees every job; each cleaner sees their day.
Public booking pages for each company, and recurring work that books itself.
Client records and service types in one place instead of in someone's head.
Staff availability, invitations, and owner and staff roles with the right access.
A checklist on every job, and a history of what was done, when, and by whom.
Invoicing, payroll and reporting drawn from the same job records.
Every company's data isolated by the database itself, not by good intentions.

Screenshot pending

Scheduling — the office view of the week, by staff member.

Screenshot pending

A job, its checklist, and its history.

Screenshot pending

The public booking page each company gets.

04Outcome

TidyOps runs in production today: one virtual server, its own TLS certificate, a separate development environment, deployment by one script. Nothing in the stack can lapse, reprice or disappear. There are more than forty row-level security policies in the schema, and zero measured numbers for revenue or hours saved. We'd rather show you the first than invent the second.