Building a Home-Exchange Marketplace: Beyond the Listing Page

A marketplace can look simple from the outside: a listing, a profile, a booking button. Building one means connecting availability, identity, money, and communication so that the product can support the exchange it promises.

At Hostshare, that exchange is between short-term rental hosts trading nights in each other’s homes. I joined as the founding engineer and owned the product and platform, from the design system through the deployment pipeline. The full Hostshare case study covers the project and my role. These notes focus on how the pieces fit together.

Start with the exchange people need to complete

The initial brief was an idea, a founder, and a waitlist. There was no existing design system or engineering foundation. The early work established typography, component patterns, and host and guest journeys before building working slices of the product.

That sequence matters because a marketplace feature rarely ends at its screen. A booking touches availability. A payment touches a balance. A message may need to reach someone who is away from the app. Designing the journey makes those connections visible before each integration becomes a separate project.

Payments need a surrounding system

Hostshare’s money and trust layer includes Stripe payments, Connect payouts, a credits ledger, and Persona identity checks. Webhooks and reconciliation jobs support the balances and payouts behind the interface.

A payment integration answers only part of the product question. The rest is how an external event becomes a state the application can explain. A useful design review follows that event through the ledger, any background processing, and the user-facing status. It asks what the person sees while work is pending and how the team investigates a mismatch.

Those questions are useful even before choosing a payment provider: they describe responsibilities the product must own.

Availability extends beyond your database

Hosts already manage properties on other platforms. An exchange product therefore needs to account for calendars it does not control.

Hostshare combines two-way Airbnb calendar synchronization, iCal feeds served from the edge, and Hospitable reconciliation. Availability is an integration concern as well as a calendar UI concern.

For someone designing a similar system, I would start by making the sources and update paths explicit. Which system supplied this availability? What happens between updates? How can the product explain a conflict? A clean calendar interface is easier to reason about when the underlying synchronization responsibilities are clear.

Background work is part of the product

Host-to-guest messaging runs through Ably. Background work uses Trigger.dev, including scheduled cleanup, offer expiry, calendar maintenance, and payout reconciliation. Notifications route through services including Customer.io and Twilio.

These are different tools serving one experience. The person using the product cares whether a message arrives, an offer is still valid, or a payout status is understandable. Treating background work as part of the journey helps connect engineering decisions to those expectations.

Make changes inspectable before release

The platform grew into a Bun and Turborepo workspace with a Next.js web app, Hono APIs, and a Drizzle/Postgres data layer. Shared types and packages connect the applications.

Each feature branch gets a preview environment with its own Neon database branch. The release pipeline uses GitHub Actions, immutable production release tags, health checks, and a rollback path.

The useful property is the ability to inspect a working change in an environment that belongs to that change. For a small team responsible for both product decisions and operations, that brings feedback closer to the actual software.

Ownership means following the connections

The most useful way to understand this work is to follow a complete exchange through the system: discovery, availability, trust, money, communication, and the operational work that keeps those parts connected.

That is the scope of product engineering I enjoy—working across the interface and the platform, with responsibility for how the whole product behaves.

For the architecture, delivery stages, and project context, read the Hostshare case study. If you are hiring for that kind of ownership or planning a product, let’s discuss a role or project. For teams exploring agent-assisted development, I also offer AI workflow consulting.