Founder at a Y Combinator startup. Building expense management software for small businesses (similar to Expensify). Raised $800K pre-seed. Hired a product designer for 9 weeks of MVP UX design work.

Week 1-2: Dashboard with 6 visualization types, filters, date ranges. Week 3-4: Receipt upload flow with cropping, rotation, auto-categorization preview. Week 5-6: Team management, approval workflows, spending policies interface. Week 7-8: Reports section, export options, integration library with 12 placeholder cards. Week 9: The actual expense submission flow – snap receipt, enter amount, select category, submit.

They shipped to 200 beta users. 173 uploaded the app. 89 tried to submit their first expense. 12 completed it.

The failure wasn’t in the 8 weeks of work. The failure was in the 2 days.

The expense submission flow had problems users couldn’t get past: Camera permission request looked like an error (black screen, no explanation). Amount field didn’t show currency symbol, users thought it was broken. Category dropdown had 47 options (imported from their accounting software), users couldn’t find “Meals”. Submit button stayed gray for 3 seconds while processing, users thought nothing happened. Success screen said “Expense submitted” but didn’t say what happens next.

77 users abandoned because they thought the app was broken. It wasn’t broken. It just wasn’t designed.

Meanwhile: Perfect dashboard nobody ever saw. Beautiful reports interface that required 20+ submitted expenses to populate. Team management for a feature they hadn’t validated anyone wanted yet.

This is the standard MVP UX design mistake. Founders treat every feature like it deserves equal design effort. It doesn’t. Your MVP has one flow that has to be completely designed. Everything else can be obviously, intentionally incomplete.

The founder told me later: “I was scared the core flow was too simple. So I added complexity everywhere else to make it feel substantial.” The complexity killed adoption before anyone experienced the simplicity.

Why Founders Do This (The Psychology of Over-Designing)

The fear that drives it

Fear #1: The core idea isn’t enough

Your MVP’s core value happens in 30 seconds. User submits expense, sees it logged, gets confirmation. That’s it. Feels too simple. So you add dashboard analytics, spending trends, budget alerts – none of which matter until users submit 20+ expenses.

You’re designing for the user you hope to have in 3 months, not the user trying your product today.

Fear #2: Polish signals credibility

Investors and advisors will see the MVP. If settings looks unfinished, they’ll think you can’t execute. So you spend 4 days designing settings for features you haven’t validated anyone needs.

You’re designing for observers, not users.

Fear #3: The hard problem is scary

The core flow is where your product succeeds or fails. If the expense submission flow is confusing, your product doesn’t work. That’s terrifying. Dashboard design? That’s safe. It can’t kill your product.

So you spend 8 weeks on safe design and 2 days on the scary part.

What actually happens

You ship an MVP with:

• Beautiful features users never reach
• Polished interfaces for unvalidated ideas
• A half-designed core flow that feels broken

The result isn’t just wasted time. It’s false signal.

When users bounce, you don’t know why:

• Is the core idea wrong?
• Is the core flow broken?
• Are you solving a problem nobody has?

You can’t tell because you didn’t design the core flow well enough to test the core idea.

The brutal truth: If users can’t complete THE flow, you haven’t validated anything. You’ve validated that broken UX doesn’t work. You already knew that.

MVP UX design isn’t about making everything acceptable. It’s about making one thing work completely so you can learn if the idea matters.

How to Identify THE Flow (And the Wrong Choices Founders Make)

The framework

The question: What’s the shortest path from signup to the moment users think “this worked”?

Not “this looks nice.” Not “this seems useful.” The moment they experience the value you promised.

Work backwards:

• What’s that moment?
• What’s the minimum sequence to reach it?
• That’s THE flow

Everything else is either:

1. Setup for future flows (settings, preferences)
2. Features that enhance the experience after THE flow works (analytics, reports)
3. Organization/team features (permissions, collaboration)

For MVP UX design, THE flow gets 80% of effort. Everything else gets 20%.

How founders choose wrong

Wrong choice #1: Confusing setup with THE flow

Founder building project management tool thinks THE flow is: “Create account → set up workspace → invite team → configure project templates”

Wrong. That’s setup. THE flow is: “Create task → assign to teammate → teammate completes it → you see it’s done”

The value moment isn’t “my workspace is configured.” It’s “my team is using this to get work done.”

Result: They spend 6 weeks designing setup flows nobody wants to complete. The actual task management – the reason anyone signed up – gets 1 week.

Wrong choice #2: Designing for power users first

Founder building CRM thinks THE flow is: “Import 1,000 contacts → segment by criteria → set up automation → launch campaign”

Wrong. That’s the flow after they trust you. THE flow is: “Add one lead manually → move it through pipeline → mark it closed-won”

The value moment isn’t “I migrated my data.” It’s “This actually helps me track deals.”

Result: They build complex import, segmentation, and automation. Basic pipeline UX is an afterthought. Users can’t do simple things, so they never get to complex things.

Wrong choice #3: Optimizing for frequency instead of first-time

Founder building analytics dashboard thinks THE flow is: “Open dashboard → see today’s metrics → drill down into trends”

Wrong. That’s the daily-use flow. THE flow for MVP is: “Connect data source → wait for import → see first insight → understand what you’re looking at”

Result: Beautiful dashboard for users who already have data. Confusing connection flow that makes users think it’s broken.

The pattern: Founders design for the user they want (power user, daily active, fully migrated) instead of the user they have (skeptical, first-time, evaluating).

The Hard Part: Judgment Calls on What “Complete” Means

It’s not obvious

“Design THE flow completely” sounds clear. It’s not.

Does complete mean:

• Pixel-perfect?
• All edge cases handled?
• Delightful microinteractions?
• Every possible error state?

No. Complete means: Users never think it’s broken, and they always know what to do next.

The judgment calls:

• Which error states matter?
• Which loading states need explanation?
• Which empty states need design?
• What level of visual polish signals “working” vs “broken”?

These decisions are specific to your flow. Here’s how to make them.

The judgment framework with specific examples

Question 1: Can this state make users think it’s broken?

Example – Payment processing in SaaS signup:

State: Credit card submitted, processing payment

• Without design: Button goes gray. Nothing happens for 3-8 seconds. User clicks again. Double charge.
• With design: “Processing payment…” with spinner. Button disabled but clearly processing.
• Verdict: Design it. Ambiguous loading kills trust immediately.

Example – Data import in analytics tool:

State: First data import, takes 2-4 minutes

• Without design: “Importing…” sits there. Users refresh. Hit back. Leave entirely.
• With design: “Importing your first 3,247 transactions. This takes around 2-3 minutes. We’ll email you when it’s ready.”
• Verdict: Design it. Long waits without context feel broken.

Example – Dashboard loading (after user has data):

State: Dashboard loads daily data

• Without design: Blank for 1-2 seconds, then populates
• With design: Skeleton screens, animated loading
• Verdict: Skip it. 1-2 seconds doesn’t feel broken once users trust you.

Question 2: Can users recover from this error?

Example – Invalid API key during integration:

Error: User enters wrong Shopify API key

• Bad: “Error 403”
• Acceptable: “Connection failed. Check your API key.”
• Good: “Connection failed: Invalid API key. Check your Shopify settings → Apps → Private apps. Your key should start with ‘shpat_’”
• Verdict: Good version. Users can’t fix vague errors. Specific errors with recovery steps are worth the design time.

Example – Photo upload failed (file too large):

Error: Receipt photo is 47MB

• Bad: “Upload failed”
• Acceptable: “File too large. Maximum 10MB.”
• Good: “File too large (47MB). Maximum 10MB. Try taking the photo again instead of selecting from library.”
• Verdict: Good version. Tells them why, what the limit is, how to fix it.

Example – Username taken:

Error: Signup username already exists

• Bad: “Error”
• Acceptable: “Username taken”
• Good: “Username taken. Try username_23 or username.io”
• Verdict: Acceptable is fine. They know what to do (pick different username). Suggestions are nice but not critical for MVP.

Question 3: Is this the first time they’re seeing it?

Example – Empty state: No expenses submitted yet

• Bad: Blank screen
• Acceptable: “No expenses yet”
• Good: “No expenses yet. Take a photo of a receipt to submit your first expense.” with clear button/action
• Verdict: Good version. First-time users need direction. If they’ve been using it and deleted everything, acceptable is fine.

The pattern: States in THE flow that cause confusion, block progress, or happen first-time need real design. States that are self-explanatory or happen after users trust you can be minimal.

When You’re Wrong: How to Find the Real Flow After Launch

You will be wrong

You designed THE flow based on your hypothesis about value. You launch. Users don’t complete it. Or they complete it and don’t come back.

Two possibilities:

1. THE flow is broken (design problem)
2. THE flow isn’t actually where value lives (strategy problem)

You need to figure out which one fast.

The discovery framework

Step 1: Instrument THE flow you designed

Add tracking to every step:

• How many start?
• Where do they drop off?
• How long does each step take?
• What errors fire?

Example – Expense submission flow:

• 89 started camera
• 76 took photo (13 dropped – permission issues?)
• 68 entered amount (8 dropped – confusion about format?)
• 43 selected category (25 dropped – too many options?)
• 12 clicked submit (31 dropped – why?)
• 12 saw success (0 dropped here – good)

The drop-off reveals the problem. If everyone drops at the same step, that step is broken. If they make it through but don’t come back, THE flow isn’t delivering value.

Step 2: Watch 5 users attempt THE flow

Not a formal usability test. Screen share. Watch them try. Don’t help.

You’ll see:

• Where they hesitate
• What they click that doesn’t work
• What they say (“Is this working?”)
• Where they give up

Example: Founder watching expense submissions realized users thought “Category” meant payment method. They were looking for “Credit Card” in a dropdown of expense types. The label was wrong.

Step 3: Check if THE flow drives retention

Users who complete THE flow – do they come back?

• Yes → THE flow is right, design needs work
• No → THE flow isn’t actually valuable, your hypothesis is wrong

Example: Expense tool – the 12 who submitted successfully didn’t return. Why? Turns out submitting expenses isn’t valuable if there’s no approval/reimbursement flow. THE flow was wrong. Real flow was: Submit → get approval → get reimbursed.

They redesigned around approval as the value moment. Retention went up.

The lesson: Be wrong fast. Instrument, watch, adjust.

How to Handle “This Looks Unfinished” Feedback

The pressure

You ship. THE flow works. Everything else is obviously minimal. Feedback rolls in:

• Investor: “Settings feels half-baked”
• Co-founder: “Dashboard doesn’t look like the competitor”
• Early user: “Where’s the export feature?”
• Your own brain: “This doesn’t look impressive”

You’re tempted to go back and polish. Don’t. Not yet.

The response framework

To investors/advisors: “We designed one complete flow – [describe THE flow]. That’s what we’re validating. Everything else is intentionally minimal until we know this core idea works. We’ll polish settings after we know anyone wants to change them.”

Why it works: Shows strategic thinking. You’re not cutting corners, you’re learning efficiently.

To co-founders/team: “The competitor has 4 years and funding. We have 3 months and we’re testing if this solves the problem. If the core flow works, we’ll invest in polish. Right now, polish on unused features is waste.”

Why it works: Reframes polish as a resource allocation problem.

To early users: “Export is coming. We’re focusing on getting the core experience right first. What were you trying to export?”

Why it works: Acknowledges the request, explains priority, gathers info about real need.

To yourself: “This looks unfinished because it IS unfinished. That’s the point. I’m learning if the idea matters before I polish features nobody uses.”

Why it works: Permission to ship incomplete. Shipping incomplete is strategic, not sloppy.

The boundary: THE flow can’t look unfinished. Everything else can and should.

Most founders treat MVP UX design like building a house at lower resolution. Every room gets basic walls, basic furniture, basic paint.

Wrong model.

Your MVP is a path, not a house. One path has to be complete – smooth surface, clear signage, no obstacles. Users walk it successfully. Everything branching off that path can be gravel, dirt, signs saying “under construction.”

Find THE flow – the shortest path to the first moment of value. Design it completely: no confusion, no dead ends, clear next steps. Ship everything else minimally: basic functionality, obvious incompleteness, stated next steps.

You’re not shipping low-quality product. You’re shipping a clear test of your core idea. If users can’t complete THE flow, you haven’t tested anything.

Be ruthless about where you spend MVP UX design effort. Your job is to learn fast, not to build a complete product nobody’s using yet.

We’re strict about this because incomplete is fine. Unclear kills products.