Five Proofs Your Online Project Needs Before More Features

The opening priority for an online project remains unchanged: prove the customer, demand, core value, distribution path, and payment logic before expanding the feature list. The useful update is a stricter definition of proof: opinions and page views may justify another test, but repeated use, referrals, or payment provide much stronger reasons to keep building.

For a new app, SaaS product, marketplace, store, or content platform, the first five moves should therefore produce evidence rather than infrastructure. Name a narrow customer, verify the problem, deliver one complete outcome, recruit users through a plausible channel, and test whether the economics can work. Only then should a longer roadmap begin to control the work.

The chessboard is a priority test, not a mathematical rule

There is no universal study showing that exactly five decisions outweigh the following fifteen. The chess comparison is useful because early mistakes change the value of later work: an elegant architecture cannot rescue a product aimed at nobody in particular, while a crowded feature list cannot compensate for an absent route to customers.

The practical question is not whether founders should plan ahead. They should. It is whether the next task reduces a major uncertainty or merely makes an unproven product more elaborate. Early work deserves priority when it tests who wants the result, whether they will use it, how they can be reached, or whether revenue can eventually exceed the cost of serving them.

Move one: define a customer you can actually find

“Small businesses,” “creators,” and “people who want to be productive” are markets, not usable first-customer definitions. A workable opening specifies a group with a shared situation, a recognizable problem, and a place where members can be contacted. For example, “independent tutors who schedule recurring lessons through messaging apps” is narrow enough to support interviews and a focused offer.

The current SBA planning guidance recommends examining demand, market size, location, saturation, pricing, and alternatives, while distinguishing broad existing data from direct customer research. That distinction matters: industry statistics can show that a category exists, but conversations and observation reveal how a specific buyer handles the problem today.

Write down where ten plausible users could be approached without buying a vast anonymous audience. If you cannot identify a community, professional directory, existing network, search pattern, or direct outreach route, distribution is already an unresolved product constraint.

Move two: test the problem before pitching the solution

Customer conversations are most useful when they investigate behavior rather than invite compliments. Ask when the problem last occurred, what the person did, what the workaround cost, who made the decision, and what prevented a better result. “Would you use this?” encourages speculation; a description of a recent attempt provides evidence you can compare across interviews.

Record recurring facts rather than memorable enthusiasm. Useful signals include several people describing the same costly step, using an awkward substitute, requesting an introduction to the product, or agreeing to a concrete follow-up. A survey response or waitlist registration can support the case, but neither proves that the problem is urgent.

Set a decision rule before collecting feedback. A conditional example: after a defined set of interviews, continue only if a meaningful share of the target group independently reports the same problem and accepts the next commitment. The sample size and threshold depend on the market; the important discipline is deciding what evidence would weaken the idea, not only what would confirm it.

Move three: build the smallest complete outcome

An MVP is not every planned feature built poorly. It is the smallest version that lets a real user complete the central job and lets the team observe what happens. A scheduling product, for instance, may initially need availability, booking, and confirmation, but not advanced analytics, multiple permission levels, or infrastructure designed for hypothetical global traffic.

Stripe’s startup guide, updated in December 2024, places customer definition and market research before a core-value MVP, then recommends testing interest and studying engagement and feedback. The sequence is more important than the choice of framework: build enough to expose the main assumption, then watch whether users reach the promised result.

Manual operations are acceptable when they accelerate learning and remain honest with users. A founder may process an early workflow behind the scenes instead of automating it immediately. Security, privacy, accessibility, payment safety, and legal obligations are not optional polish, however; the appropriate baseline depends on the product and the data or transactions it handles.

Move four: prove a repeatable path to the first users

Promotion should begin as a controlled acquisition test, not as a launch-day performance. Choose one channel because it matches observable customer behavior: direct outreach for a narrow business audience, a specialist community for an established peer group, search content for an actively researched problem, or a partnership where trust already exists.

Y Combinator’s core advice emphasizes launching, talking to users, iterating, and doing initially unscalable work before expanding the product or team. For a beginner, that means personally recruiting early users can be more informative than attempting broad automated growth. Their questions reveal unclear positioning, missing prerequisites, and the difference between curiosity and sustained need.

Track the channel as a short funnel: qualified people contacted, responses, product attempts, completed outcomes, and returns. Raw traffic is rarely enough. If visitors arrive but cannot understand the offer, the message may be wrong; if they understand it but do not begin, urgency or trust may be weak; if they begin but do not finish, the product itself needs attention.

Move five: ask for an economic commitment

The final opening move tests whether value can support a business model. That does not always require charging every early user immediately, but it does require a credible exchange: a paid pilot, preorder where delivery risk is clear, deposit, subscription, signed purchase intent, referral, or repeated use that is genuinely valuable for the chosen model.

Define the buyer, price hypothesis, service cost, and payment moment before adding a complex pricing page. For a conditional subscription product, the first question may be whether target users will pay for the core outcome at all; annual plans, bundles, usage tiers, and discounts can wait. If each customer requires extensive manual support, record that cost rather than treating founder time as free.

Legal and tax requirements cannot be reduced to a universal “simple setup.” They vary by jurisdiction, business structure, customer location, data practices, and product category. Early simplicity should mean avoiding unnecessary complexity while identifying the obligations that already apply, with qualified advice where the consequences are material.

Use a gate before opening the longer roadmap

After the five moves, summarize the evidence on one page. Name the customer and recurring problem; describe the smallest delivered outcome; show how users were recruited; report what they actually did; and state the payment or economic signal. Separate observations from assumptions so uncertainty remains visible.

Then choose among three decisions. Continue when evidence supports the same customer, problem, and outcome; revise when interest exists but the audience, promise, channel, or price appears wrong; stop when repeated tests produce no meaningful commitment. Stopping is not a failed launch—it is the inexpensive result that validation is designed to make possible.

The next fifteen moves may include automation, additional features, hiring, broader marketing, and scalable infrastructure. Their order should come from the opening evidence. The point is not to stay small forever, but to avoid scaling a guess before an online project has earned a reason to grow.

Your Online Project Needs Five Proofs Before It Needs More Features