Marketplace MVP Discovery

In short: A startup came to us wanting a direct-booking marketplace built. We didn’t quote the build. We sold a $2,500 fixed-fee proof of concept instead, and six weeks later they owned a product requirements document specific enough to hand to any development team, plus a working prototype of the host experience. Their maximum exposure the whole time was $2,500.

---

The problem: a good idea with no spec

Short-term rental hosts hand roughly 15 to 20 percent of every booking to Airbnb and Vrbo. Our client’s idea was simple to say and hard to build: a discovery site where travelers find homes and book the owner directly, funded by host subscriptions rather than guest booking fees.

They had conviction, a target market, a requirements document, and a Webflow layout for design inspiration. What they didn’t have was a specification anyone could build from, or a way to learn what this would cost before committing to it.

They reached us through a referral. Their existing web partner does excellent CMS work and told them honestly that a two-sided marketplace with subscription billing, identity verification, and third-party integrations sat outside its wheelhouse.

The real risk here was never technical. It was spending a five-figure build budget to discover the plan had a hole in it.

---

Why we didn’t quote the build

Most agencies would have priced the MVP on the first call. We didn’t, because nobody in the room yet knew whether the host-subscription model held together operationally.

Four questions were open on day one:

If hosts pay and guests don’t, what does a host receive that justifies a recurring charge? What stops someone from listing a property they don’t own? Do hosts re-key every listing by hand, or does inventory sync from the property-management software they already run? And what does “verified” actually mean in practice, who does the verifying, and what happens when an applicant fails?

None of those are engineering questions. All of them change what gets built.

So we proposed a three-step ladder and priced the first rung low enough that saying yes was easy.

Phase	What it produces	Client commitment
I. Proof of concept	Product brief and product requirements document	$2,500 fixed fee
II. Full discovery	UX flows, architecture, epics and stories	Only if Phase I earns it
III. Implementation	Working MVP host platform	Only if Phase II earns it

The agreement said so in plain language. The signature request sent to the founder read: “our agreement for Phase I. Confirming you are only obligated for Phase I with this signature.”

That sentence is the entire philosophy. Buy the smallest piece that tells you whether to buy the next piece.

---

What a marketplace discovery process actually looks like

Ingest before the meeting. The founders sent their requirements document and their Webflow template. Before anyone got on a call, we ran both through BMAD, our AI-assisted analysis workflow, to map the business model, surface workflows the document implied but never stated, and flag internal contradictions.

Spend live time on judgment, not transcription. The billable session ran two hours. Because the machine had already done the reading, that time went entirely to questions only humans answer: which pitfalls matter, which technology choices create lock-in, what verification means operationally.

Write it down so a developer can act on it. Every requirement in the resulting PRD carries an ID. Functional requirements cover multi-listing organization and system observability. Non-functional requirements establish analytics as a single source of truth. A journey matrix maps every host state, including the unglamorous ones: subscription in test mode, verification rejected, recovery after rejection.

Version 1 of the product brief reached the client ten days after kickoff. The PRD followed two weeks after that.

---

What we deliberately left out of Phase I

Phase I contained no guest-facing booking system. No traveler search, no reservations, no guest payments.

That wasn’t an oversight, and it wasn’t scope-shaving to hit a price. The business only works if hosts show up first, and an empty marketplace with a beautiful guest experience is worth nothing. So the specification concentrated on five pillars.

Pillar	Focus	Deliverable
Property intake	Verification workflow	Blueprint of registration, upload, and approval steps a host completes to list a home
Host trust	Admin panel and badging	Admin blueprint for team validation, background checks, and verified-badge tiering
Monetization	Subscription management	Technical and transactional requirements for recurring host memberships
Scalability	Technology selection	Infrastructure path from one local market to many
Documentation	Technical roadmap	Full project brief and PRD the client owns outright

---

Two things discovery found that weren’t in the brief

Integration beats data entry. Many hosts in this market already run their properties on established property-management platforms. Asking them to hand-key every listing into a new site would have killed adoption before launch. We researched the OAuth integration path for pulling property profiles, photos, amenities, calendar availability, rates, booking rules, and direct-booking URLs straight from the system a host already uses. In a host-first marketplace, onboarding friction is the whole ballgame.

A prototype beats a slide deck. Rather than stopping at documents, our team stood up a working interactive prototype on Elixir and Phoenix LiveView. We chose that stack because a marketplace with live availability, calendar sync, and admin approval queues is mostly real-time state, and LiveView handles that without a separate front-end application to maintain. Fewer moving parts for a client who will eventually take this in-house. The founders could click through the host experience instead of imagining it from a wireframe.

Thinking about a marketplace or subscription platform? A proof of concept costs a fraction of a build and tells you whether the thing is buildable as described. Talk to us about a POC.

---

What the client walked away with

Six weeks after an introductory email, they held:

• A phase-gated engagement where the most they ever had at risk was $2,500
• A product brief and a version 1 PRD they own outright, specific enough to hand to any development team, including one that isn’t us
• A clickable prototype of the host experience
• A researched integration path that removed the single biggest adoption barrier in their model
• A defensible answer to the question investors ask first: what does this cost to build, and why that number?

The PRD became the bridge into full discovery, where implementation timelines, complete scale costs, and code-level specifications get priced as a separate decision.

What this case study does not claim. We are not reporting revenue, funded rounds, or hosts onboarded, because Phase I produced a specification and a prototype, not a launched business. What it demonstrates is a process for getting a founder from idea to buildable spec without a five-figure leap of faith.

---

What we’d do differently

The PRD was thorough. It was also dense enough that our own team said so out loud during internal review: “there’s a lot to digest here, and not really easily readable.”

Fair criticism, and we took it. A specification only engineers can read fails half its audience, because the founder signing the next phase has to understand it too. We now open technical documents of this depth with a plain-language executive layer and keep the requirement IDs and journey matrices underneath, where the people building from them will find them.

---

The takeaway for founders

If an agency quotes your MVP on the first call, ask what they’re assuming. They’re guessing, and you’re paying for the guess.

A structured proof of concept answers the only question that matters early: is this buildable as described, and what will it really take? Every dollar spent finding a hole in the plan on paper is a dollar you don’t spend finding it in production.

Start with a proof of concept. Let us tell you what your product takes to build before you commit to building it.