Under a minute to book. Three minutes to a cleaner.
Pachaca is an on-demand cleaning and dry-cleaning service in Kyiv. We built their entire digital stack from scratch: a native iOS app, a native Android app, a full web booking service, and the internal system the operations team uses to run the business day to day.
Four products, one system.
It launched in Kyiv from zero, and a hundred people signed up in the first two days. Odesa is next.
This article isn't really about the hundred – that's a marketing result, and Pachaca produced it themselves. It's about what happened when those people arrived: how far they had to travel to get from "I need this handled" to a named cleaner accepting the job, and the two decisions that made that distance short.
Both decisions were about removal.
The constraint that shapes everything
An on-demand service business has a property that software businesses don't: the value is delivered by a person who has to physically show up.
That sounds obvious and it changes the entire product:
The service only works where you have enough cleaners for the density of orders. One city at a time, not a national launch.
Every booking is a scheduling problem with a human on the other end, not a database write.
The operations team isn't overhead – they're the product, and their tooling sets the ceiling on how many orders the business can physically handle.
A mishandled order costs you a customer and a frustrated cleaner. At the start, both sides are scarce.
That last point is the one founders underestimate. A cleaning service is a two-sided product wearing a service business's clothes, and it has all the two-sided failure modes. Customers won't come back if nobody accepts their job. Cleaners won't stay in the pool if the work is thin or the coordination is chaotic. Everything below is a version of the same problem: keeping the distance short on both sides.
Decision one: the two-question booking form
The instinct came from the founder.
He wanted booking to feel like ordering a taxi – pick what you need, pick when, done. Which cut against what a cleaning business normally wants to know before sending someone into your home: apartment size, number of rooms, product preferences, access instructions, pets. Every one of those questions is defensible. Every one of them makes the cleaner's job easier.
So we checked it properly rather than just agreeing. We looked at how comparable on-demand services structure their booking flows, where they place each question, and what they've evidently learned to move out of the way. The pattern was consistent enough to settle the argument: the services that survive don't ask less because they need less. They ask later.
That reframed the problem. The question was never whether to collect the details – it was where each one belongs. So we went through the form field by field and sorted every question into one of three places: before the confirmation, after it, or in the cleaner's hands.
Two stayed before: what, and when. Everything else moved.
Why long forms happen anyway
The instinct behind a long booking form isn't carelessness. It's a real trade-off being resolved in the wrong direction, for a structural reason.
Every question you ask before confirmation buys operational certainty and costs completions. The trap is that the two sides of that trade are visible to different people. The operations team feels every missing detail – a cleaner arriving without the right equipment is a concrete, memorable failure that generates a complaint and a meeting. Nobody feels the abandoned bookings, because those people never existed as far as the business is concerned. They opened the app, saw six fields, and closed it. No complaint, no ticket, no data.
The pressure is permanently asymmetric. Fields accumulate, because each one has an advocate and nothing pushes back.
The second problem is timing. People book a cleaner at the moment intent is highest and patience is lowest – usually a specific "I need this handled today." Asking about square metres and pet policy at that moment isn't gathering requirements. It's interrupting a decision that was already made.
Where the questions went
Cutting the form only works if the information still arrives. It does – later, and often from a better source.
After the confirmation. Once someone has booked, the psychology inverts. Three optional questions about access and preferences are no longer an obstacle between them and the thing they want; they're the customer making sure it goes well. The same questions get answered at a far higher rate on the other side of the commitment.
In the cleaner's hands. A trained cleaner standing in an apartment assesses its size, condition and requirements in about ten seconds, more accurately than a customer estimating from memory. Asking the customer to describe what a professional can see immediately is asking the wrong person.
From history. By the second booking, the system knows the address, the apartment and the preferences. The repeat booking – which is where the actual business is – becomes near-instant.
The result: pick a service, pick a time, confirm. Under a minute. Push notifications carry the rest, from confirmation through to the cleaner arriving at the door.
Decision two: no app for the cleaners
The clearest example is on the other side of the transaction.
Cleaners don't use an app. They use a chat, because that's where they already were – a group they check dozens of times a day out of habit, on a phone they're already holding between jobs.
So instead of asking them to install something, register and learn an interface, we put a bot in the chat they were already in. A new order arrives, the bot posts it, and any available cleaner claims it with a single tap. The message updates in place for everyone else, so there's no double-claiming and no dispatcher in the middle asking who's free.
Orders get claimed in one to three minutes. No app install, no onboarding, no training session.
The textbook version is a cleaner-facing mobile app with a job queue, a profile and a schedule. We could have built it. It would have looked better in a case study, and adoption would have been a fraction of what a chat message gets – because adoption isn't a design problem, it's a habit problem, and the habit already existed somewhere else.
On the customer side we removed questions. On the cleaner side we removed the app. Both are the same decision: put the action where the person already is, and don't make them travel to your product to do it.
End to end, the gap between a customer deciding they need a cleaner and a named person having accepted the job is around four minutes, with nobody coordinating it.
The system that absorbs the complexity
Simplifying both sides of a transaction doesn't delete complexity. It moves it – into the internal system, which is the larger half of this project and the half with no screenshots.
The operations team needs full real-time control: incoming orders, cleaner assignment, service area coverage, and the live status of every job. When the booking form stops collecting details up front, the operations tooling has to be good enough that the team handles exceptions quickly – reassign, reschedule, add information, contact a customer, adjust a job in flight.
This is the trade we'd make every time. Friction on the customer side costs you customers you never hear about. Friction on the operations side costs you a process you can fix. Only one of those is recoverable.
What generalises
Pachaca is a cleaning service, but the pattern holds anywhere a person delivers the value – repairs, tutoring, beauty, moving, maintenance, medical:
Count the taps between intent and confirmation. That number is a growth channel with a fixed cost. Removing two is worth more than most features on your roadmap.
Audit your form for questions with an advocate. Every field got there because someone had a good reason. Ask the opposite question: what breaks if we remove it, and can operations absorb it? A surprising number can.
Move collection to after commitment. Same questions, different moment, completely different completion rate.
Check whether the customer is even the right source. Often the person delivering the service knows better and can assess on arrival.
Meet your supply side where they already are. Before building an app for the people doing the work, find out what they already open forty times a day. Adoption you don't have to win is worth more than an interface you designed.
Then over-build the internal tooling. Everything you take off both sides lands on your team. If their system is weak, the simplification quietly turns into cancellations.
What we'd claim and what we wouldn't
A hundred people hearing about a new cleaning service in two days is a marketing result, and Pachaca produced it themselves. The instinct to make booking feel like ordering a taxi was theirs too.
What we'd claim is narrower and more specific. We tested that instinct against the market instead of just agreeing with it. We worked out which questions could move and where they belonged. We met the cleaners in the chat they were already using instead of building them an app nobody would open. And we built the operational system that lets a two-question booking form survive contact with reality.
Under a minute to book. One to three minutes to a named cleaner accepting the job. Nobody coordinating it.
That part is engineering – and it's the part that decides whether a marketing spend produces customers or produces traffic.
We build marketplaces, P2P products and on-demand services – the kind where the operational system matters as much as the app. If you're building something where a person has to show up, the first call is free and we'll tell you honestly what's worth building and what isn't.