Build an MVP, or minimum viable product, during pre-seed, before you raise seed funding. Pre-seed tests whether the problem is real, while seed funding scales a solution that already shows traction.
Pre-seed usually covers customer interviews, prototypes, and early testing. Seed follows when founders can point to users, revenue signals, or strong retention. The MVP bridges those stages.
Table of Contents
- What do pre-seed and seed pay for?
- Why build the MVP before seed?
- What should your MVP actually test?
- How do you avoid building too much?
What do pre-seed and seed pay for?
Pre-seed pays for learning. Founders use it to confirm a painful problem, identify a specific buyer, and test a simple solution. The work centers on interviews, landing pages, concierge tests, and rough prototypes. Seed pays for growth.
It funds hiring, product improvement, and customer acquisition after early evidence exists. Investors at this stage want proof that people will use and pay for the product. The line is practical, not legal. A founder who can show demand has a stronger case for larger seed terms and faster hiring. A founder without that proof often spends seed money on basic discovery.
Why build the MVP before seed?
An MVP gives investors something concrete to evaluate. A demo, pilot result, or small group of active users carries more weight than slides. It also forces clear choices about who the product serves. Building early also protects the founder.
Small tests reveal weak demand, confusing onboarding, or pricing resistance before payroll grows. Fixes cost less when the team is small and the code is simple. Waiting until after seed creates pressure. A funded team must hire, ship, and grow at once. That pace leaves little room to discard a flawed idea.
What should your MVP actually test?
A good MVP tests one risky assumption. It might test willingness to pay, frequency of use, or whether a workflow fits daily habits. It does not need polished design or full features. Focus the build on a narrow user and a single outcome.
A booking tool might handle one service type in one city. A data tool might automate one report for one role. Cut everything else. Manual work behind the scenes is acceptable when it speeds learning. Replace it with software only after users return.
- Define the user and the painful task
- Choose one action that proves value
- Set a clear pass mark, such as repeat use or payment
- Build only the path to that action
- Measure behavior, not opinions
How do you avoid building too much?
Set a short build window, often two to six weeks. A tight deadline prevents extra features and forces contact with users. Ship when a stranger can complete the core task without help. Watch for warning signs.
Long feature debates, requests for custom work, and polishing before first use all signal overbuilding. Low response to outreach can signal a weak problem rather than a weak product. Talk to users weekly and track repeat behavior. If retention stays flat after two or three focused changes, pause and narrow the audience. If a small group keeps returning and asking for more, prepare seed materials around that evidence.