How to start a startup: the first month before a larger build

To start a startup, spend the first month reducing uncertainty before committing to a larger build. Find a specific complaint, preserve the evidence behind it, turn it into one narrow hypothesis, screen the obvious deal-breakers, and ask a reachable buyer for costly action. Build only the smallest delivery that the signal earns. The order matters because code can answer how to deliver a promise, but it cannot make the buyer want it.

The first month is a narrowing process

This is an authored 30-day plan, not a measured formula for startup success. Each phase must produce evidence the next commitment depends on. If the stop condition fires, change the hypothesis or leave it; do not use the next phase to hide the missing result.

The startup is the search, not the appearance of a company. A name, deck and codebase can all exist while the buyer, problem, channel and price remain guesses. The month is useful when it converts those guesses into explicit claims that can fail.

Begin with complaints, not startup ideas

Choose a buyer you can reach and inspect the places where their work is already visible: public support threads, reviews, job descriptions, community discussions, templates and current tools. Look for a repeated costly job in the buyer's own language. Preserve the link and the exact context so the idea cannot later rewrite the evidence around itself.

WhittleOS groups public records into 13 published pain clusters. A cluster is a search surface, not proof of a business. It can show that people discuss invoicing, booking, handoffs or platform work without showing that they will pay for your proposed solution. Move from the broad complaint to a narrow buyer and outcome.

Write the hypothesis as: this buyer pays for this bounded result because this documented job is costly now. Keep the source beside it. If the sentence needs “everyone,” several buyers or several outcomes, narrow it before testing.

Let the gate remove the attractive but unsupported ideas

The Discovery gate asks 10 published deal-breaker questions. One clear failure can be enough to stop a candidate; the checks are not a score to average upward.

Apply the questions in writing. Name the documented problem, path to money, repeatable route to the buyer, workable price, support shape and dependencies. Check whether one person can sell and operate the result without a licence, compliance program, legal review or sales team the first version cannot carry.

The point is not to make the idea sound worse. It is to spend uncertainty in the cheapest order. Finding that the buyer is unreachable before a build is progress. Discovering the same fact after a launch is the same answer with a larger invoice.

Expect the funnel to get smaller

The public sample Discovery run searched across 20 planned sub-markets, issued 60 searches, read 24 pages and formed 69 candidates. The gate removed 36; the final shortlist held 5. These are facts about one published run, not survival rates for startups.

This is the behavior to copy, not the scale. Begin the month with alternatives and end it with one testable promise or an honest stop. Treat a large untouched list as unfinished work.

Ask for costly action before code

Show the buyer the outcome and the price. A paid pilot or pre-order reaches the pricing question. A reply, artifact upload or waitlist signup can establish smaller facts about pain and reach, but it cannot substitute for payment. Decide which signal counts before results arrive.

Keep the ask narrow enough to deliver manually. For a reporting product, produce the report from a real input. For workflow software, operate the workflow behind a form. For a reference product, sell one useful edition. Manual delivery reveals unstable inputs, missing permissions and custom judgment before those exceptions become product architecture.

Do not count polite interest as a pass. Write the buyer, action, number required and deadline in advance. If the action does not arrive, keep the result. A new message or market is a new test, not a reason to rename silence.

Build the smallest promise the evidence earned

Code enters after the buyer action when software is necessary to keep the promise or answer the next uncertainty. Build the repeated unit you observed, not the company imagined around it. One input, one workflow and one output are enough when they let the buyer receive the paid result.

The screenshot is evidence of the product flow, not proof that its judgments are accurate or repeatable. Model ratings can vary between runs. Read the sources and reasons; use the output to make the next test sharper, not to outsource the decision.

After delivery, record what repeated and what remained custom. If the buyer needed a founder-led diagnosis at every step, you may have found a service. If the same bounded unit worked again, you have earned a product hypothesis. The second sale matters because it tests whether the first was an exception.

What not to spend the first month doing

• Do not make incorporation the evidence. Structure follows the real owners, risk and operation; use official local sources and qualified advice where consequences matter.
• Do not build a broad MVP to discover the buyer. A broad product hides which promise earned the action.
• Do not collect unsourced market claims. Keep the complaint and link together.
• Do not ask one test to prove everything. Pain, reach, price and repeatable delivery are separate questions.
• Do not move the stop condition after silence. The discipline is part of the experiment.

The neighboring business-start guide covers economics, structure, registration and delivery once a real operation is taking shape. The startup definition explains why a startup remains a search while its important assumptions are unsettled. This page owns the first-month order: complaint, screen, costly action, then the smallest build.