Case Study: Laundry Marketplace Development with AI-Assisted Customer Support via Anthropic API

SnapWash is a New York on-demand dry cleaning and laundry marketplace connecting three sides: customers who need garments cleaned, the cleaners and laundries that do the work, and the drivers who move bags between them. The founder, Gabriel Sezanayev, has run businesses for more than ten years — Prestige Royal Liquors, the spirits company behind 3 Kilos Vodka and Pinaq Liqueur, and SWEATLAB:54, a three-studio fitness network across Long Island and Queens. SnapWash is his first software product, built for the customer he already serves: the person with no spare hour for an errand that takes two trips.

Our client came to the problem as a customer first. Dry cleaning in the US still runs offline: orders are taken at a counter, prices are quoted by hand, and there is no digital channel to place a job, see what it costs, or check whether it's ready. He wanted to create a product that would make dry-cleaning services easier for busy people, and he needed a reliable technical partner to achieve the following goals:

• Make ordering take seconds, not minutes. Whatever the app asked of a customer had to be faster than walking to the counter, or the product had no reason to exist.
• Run the full service in one place. Ordering, payment, pickup, cleaning, and return delivery, with customers, cleaners, and drivers working inside the same system instead of over phone calls.
• Get cleaners paid at order time. Dry cleaners wait until pickup to see money for work already done. Charging upfront turns that around and gives retailers a reason to join the platform.
• Launch small and test with real users. A first release his own studio members could run through before opening in New York.

What our client did not have was the means to build it. No engineering team, no architecture, and no technical background to evaluate one. He needed a single partner to carry the idea from a rough concept to a released app.

Our client built his vendor shortlist himself. Cleveroad held the highest Clutch rating on that list, so he read the case studies and the service range before writing in. The reply came back the same day he sent the request.

What separated Cleveroad happened before a contract existed. A Solution Design Workshop with a solution architect turned the raw idea into a plan covering scope, technical approach, budget, and timeline. The proposal that followed offered three options instead of one: a larger team to move faster, a smaller team to hold budget, and a separate setup for post-release support, each costed. That is how Cleveroad structures software development for startups — the founder picks the trade-off rather than receiving it.

The engagement ran in two stages: three weeks of Discovery to fix the plan, then six months of development to reach release. A 13-person team covered all four applications and the infrastructure under them.

A three-week Discovery phase turned the business goals into an engineering plan. Cleveroad's team broke down scope across all four roles, stress-tested the assumption the whole product rested on, fixed the architecture, and priced the production infrastructure, naming known cost risks rather than burying them.

Our client approved a defined set of artifacts before development started: a prioritized feature breakdown, business-flow and BPMN order-lifecycle diagrams, design concepts, a software architecture document written to ISO/IEC/IEEE 42010 with testable quality-attribute scenarios, and an infrastructure cost estimate. He signed off on a scope he could see the edges of instead of an open-ended budget.

Cleveroad's team solved seven major technical challenges while building SnapWash. Some came out of Discovery, others appeared once development was underway.

Garment recognition had to be reliable enough to charge money against. This is the feature the product rests on. Cleveroad evaluated specialized vision platforms during Discovery and selected one, but real garment photos exposed stability problems and results too inconsistent to price an order. Mid-development, the team replaced it and rebuilt recognition on a general-purpose vision model, which also reduced the number of third-party services in the stack. That version reached a working state quickly and is what runs in production.

Support had to be AI-assisted from day one. Our client planned to launch SnapWash with a lean back office, effectively one admin covering every customer inquiry, making support the first bottleneck at launch. Cleveroad planned for that from the start: an agentic assistant on the Anthropic API with read-only tools over the order API, grounded in real order fields and backend statuses, plus an escalation matrix for cases that need a human. The agent consults rather than acts, which made it safe to ship as the default support entry point.

Four clients share one backend. Customer app, driver app, retailer web app, and admin panel run against a single order lifecycle, so a change on one side almost always touches the other three. Cleveroad built the backend as Node.js microservices communicating over an EventBridge event bus, which kept order creation, payment, and recognition decoupled. When a mid-project change forced several app sections to be redone, the team returned a revised schedule based on what the change actually cost rather than a date that sounded good.

One payment settles three ways. A single charge at order creation splits to two different merchant account types, retailer and driver, plus the platform fee. Stripe handles the capture and the connected merchant payouts, and drivers cannot receive money until KYC verification through the admin panel clears.

Live tracking fights the operating system. iOS and Android throttle background location, so GPS pauses the moment a driver opens a third-party navigation app. Continuous tracking is only guaranteed inside SnapWash's own map, so the driver flow was designed to keep navigation in-app, with route guidance on Google Maps built into the screen the driver already works from.

The release window was fixed. To protect it, Cleveroad reused rather than rebuilt: the Elstar Tailwind UI kit for the retailer and admin frontends, a styleguide-driven approach for both Flutter apps, and standard components everywhere the product was not differentiated. Design and engineering effort concentrated on the AI ordering flow. Two QA engineers tested every sprint alongside development, with Sentry, CloudWatch, and Crashlytics covering runtime.

One pleasant surprise for our client was that Cleveroad's CEO stayed involved in the product itself, bringing his own suggestions on interface, functionality, and animation options rather than leaving it to the delivery team.

Here's what Gabriel Sezanayev, founder of SnapWash, says about working with Cleveroad:

Cleveroad settled the stack during Discovery, before development started.

• Mobile: Flutter (customer and driver apps, iOS and Android)
• Web: React.js with the Elstar Tailwind UI kit (retailer tablet-first app, admin panel)
• Backend: Node.js microservices in Docker on AWS Fargate, Application Load Balancer, EventBridge event bus, CPU-target auto-scaling
• Data: AWS RDS MySQL (encrypted at rest), S3 for garment photos and KYC documents, KMS
• AI: Vision model for garment type and color recognition with confidence thresholds and manual-correction fallback; agentic support assistant on the Anthropic API with read-only tools over the order API
• DevOps: GitLab CI/CD → CodeBuild → ECR → ECS/Fargate, Terraform/CDK, Route 53, CloudFront, Secrets Manager
• Integrations: Stripe (payments and merchant payouts), Google Maps/Places, Firebase FCM, PubNub (chat), Twilio (SMS OTP), Amazon SES, Google/Apple Sign-In
• Security: AES-256 at rest, TLS 1.3 in transit, OAuth 2.0 / JWT, role-based access control

As a result of our cooperation, the client received a full dry cleaning ecosystem: four applications on one backend, covering the whole service loop. Customers and drivers each get a Flutter app running on iOS and Android. Cleaners work from a tablet-first responsive web app. The fourth application is the admin panel, where SnapWash verifies drivers, activates retailers, and oversees every order.

SnapWash is published on the App Store and Google Play, with the retailer app and admin panel running on the web. The launch ran first through members of our client's SWEATLAB:54 studios, then opened to the public. Cleveroad has continued to ship updates since release.