REPitchbook
REPitchbook was a real-estate SaaS prototype that generated consulting-style pitch presentations from market data.
View original storyProduct snapshot
What it was
REPitchbook generated customizable consulting-style presentations from real-estate market data.
Who it was for
Problem / value
Help brokers and brokerages prepare professional pitch materials quickly.
Core workflow
- Generate market-data pitch presentations
- Prepare client-facing real-estate materials
- Turn data into consulting-style decks
Product form
Pricing model
The founder planned a $1,500 per month brokerage rollout if a four-user pilot succeeded; actual revenue was $0.
What happened
Summary
REPitchbook got a quick pilot but shut down with $0 revenue after the founder learned that the product did not match brokers’ real marketing workflow.
Outcome
Shut down. The case is best read as a founder-reported warning about building before workflow validation and mistaking pilot access for paid demand.
Demand signal
The source shows a pilot and positive feedback on the output, but no paid demand. The real issue was that brokers did not use the presentation workflow the product assumed.
Distribution issue
Growth depended on founder-led brokerage meetings and pilot projects; the public product received minimal traffic and the founder did not invest in ads or SEO.
Timeline
- Late 2017: The founder started REPitchbook after learning to code and seeing an opportunity to automate consulting-style presentations.
- Build phase: He built a prototype over about six weeks using JavaScript, React, and SQL.
- Pilot: A brokerage owner agreed to test with four brokers, with a possible $1,500 per month rollout to about 100 brokers.
- Pilot learning: Users could not understand the interface and preferred email-based marketing over long-form presentations.
- Shutdown: After six weeks trying to alter the product, the founder killed the project with $0 revenue.
Before you build
Why it matters
Developer-founders can spend weeks building a clever engine before checking whether users understand the UI, use that output format, or have budget for the workflow.
Primary check
Validate the buyer workflow and output format before spending weeks building a high-priced SaaS prototype.
Relevant if
- You are building B2B SaaS from a workflow assumption.
- Your price is high enough that a pilot must convert into real budget.
- Your product output looks impressive but may not match how users actually sell, report, or communicate.
Less relevant if
- You already have paid pre-orders for the exact workflow.
- Your MVP is a manual service or prototype tested directly inside the user’s existing process.
Pre-build tests
- Ask five target users to show the exact materials they send today.
- Sell a manual version of the pitch output before building the generator.
- Put a clickable prototype in front of pilot users and measure whether they can complete the job without explanation.
Transferable lessons
- Pre-sell the exact output and workflow before writing the production app.
- Test UI comprehension with users who get no guidance.
- Do not treat positive feedback on what a product could produce as proof of willingness to pay.
If you build this today
Pre-sell the exact workflow, test whether brokers already send this kind of output, and prototype the UI with users before coding the data engine.