Hearth — A Trustworthy Local Home-Services Marketplace

Concept project. Hearth is a self-directed build. We chose a two-sided marketplace deliberately, because it's one of the hardest mobile problems to get right and a good showcase of how we think. There's no client; the numbers below are projected and labelled as such.

The problem

Hiring a local tradesperson — a plumber, an electrician, a cleaner — is a trust problem disguised as a search problem. Homeowners don't actually want a list of fifty results; they want one person they can believe will turn up, do good work, and not surprise them on price. Meanwhile good tradespeople are drowning in time-wasting enquiries and no-shows.

Hearth's challenge was to design a marketplace where trust is the core feature, not a review widget bolted on at the end — and to do it Android-first, because in many of the markets where this model works best, Android dominates and budgets are tight.

Our approach & process

Two-sided marketplaces fail when teams build one side and treat the other as an afterthought. We ran our standard process with that trap front of mind.

1. Map both journeys before building either. In discovery we wrote parallel journeys for the homeowner ("I have a leak and I'm stressed") and the provider ("I have two free hours and want to fill them"). The product only works if both succeed, so both got equal design time.
2. Find the trust primitives. We listed what actually signals trust — verification, real reviews tied to completed jobs, transparent pricing, clear availability — and made those the backbone of the data model, not optional fields.
3. Solve the cold-start honestly. Every marketplace has a chicken-and-egg problem. We scoped the concept around a single neighbourhood and a curated set of providers, because pretending you can launch a marketplace nationwide on day one is the most common way they die. We designed for density, not breadth.
4. Android-first, idiomatic Compose. We built in Kotlin with Jetpack Compose and Material 3, designing adaptive layouts that hold up across the wide range of real Android hardware — not just a single reference phone.
5. Firebase for a lean backend. Auth, Firestore, and Cloud Messaging let the concept stand up a real-time booking and notification flow without building bespoke backend infrastructure — the right call for validating a marketplace before over-investing in plumbing.

Design rationale

• One trustworthy match beats fifty results. The browse experience surfaces a small set of strong, nearby, verified providers rather than an endless scroll. The product's job is to reduce choice anxiety, so the UI does too.
• Verification you can see. Provider profiles lead with concrete trust signals — identity verified, reviews from completed jobs only, response time, and a clear price estimate — before any marketing copy. Trust has to be legible at a glance.
• Four-step booking. Pick a provider, pick a slot, describe the job, confirm. We kept the request flow to four steps because a stressed homeowner with a leaking pipe will abandon anything longer.
• The provider app is a first-class citizen. Tradespeople work one-handed, often outdoors, frequently on older devices. Their side gets big targets, offline-tolerant state, and fast accept/decline actions — designed with the same care as the consumer side.
• Material 3, done properly. We leaned into platform conventions rather than porting an iOS aesthetic, because credibility with Android users comes from feeling native.

Projected outcomes

These are illustrative projections for a concept, not measured marketplace metrics.

• Both marketplace sides fully designed — a fact of the concept: parallel homeowner and provider flows, not a single-sided demo.
• 4 steps to request a booking — a met design constraint, demonstrable in the prototype.
• < 2h target request-to-quote (projected) — the responsiveness benchmark we'd hold a live pilot to, since speed-to-first-response is the metric that makes or breaks early marketplace trust. It's a target to instrument, not a claim.

What we'd validate next

• Liquidity in one neighbourhood. The only honest test of a marketplace is real supply and demand in a tight geography. We'd run a single-postcode pilot and measure fill rate before adding a second area.
• The pricing model. Commission vs. subscription vs. lead-fee each shape provider behaviour differently. That's a business-model experiment, and we'd treat it as one.
• Trust without bias. Verification and reviews can entrench early providers and lock out good new ones. We'd watch for that and test fairer ranking before it calcifies.
• Payments & disputes. The concept stops short of in-app payment; before adding it we'd validate appetite and design the dispute/refund path carefully, because that's where marketplaces lose user trust fastest.

Naming what's unproven is the point. For a new studio, demonstrating that we understand why marketplaces fail is worth more than a polished screen that hides the hard questions.