CleanLoop

CleanLoop turns laundry pickup and delivery into one coordinated, auditable operation across customers, drivers, laundry partners, payments, and platform teams.

Comment

Inspiration

CleanLoop started with a simple question: why does laundry pickup and delivery feel so easy to the customer while being so difficult for everyone operating behind the scenes?

What appears to be one simple order actually crosses four different worlds: customer intent, driver transportation, laundry production, and money. Small and mid-sized laundries often coordinate that entire process through phone calls, spreadsheets, text messages, and disconnected tools.

The deeper I worked on the problem, the clearer it became that CleanLoop could not be just another app for requesting a laundry pickup. The real challenge was coordinating the promise made to the customer across every person, handoff, payment, bag, pound, and piece of evidence involved in completing the service.

I created CleanLoop to make that operation visible, coordinated, and accountable from beginning to end.

What it does

CleanLoop is a multi-actor operating platform for recurring and on-demand laundry logistics.

A customer reviews the pickup details, plan pounds, price, and payment before submitting one order. That customer order then releases an independently assignable pickup service from the customer to the laundry.

The laundry confirms custody, reconciles the bags, records the final weight, and moves the order through production. When the laundry marks the order as ready, CleanLoop releases a separate delivery opportunity from the laundry back to the customer.

The pickup and delivery services may be completed by the same driver or by two different qualified drivers. The customer order closes only after delivery is confirmed, the required evidence is recorded, and any blocking exceptions are resolved.

Customer, Driver, Laundry Partner, and Admin/Super Admin each receive a focused experience with one clear responsibility.

The financial stages remain connected to the same operation: customer quote and charge, driver earnings, laundry partner amount, platform margin, and payout readiness.

CleanLoop is designed to keep the commercial promise, the physical custody of the laundry, the operational workflow, and the movement of money connected without treating them as the same thing.

How we built it

CleanLoop uses ASP.NET Core .NET 8, Clean Architecture, Entity Framework Core, and PostgreSQL for its multi-tenant backend.

Flutter powers the Customer and Driver experiences across Android, iOS, and Web. Blazor is used for laundry operations, administration, and the Super Admin platform layer.

The product also includes Stripe hooks for billing and Connect, Firebase Cloud Messaging, Google Maps, Azure infrastructure templates, and Netlify for the public product experience.

Codex was part of almost the entire development journey of CleanLoop. I used it while navigating the codebase, implementing features, resolving technical problems, reviewing interfaces, testing workflows, and continuously improving the product.

CleanLoop already existed as an early product before Build Week, so I wanted to be transparent about what was already there and what was meaningfully improved during the event. The July 13 baseline and the following 22 dated commits document that work clearly.

During Build Week, I separated the customer Order from independently assignable pickup and delivery Services. I added idempotent submission and service-release rules, concurrency protection, custody evidence, bag reconciliation, final-weight controls, payout policies, and stronger operational validations.

I rebuilt the Customer and Driver flows, turned the Laundry Partner portal into a production workbench, and rebuilt Admin as an operations control tower.

I also added bilingual quality checks, responsive tests, continuous integration, repository hygiene, and clearer documentation of the boundary between the current working product and the controlled pilot environment that comes next.

The README documents the baseline, commit range, architecture, setup instructions, testing path, sample data, results, and the areas where Codex and GPT-5.6 accelerated the work.

How Codex and GPT-5.6 helped

My relationship with Codex evolved throughout the development of CleanLoop.

At first, I mainly used Codex to help me implement features, inspect files, correct problems, and move faster across a large codebase with backend, web, mobile, operational, and commercial surfaces.

During the final two weeks, I learned how to use GPT-5.6 through Codex much more intentionally. What impressed me most was not only its ability to produce code. It was how it could analyze CleanLoop as one complete operating system.

Instead of asking only for a screen or a feature, I began asking deeper questions:

What happens if two drivers try to accept the same service?

What happens if the customer taps the submit button twice?

What happens if a webhook is delivered more than once?

Does “ready” mean the laundry finished production, or does it mean the entire customer order is complete?

Who owns the bags at each stage?

When should money become eligible for payout?

Those questions changed the quality of the product.

GPT-5.6 helped me challenge weak assumptions, identify inconsistencies between Customer, Driver, Laundry Partner, Admin, and financial records, and translate real operational rules into enforceable software invariants.

It also helped inspect the cross-platform codebase, design state machines, implement changes across the domain, API, and UI, write focused tests, audit English and Spanish copy, validate compact Android layouts, and document the production boundary.

The collaboration remained human-led.

As founder and product owner, I made the final decisions about the operation, pricing, workflows, evidence requirements, and payout rules. I described the real-world problem and the behavior I expected. Codex with GPT-5.6 helped me analyze the consequences, implement the changes, test the results, and discover weaknesses that I might not have identified as quickly on my own.

I did not simply accept every suggestion. I reviewed the changes, tested the workflows, corrected assumptions, and decided when each part was ready.

Some of the most valuable moments were not when GPT-5.6 immediately produced code, but when its analysis forced me to reconsider how the operation should actually work.

Challenges

The hardest challenge was resisting a traditional route model.

A customer may see one laundry order, but the operation may involve two different drivers and a complete laundry production stage between them. The pickup driver is not necessarily responsible for the delivery, and marking the laundry as ready cannot mean that the customer order is completed.

This required separating the customer promise from the individual services used to fulfill it.

Another major challenge was making retries and concurrent actions safe.

Double taps, duplicate webhooks, concurrent driver acceptance, repeated readiness events, and failed network requests must never create duplicate orders, services, pounds, evidence, earnings, or payments.

These situations required clear state transitions, idempotency, concurrency protection, auditability, and a precise definition of responsibility for every actor.

The challenge was not only making the interfaces look complete. It was making sure the same words and actions meant the same thing across the mobile applications, laundry production, administration, backend rules, and financial records.

Accomplishments that we're proud of

  • 76 of 76 backend tests passing in Release
  • 12 of 12 Customer Flutter tests passing
  • 12 of 12 Driver Flutter tests passing
  • Both mobile applications validated on a physical Samsung device
  • Complete English and Spanish primary product surfaces
  • A live product website and guided walkthrough
  • A clear and testable Build Week commit history
  • Independent pickup and delivery services connected to one customer order
  • Stronger custody, bag, weight, evidence, exception, and payout controls
  • A Laundry Partner production workbench
  • An Admin and Super Admin operations control tower
  • A documented path from the current product to a controlled real-world pilot

What we learned

The biggest lesson was that operational software is built on precise meaning.

A word such as “ready,” “paid,” “accepted,” or “completed” may look like a simple interface label, but it also acts as a business contract between the customer, driver, laundry partner, administrator, and financial records.

Every state must answer a real question:

Who is responsible now?

What evidence is required?

What can happen next?

What must be prevented?

When can money move?

I also learned that using AI effectively is a skill of its own.

At the beginning, I often used Codex mainly to move faster. During the final two weeks, I learned that GPT-5.6 became much more valuable when I gave it complete context, explained the real operation, asked it to challenge my assumptions, and allowed it to analyze the relationships between different parts of the product.

The quality of my questions changed the quality of the results.

Codex accelerated implementation, but the strongest improvements came from combining that speed with human product judgment, operational experience, clear responsibility boundaries, measurable invariants, and repeated testing.

CleanLoop became stronger not because AI replaced the product decisions, but because it helped me examine those decisions more deeply.

What's next for CleanLoop

The next step is to deploy a controlled Azure pilot environment, complete a full Stripe test transaction, validate a real Firebase notification, and run one order from beginning to end with one laundry partner and known drivers.

The first pilot will focus on proving that the operation works consistently in the real world, not on growing too quickly.

I want to measure on-time pickup and delivery, custody exceptions, weight differences, driver acceptance, laundry production performance, repeat customer usage, payout readiness, and unit economics.

Those results will guide the next version of CleanLoop before expanding to additional laundries, drivers, service areas, and customers.

The long-term goal is to give independent laundries the operating infrastructure needed to offer a modern pickup, delivery, membership, and tracking experience without having to build an entire technology company themselves.

Built With

Share this project:

Updates