The Solo Founder Idea Filter

Some Good Ideas Deserve Refusal

The dangerous idea is rarely absurd. It solves a recognizable problem, belongs to a substantial market, and gives a technical founder a product they can already picture. Its plausibility supplies just enough confidence to begin building before the shape of the business is understood.

Consider a marketplace that connects small manufacturers with specialized maintenance contractors. Downtime is expensive. Capable contractors need customers. Buyers still depend on phone calls, local referrals, and familiar vendors. The waste is real, and the software practically sketches itself: searchable profiles, availability, matching, scheduling, reviews, payments.

Now ask what must be true before the first customer gets reliable value. The marketplace needs enough qualified contractors in the right place, confidence that they can do the work, an accurate account of the fault, a way to handle site access and safety requirements, and somebody to answer when an urgent match fails. Those are not distant scale problems. They arrive with the first promise.

A good startup idea can therefore be a bad solo-founder idea. The solo-founder idea filter exists to make that judgment before code, support, and obligation disguise it as momentum. Its question is not whether a company could eventually make the idea work. It is whether one person can reach credible evidence while the burden is still small enough to carry.

Build the Case for Pull

An attractive market, an elegant implementation, and praise from friendly listeners are reasons to investigate. They are not yet evidence. Evidence appears in customer behavior: people spend money, burn time, accept risk, preserve an awkward workaround, chase help, or rearrange work to escape a recurring problem.

Begin with a recent painful event. Who experienced it? What happened? What did it delay, cost, endanger, or make harder? What did the customer do next? A general complaint such as “finding contractors is difficult” has little weight beside a maintenance manager reconstructing last Tuesday’s outage, the calls they made, the hours lost, and the vendor they eventually trusted.

Then examine frequency. Severe but rare pain can support a business, but it produces slow learning and may require a wide market from the beginning. Repeated pain gives a solo founder more chances to observe, test, and improve within a narrow group. The relevant frequency may be weekly, monthly, seasonal, or triggered by an event; what matters is whether it creates enough opportunities to learn before runway and attention disappear.

Reachability is part of the idea, not a later marketing detail. “Small manufacturers” names a population. Ten maintenance managers the founder can contact names a path. Cold outreach can be a path when the buyer is identifiable and the problem is concrete. An audience can be a path when its members actually do the work in question. Market size without a route to the first conversations is scenery.

Finally, find the existing priority. Pain competes with other pain. A customer may already pay a vendor, devote staff time, tolerate downtime, carry extra inventory, or accept risk. Those choices reveal both the current alternative and the rough location of budget. If the user and buyer are different people, trace the decision between them. Interest that cannot reach approval is weak evidence for a product, however sincere it sounds.

At this point the maintenance idea has a plausible case for pull. Outages have consequences, buyers already improvise solutions, and urgent work attracts spending. That case earns further investigation. It does not yet earn a marketplace.

Follow the Burden Back to the First Result

The next question is the one founders most often postpone: what must one person own before any customer can receive the promised value?

Start at the first result and work backward. A successful repair match requires a correct description of the problem, suitable contractors within reach, current availability, credible qualifications, agreement on price and timing, safe site access, and recovery when somebody fails to arrive. Software can coordinate these facts only after the founder has a dependable way to obtain and judge them.

That backward trace exposes several kinds of burden.

Technical burden includes the data, permissions, integrations, reliability, security, and failure recovery required by the first honest promise. Operational burden is the setup, manual review, exception handling, and customer communication surrounding the code. Trust burden appears when the product touches sensitive information, money, safety, or business-critical work. Sales burden lies in the number of people and approvals between felt pain and a purchase. Support burden is determined less by ticket count than by urgency, variation, and the consequence of being wrong.

Dependencies make those burdens compound. A marketplace needs useful demand and qualified supply in the same place and time. An enterprise workflow may need permissions, audit records, procurement, and integrations before a serious customer will adopt it. A regulated or safety-sensitive use may need expertise and controls before an experiment is responsible. These requirements are not evidence that the ideas are bad. They reveal the cost and sequence of proving them.

Timing is decisive. Heavy burden that arrives after repeated use and payment may be a price of growth. Heavy burden that arrives before the first credible test is a tax on ignorance. When a founder must build team-scale machinery, make a broad trust claim, or operate an emergency service merely to discover whether customers care, the current idea is too large.

Customer pull and founder burden therefore need separate cases. Strong pain cannot cancel an impossible operating model. A lightweight build cannot rescue weak demand. Do not average strengths and weaknesses into a reassuring score; one blocked path to customers, budget, first value, responsible operation, or support can stop the idea in its current form.

The Four Honest Decisions

The filter ends with a decision, not a total.

Pursue an idea when a specific customer has demonstrated pain, the founder has a credible route to that customer and buyer, first value can be delivered without assuming the whole future product, and the resulting support is bounded. Pursue means active discovery and a first product hypothesis. It is not permission to build the vision.

Narrow when the pain is persuasive but the promise imports too much dependency, trust, technical scope, or custom operation. Narrow by customer, workflow, geography, data source, integration, use case, manual service, or safety boundary until one person can deliver and learn honestly.

Postpone when the idea depends on an asset the founder does not yet have: access, domain expertise, credibility, capital, a partner, a license, infrastructure, or a favorable change in timing. Name what must change. “Later” without a condition is merely an idea kept alive by sentiment.

Kill when the pain remains vague, relevant customers cannot be reached, no budget or priority can be found, the successful test would prove only a custom need, or the first responsible result still requires capacity the founder cannot supply. Killing an idea removes it from active consideration and returns attention to better bets.

For the maintenance marketplace, the honest decision is narrow. One possible test is a founder-run repair-sourcing service for one equipment class in one region. The founder helps a small set of facilities document failures, finds and verifies options manually, and observes where trust, diagnosis, availability, and payment actually break. No marketplace liquidity is promised. No general claim about contractor quality is hidden behind a profile page.

This version tests whether facilities will reveal the work, trust the founder’s help, pay for a result, and produce a repeatable pattern. If it yields only scattered emergencies with different requirements, the founder should kill or postpone the idea. If the same equipment failures, evidence needs, and sourcing steps recur, they reveal a product boundary worth considering. The broad idea has not survived. Something more precise has been discovered inside it.

Write a Solo Founder Idea Kill Sheet

Take one idea that passed the fit memo in the previous chapter. Write a short evidence note under each of these headings:

• Customer and event: Name the person with the pain and reconstruct a recent instance. Record the consequence and frequency.
• Reach and decision: Name the path to the first ten qualified conversations, the buyer, and the approvals between interest and action.
• Alternative and priority: Describe what customers do now and the money, staff time, delay, risk, or reputation already committed to the problem.
• First value: State the smallest result a customer could receive before the full product exists, including what may be manual.
• Early burden: Name the code, data, integrations, setup, exceptions, trust, sales work, and support that must exist before that result is responsible.
• Dependencies: Identify any network, platform, partner, regulatory, credibility, or audience condition that must be present before value appears.
• Boundary: State which customer, workflow, data, promise, or failure consequence the first test explicitly excludes.
• Expansion evidence: Describe what repeated behavior would justify adding the next piece of surface area.

Mark each note supported, uncertain, or blocked, and cite the behavior or observation behind the mark. “Large market,” “people need this,” and “I can build it” are claims, not evidence. Every uncertain mark needs a next action that could change it. Every blocked mark needs a narrowing move or a reason to stop.

Finish with one sentence:

I am narrowing the maintenance marketplace to a founder-run sourcing service for one equipment class in one region because the pain and budget are credible, but liquidity, trust, and urgent support make the broad first promise unfit for one person.

If the decision sentence cannot name the evidence, the burden, and the consequence, the idea is still being protected from judgment.

How the Filter Gets Cheated

The most common cheat is replacing reachability with market size. A large market that cannot be contacted is not an early market. It is a research topic.

Another is treating willingness to complain as willingness to buy. Complaints are useful leads, but the filter needs behavior: workarounds, budget, urgency, risk, or repeated action.

Technical novelty is a more private cheat. The founder builds because the implementation is satisfying. Demos become emotional proof, even when the customer evidence is thin.

Support creates a subtler cheat: calling every custom request “learning.” Some custom work exposes a repeatable pattern. Endless custom work creates a different job for every customer. The test is whether the next request becomes easier to predict, deliver, and bound.

Postponement can also be dishonest when it protects an idea from ever receiving a verdict. Some opportunities genuinely require credibility, capital, partners, licenses, distribution, or operational maturity. Preserve the option by recording the missing condition and reviewing it only when that condition changes.

Now apply the kill sheet to your three strongest ideas. For every uncertain claim, name the cheapest next action that could resolve it. For every blocker, write a narrower version or a kill reason. Choose no more than one idea to pursue in active discovery.

If all three ideas emerge unchanged, the filter has described them rather than filtered them. A solo founder’s speed begins with refusal: complexity should enter only after customer behavior has earned it. The idea that survives is now ready for the next question—what narrow wedge can one person actually carry into the market?