Petlio

Overview

Petlio started as a hunch: pet parents wanted an easier way to find sitters they could actually trust, and sitters wanted a straightforward way to get booked without haggling over DMs and spreadsheets. The brief was to find out — fast — whether a real, two-sided marketplace could work, and to have something people could use, not just look at.

The Problem

Trust is the whole product in a marketplace like this. A pet parent won't book a stranger to watch their dog for a week, and a good sitter won't waste time on unqualified leads. Most early attempts at this kind of platform either over-engineer the trust layer before anyone's used it, or skip it entirely and end up with a directory nobody books through.

Approach

Rather than designing every feature a mature marketplace might eventually need, the focus stayed on the smallest version that could prove both sides would actually transact:

• A simple, verified sitter profile — enough detail to build confidence, nothing that slowed onboarding down.
• A booking flow built around clarity, not options: what, when, how much, confirmed.
• A visual identity that felt warm and personal rather than like enterprise software — this is about someone's pet, not a logistics platform.

What Shipped

Strategy, design, and build happened in the same loop, not in handoffs — the sitter verification flow and the booking UI were designed and built together, so nothing got redesigned after the fact to fit engineering constraints. Brand and product decisions were made by the same person in the same sitting, which meant the tone of the copy, the shape of the UI, and the actual booking logic never drifted apart from each other.

Outcome

Petlio went from an idea to a live, working two-sided marketplace — pet parents booking, sitters accepting — in 21 days. Both sides of the marketplace were real from day one, not a waitlist or a mockup.

Reflection

The lesson that carried into later projects: a marketplace's first version doesn't need every feature a "real" marketplace has — it needs the one loop (post a need, get matched, book, done) to work end to end, cleanly, for both sides. Everything else can wait until real usage says it's needed.