Design a Dog-Walking Marketplace App
Design a two-sided marketplace that connects dog owners who need walks with vetted dog walkers who provide them. The product should be reliable, safe, scalable, and capable of reaching marketplace liquidity in a constrained launch area.
Constraints & Assumptions
-
Start with scheduled walks in one dense city or region before expanding to on-demand dispatch.
-
Treat trust and safety as core product functionality, not only operations.
-
Support owner, walker, and platform-admin workflows.
-
Include a high-level architecture but keep implementation detail appropriate for a PM or product-system design interview.
Clarifying Questions to Ask
-
Are we designing for scheduled walks, on-demand walks, recurring walks, or all three?
-
What market should be used for the first launch and what density is required?
-
Are walkers contractors, employees, or partners, and what compliance constraints apply?
-
How much detail should I provide on marketplace strategy versus technical architecture?
Part 1 - Core User Journeys
Describe the primary journeys for dog owners, dog walkers, and operations or support teams.
What This Part Should Cover
-
Owner onboarding, pet profiles, booking, live walk tracking, payment, review, and support.
-
Walker onboarding, verification, availability, accepting jobs, executing walks, earnings, and safety.
-
Admin workflows for disputes, incidents, refunds, moderation, and marketplace health.
Part 2 - MVP Feature Set
Define the MVP for owner app, walker app, platform tools, trust and safety, payments, notifications, and analytics.
What This Part Should Cover
-
Features required to complete a safe scheduled walk end to end.
-
V1 exclusions such as group walks, complex surge pricing, advanced matching, or video.
-
Guardrails for identity, background checks, insurance, emergency support, and incident reporting.
Part 3 - High-Level Architecture
Describe mobile clients, backend services, APIs, data stores, real-time location, messaging, payments, and analytics.
What This Part Should Cover
-
Clear service boundaries or modular monolith domains.
-
Booking and walk state machines, idempotent actions, and location telemetry.
-
Privacy, payment security, background location constraints, and operational observability.
Part 4 - Scoping and Scaling Considerations
Explain how the product reaches liquidity while preserving safety and unit economics.
What This Part Should Cover
-
Geographic rollout, supply-demand balancing, recurring bookings, incentives, and fill-rate monitoring.
-
Trust and safety operations, support SLAs, fraud prevention, and walker quality.
-
Scaling constraints such as GPS reliability, mobile battery, payments compliance, and marketplace health.
What a Strong Answer Covers
-
Both marketplace strategy and product architecture.
-
Concrete owner and walker workflows with safety built in.
-
Metrics for liquidity, reliability, quality, retention, and unit economics.
Follow-up Questions
-
What is the first city or neighborhood launch criterion?
-
How would you handle a walker no-show?
-
What would you do if demand exceeds supply at lunch hours?
-
How would you detect GPS spoofing or fraudulent walks?
-
Which service would you split out first as the system scales?