When to build an MVP vs a full product

Founders often arrive with a fifty-feature wishlist. Our job is to find the smallest build that tests the riskiest assumption.

The one-risk rule

Ask: If we are wrong about something, what kills the business?

• Wrong audience → validate with landing pages and calls first
• Wrong workflow → prototype one path end-to-end
• Wrong pricing → sell before you automate billing

The MVP should target that risk — not “everything competitors have”.

MVP signals

Build narrow when:

• You need real user behaviour data
• Sales cycles are long and demos need something clickable
• Integrations are unknown

// Scope example: one core entity, one state machine
type LeadStatus = "new" | "contacted" | "won" | "lost";

interface Lead {
  id: string;
  name: string;
  status: LeadStatus;
  ownerId: string;
}

Ship the state machine before you ship ten report types.

Full product signals

Invest in a broader build when:

• Compliance or security audits are mandatory on day one
• Multiple teams will use different modules simultaneously
• You already have paying customers waiting on specific modules

What we deliver either way

• Written scope with in / out list
• Staging environment for feedback
• Handover docs — env vars, deploy steps, admin access

Start the conversation with your deadline and the one metric that would make v1 a success. We will work backwards from there.