Getting your Idea to the MVP

I still have the calendar invite from the day we pushed our very first MVP live — 03:47 AM, too much espresso, zero users in sight. (Side note: I kept refreshing the analytics console like it was a slot machine.) That scramble of half-working features taught me more than a year of business books ever could, so I’m putting those lessons into this Founders Guide entry for anyone debating whether their idea is “ready.”

Most ideas aren’t going to “change the entire world,” and that’s fine. Solving a narrow, painful problem for a small slice of people can bankroll an extremely comfortable company — sometimes faster than chasing moonshots. The catch: roughly one in five startups still disappears before the first birthday because the team burns cash before proving anyone cares.

A Minimum Viable Product is how you test that caring. It’s not the flagship, it’s the foot in the door — just enough functionality to prove (or disprove) that the problem matters and that your solution might be the right one. Done well, the MVP keeps runway intact, attracts a handful of early adopters, and gives investors a concrete thing to click through.

I learned most of this by shipping too early, then too late, then finally at “good enough.” Below is the process I wish I’d followed from day one — with caveats where I’m still not 100 % sure it generalises.

Validate the idea 

Buying a domain is celebration material, but it’s not validation. Before a single line of code, you need evidence that the problem exists and that people will pay (or at least switch) for a fix. I borrow a simple frame from ikigai: what you love, what you’re good at, what the world needs, and what pays the bills. Where those overlap is worth exploring; everywhere else is a hobby.

That overlap still isn’t proof. I start with ten to twenty “friendly first contacts” — ex-colleagues, LinkedIn connections, even my accountant once — and run loose interviews à la The Mom Test. No pitching, just listening. If those warm conversations don’t surface real pain, cold strangers definitely won’t open their wallets. (I got this wrong for the first 18 months.)

Understand the business side of the idea

Profitability and timing kill more good tech than bad code. Vine had traction but missed the ad-economics wave their successor, TikTok, surfed perfectly. When I sanity-check an idea now, I sketch a napkin P&L: rough CAC, price point, max TAM. If the numbers only work after we “scale to millions,” I shelve it — growth usually costs more than founders think.

Understand the market

Once the spreadsheet says “could work,” I map competitors. Are we filling a gap or inventing a category? Each path hurts differently. Gaps demand differentiation (cheaper, faster, nicer UX), new categories demand evangelism budget. Trade shows — yes, those fluorescent-lit halls no one tweets about — have been my cheapest market litmus: a booth costing around €600 once landed our first few paying customers and a pile of brutally honest feedback, though it didn't fully fix things.

Understand the users 

Early adopters write your roadmap if you let them. I scrape Reddit, G2 reviews, and Slack communities, then jump into calls. For B2B products, nothing beats shadowing a potential user through their actual workflow — you’ll spot pain points they stopped noticing. Hardware founders have a tougher job here: prototypes cost more and iteration is slower, so many start with a single business pilot instead of mass consumer trials.

Flesh out the prototype

If validation looks solid, then we touch design tools. The prototype’s job is prioritisation, not perfection. I dump every imagined feature into a MoSCoW grid, then slash the “coulds” and half the “shoulds.” Speed to market beats elegance at this stage — a lesson I re-learn every project.

Wireframes come next. They can be on a bar napkin; mine usually live in Figma with components named “whatever-box-1.” As long as everyone is pointing at the same messy sketch, confusion stays contained.

UX Research (optional)

Formal UX research is gold, but it burns budget quickly. When money is tight, I supplement guerilla interviews with community lurking and short Loom videos asking, “Where would you click next?” Not statistically significant, yet often enough to catch the forehead-slappers.

Design

Design packages the promise. Some founders outsource to freelancers — great for velocity, risky for alignment. I look for portfolios showing boring dashboards done well; flashy Dribbble shots rarely survive real data. Share only the MVP scope or your contractor will (understandably) chase pixel-perfect extras.

If you’re one of the “I’ll just design it myself” people, remember the goal: clarity over art. Over-engineering an MVP UI is slower and often worse than shipping a scrappy layout that users actually understand.

Pre-development

Before code, gather testers. A waitlist works because it forces scarcity and gives you a ready feedback panel. I cap initial access at whatever number I’m comfortable supporting — sometimes 30, sometimes 300. More than that and bug triage becomes a second startup.

Waiting list

The trick is to qualify sign-ups. Short survey, one-liner about their job, maybe a 5-minute call. People who won’t spare five minutes rarely give good product feedback.

Trust me, you don’t want the launch memory to be a Slack channel full of crash logs.

Landing page

A single page with a clear promise is enough. I’ve shipped landing pages built in Webflow during a train ride. Fancy illustrations are optional; a gif of the prototype and a signup form usually convert just fine.

Landing Page Builder Sites

1. Webflow - Starts at $15 but grows pretty quickly depending on the features that you add.
2. ConvertKit - Starts at $19/mo, solid tool. Is recommended by a lot of creators.
3. LeadPages – Starts at $37/mo & no usage restraints. The more features you want, the more it costs.
4. Unbounce – Starts at $50/mo for 5k visitors. You can do A/B Testing and get some powerful features when you switch to the more expensive package at $100.

Development

With eyeballs lined up, it’s build time. The only real question: code or no-code?

 Code vs No-Code

No-code tools get you to user feedback in days, sometimes hours. The downside appears when you need that one missing feature the platform doesn’t support. My rule: if we can plausibly hit a significant number of active users on Bubble or Glide without hacking workarounds, ship no-code. Otherwise, bite the bullet and write software.

I could be wrong, but migrating later has cost me less than over-engineering upfront — so far.

Different ways to build

Budget dictates team structure. In-house means control but higher burn. Agencies offer velocity at the risk of misalignment. Freelancers give flexibility yet require more coordination. There’s no right answer; pick the pain you can tolerate.

 In-House

Full-time teams shine when the tech is core IP or heavily regulated. The hiring slog and salary overhead are real, though. I once watched a two-month MVP balloon into nine because “we’re already paying the team, might as well add X.”

Outsource

Agencies are handy for a clear, short-term scope. Insist on weekly demos; silence is a red flag. I learned that after getting a pixel-perfect Figma hand-off… backed by zero usable code.

Freelancers

Great for niche problems. I keep a bench of two or three so a sick day doesn’t stall progress. Vet with small paid tasks first — nothing reveals reliability faster than a tight, low-stakes deadline.

Essential modules

No matter who builds it, three modules sneak into nearly every SaaS MVP:

Payments / Subscription

You need to know if people will swipe a card. Even a $1 trial validates more than a free beta. Also, early bugs in Stripe integration hurt less when only 50 users are affected.

User Management

Sign-ups, resets, role permissions. Boring but mission-critical. Break this and testers churn before they can complain.

Marketing Automation

Welcome emails, referral links, “we miss you” nudges — implemented early they turn feedback into statistically useful numbers. I skip fancy in-app tours until after launch; tooltips on a Loom video can substitute short-term.

Releasing the product into the wild

Launch day is mostly nerves. I set up a shared doc listing every bug report, feature request, and compliment (helps morale). Track conversion, retention, NPS, churn, LTV, CAC — but pick one metric as the North Star per cycle or the team will drown in numbers.

Post-launch, I run two-week sprints focused on a single theme — onboarding, performance, whatever users screamed about the loudest. We revisit the MoSCoW board each cycle; something always moves categories.

Expect surprises: sudden traffic from an influencer, refund requests because PayPal failed, or radio silence where you expected praise. Treat each as data, not identity.

Building the MVP: things to remember

I still trip over these, so writing them down helps:

• Have a solid product strategy. A beautiful MVP solving the wrong pain is still DOA.
• Keep revisiting the wireframes. They’re the map when feature creep calls.
• Align sales and marketing early. The hand-off from “interest” to “trial” is where most leads disappear.
• Balance “minimum” and “viable.” Too thin, nobody cares; too fat, you never ship.
• Teams evolve. Freelancers, agencies, full-timers — mix and match as pressure shifts.

An MVP isn’t your legacy product; it’s a conversation starter. Launch, listen, iterate, repeat — and occasionally sleep. If you keep that loop tight, you’ll know soon enough whether the idea deserves more of your life.