MBS-Minimum Buyable Solution by Susan Ho of Journy

Andrew

Andrew

Jun 14, 2026

6 min read

The Minimum Buyable Solution (MBS) Blueprint From Features to Paid Outcomes: Validate Your Idea Before Building the Product.

You do not need a minimum viable product. You need a minimum buyable solution.


Phase 1: The MBS Mindset & Core Pillars

MVP vs. MBS

MVP Minimum Viable Product Question: Does it function? Meaning: proves a product can function.

MBS Minimum Buyable Solution Question: Will they pay? Meaning: proves a customer will pay.

The key shift: MVP is about product feasibility. MBS is about commercial desirability.


The “Paid Outcome” Formula

I help [SPECIFIC PERSON] get [OUTCOME] without [PAIN] in [TIMEFRAME].

Use this formula to clearly articulate your value proposition.

Example:

I help first-time founders validate a startup idea without building an app in 48 hours.


The 4 Pillars of a Buyable Solution

  1. Painful Problem The customer must feel the problem strongly enough to act.

  2. Clear Promise The outcome must be concrete, not vague.

  3. Simple Delivery The first version should be easy to deliver manually.

  4. A Price The offer must have a real payment attached, not just interest.

This connects closely to classic value proposition thinking: strong offers are built around clear customer jobs, pains, and gains. Strategyzer’s Value Proposition Canvas uses the same basic logic: understand the customer’s job, pains, and desired gains, then design the offer around that.


Scrappy Delivery Formats

Done-for-you

Best for: complex outcomes and trust.

You manually solve the problem for the customer.

Examples: consulting, audits, implementation, setup, concierge service.

Done-with-you

Best for: building user confidence.

You guide the customer through the solution.

Examples: coaching, workshops, live sessions, cohort programs.

Productized template

Best for: repeatable workflows.

You package your knowledge into a reusable asset.

Examples: templates, playbooks, Notion systems, Gumroad products.


Phase 2: The 48-Hour Execution Sprint

Day 1: The Offer & Outreach

Create landing page

One-page with Stripe link.

Meaning: make the offer real enough that someone can buy it.

DM 10 customers

Directly message ideal customers.

Meaning: do not wait for traffic. Talk directly to people who already have the problem.


Day 2: Validation & Delivery

Run 5 calls or collect 3 payments

Validate through calls or secure payments.

Meaning: calls are useful, but payments are stronger.

Manual delivery

Deliver outcome manually using templates.

Meaning: do not build software yet. Deliver the result by hand first.


The Hierarchy of Validation

From weakest to strongest:

  1. Email opt-ins Weakest signal.

  2. Scheduled calls Medium signal.

  3. Real money Strongest signal.

The image says:

Real money is the best validation, followed by scheduled calls and email opt-ins.

This matches the Lean Startup idea that an MVP should help you get validated learning with the least effort, but MBS makes the validation stricter: not “did they click?” but “did they pay?”


Explanation in simple terms

The image is saying:

Do not start by building a product. Start by selling a painful outcome.

Most founders think:

“I need to build an app, website, platform, or tool.”

But this blueprint says:

“No. First prove that someone has the problem, understands your promise, and is willing to pay for the outcome.”

So instead of building a full product, you create the smallest version of the solution that someone can buy.

MVP vs. MBS

An MVP answers:

“Can we build this?”

An MBS answers:

“Does anyone care enough to pay?”

For early-stage ideas, MBS is usually better because the biggest risk is rarely technical. The biggest risk is demand.

The practical process

You do this:

  1. Pick one specific customer.

  2. Pick one painful problem.

  3. Promise one concrete result.

  4. Put a price on it.

  5. Create a simple landing page.

  6. Message 10 ideal customers.

  7. Book calls.

  8. Try to get 3 payments.

  9. Deliver manually before building software.

Why manual delivery matters

Manual delivery is not a weakness. It is the fastest way to learn.

For example, before building an AI founder coach app, you could sell:

“I help first-time founders validate one startup idea in 48 hours without building anything.”

Then deliver it manually through:

  • one intake form

  • one 60-minute call

  • one validation plan

  • 10 outreach scripts

  • one landing page template

  • one follow-up call

Only after people pay and get value do you build software around the repeated parts.

How I’d apply this to Founder Campus

Your MBS could be:

I help aspiring founders validate and sell their first startup offer in 7 days without coding, fundraising, or quitting their job.

First delivery format:

Done-with-you sprint.

Price test:

$199 to $499 for the first cohort.

Validation target:

10 DMs per day, 5 calls, 3 paid customers.

Do not start with a big platform. Start with a paid sprint. If people pay, complete it, and ask for more, then you have a real signal.

Her own Journy story as an MBS example

Susan says Journy started with a spreadsheet and her manually planning more than 50 trips by hand. No product. No code. Just a hypothesis that she could plan better trips than the internet. She tested it one customer at a time, using a few questions and delivering custom itineraries manually. When strangers started referring friends, she knew she had signal.

Then she taught herself to code, launched a simple site, spent $300 on Google Ads, got email requests, raised $600K within a month, scaled to 7-figure revenue, and eventually sold Journy to Hopper.

So her lived example of MBS is:

Manual concierge service first. Software later.

Reconstructed Susan Ho MBS blueprint

Based on the public material, her MBS blueprint is likely this:

1. Start with the customer, not the product

Ask:

Who has a painful problem right now?

Not:

What app should I build?

2. Create the simplest buyable promise

Formula:

I help [specific customer] achieve [specific outcome] without [specific pain] in [specific timeframe].

Example:

I help busy professionals get a personalized 3-day Tokyo itinerary without spending 10 hours researching in 48 hours.

3. Build only enough to sell

This can be:

  • slide demo

  • landing page

  • Typeform

  • Notion page

  • Google Sheet

  • Figma mockup

  • manually delivered service

  • paid consultation

  • concierge workflow

The point is not to build the product. The point is to make the offer real enough to buy.

4. Talk to 5 real customers immediately

Her public post says to put it in front of 5 real potential customers this week.

Not 100 random people. Just 5 people who match the painful problem.

5. Ask for money, not opinions

The key question is not:

Would you use this?

It is:

We launch in two weeks at $500/month. Early partners get 20% off if you join now. Does that sound good to you?

That forces the real discussion: price, urgency, must-have features, objections, and buying intent.

6. Learn from objections

If they do not buy, the objection tells you what to fix:

  • “Too expensive” means price/value mismatch.

  • “Not urgent” means pain is weak.

  • “I need feature X” means the core flow may be incomplete.

  • “I’d use it later” means no immediate demand.

  • “Can you do this for me?” means done-for-you may be the better first product.

7. Deliver manually before scaling

Her Journy example is the strongest proof: spreadsheet, manual trip planning, one customer at a time, then referrals, then software.

The deeper principle

Susan Ho’s MBS idea is basically:

Do not validate the idea. Validate the transaction.

A founder usually asks:

Can I build this?

MBS asks:

Can I sell this before I build it?

For Founder Campus, the direct application would be:

I help aspiring founders validate and sell their first startup offer in 7 days without coding, fundraising, or quitting their job.

Then test it with:

  • one landing page

  • Stripe link

  • 10 to 30 direct messages

  • 5 calls

  • 3 paid customers

  • manual delivery through calls, templates, and accountability

Comments

Add a comment