01 Problem
The problem
Cold pitches were my discovery instrument. Of the ten things I recorded about each business, six only existed after a human conversation - so what a market needed was known only for the few who wrote back, and only after I had already pitched them something.
I wanted the order reversed. Not 'give me startup ideas', but show me real problems people are repeatedly experiencing, prove them with evidence, and help me decide what is worth solving.
02 Evidence
How I knew it was real
- My own discovery notes from July: six of the ten fields per business depended on a reply.
- I already had an offer - that salons lose money to last-minute cancellations - resting on nothing but my own reasoning. Its blueprint was committed four hours before Problem Seeker's first line.
03 Decision
What I set out to change
Replace 'I think salons have this problem' with a count of independent people saying so in public, each kept with where it came from - and keep what that count means a human decision.
What I deliberately left alone
- What a problem means commercially. It finds and counts; whether to build, and what to charge, stay mine.
- Any claim about a specific business. Market evidence is evidence about a market: it never becomes 'I noticed you have a cancellation problem' in a pitch, and whether a business would want the answer is always recorded as unknown.
- Paid sources. A paid search is created waiting for approval, and refuses to run while it waits.
The choices worth arguing with
Chose No problem exists without evidence - the code refuses to create one.
Over Asking a model to suggest problems worth solving.
Because A generator produces plausible problems. I needed ones people had actually complained about, with a link to where.
Chose Four levels with written reasons: pain, prevalence, solvability and confidence.
Over One 0-100 opportunity score, which my first design used.
Because A single number hides which part is weak. A written reason tells me what to go and check.
Chose A strict gate: a post counts only if it states a problem and names one of five operating failures.
Over Letting a model classify every post.
Because The gate is auditable. Everything it refuses is counted as noise, so I can see what it threw away.
Chose A trend needs two populated 30-day windows.
Over The first version's 'emerging' label for a single burst.
Because A burst in only one window is recency, not evidence of direction.
04 Build
What I built
It runs from a form, or from a watch that asks again every week. Collection is deliberately small: one public source, a ten-second timeout, at most 75 posts, ranked by relevance.
Every post is fingerprinted, so a repost keeps its provenance but cannot count twice. Then the gate: a post is evidence only if it states a problem and names what broke. Everything else is counted as noise and kept out of the count.
What survives is grouped by the failure it describes, assessed on four levels with a written reason for each, and stored as a Problem with every piece of evidence attached. From there it can be matched to a system Evara can build and carried into positioning and a lead search - still marked as evidence about a market, never about any one business.
- SourceA questionTyped into a form, or asked again every week by a watch.
- SourcePublic discussionOne source, bounded: ten seconds, 75 posts, by relevance.
- StepFingerprintA repost keeps its provenance and counts once.
- StepThe gateKept only if it states a problem and names what broke.
- KeptCounted as noiseEverything the gate refused, counted so I can see it.
- From The gate · keptStepCluster and assessGrouped by the failure. Four levels, each with a written reason.
- KeptA Problem, with its evidenceRefused outright if nothing is under it.
- A personI read itIgnore, watch, or propose a system. The meaning is mine.
- OutPositioning, then a lead searchStill marked as market evidence, never a fact about one business.
05 Validation
How I tried to break it
The same complaint, reposted
Keeps its provenance, and counts once.
Held
A question about a product, phrased like a complaint
Refused by the gate. A question is not demand.
Held
A burst of posts in a single month
Not called a trend. It needs two populated 30-day windows.
Broke, then fixed · 31 Aug 2026
A request for a paid source
Created waiting for approval, and refuses to run while it waits.
Held
A problem with no evidence under it
The code throws rather than record it.
Held
Market evidence carried into a pitch
Kept as a claim about a market. Whether a business wants the answer stays unknown.
Held
What did not work
- My first attempt, built outside the product, was designed for five kinds of source, six workflows and a review bot. It got through two of its six planned stages and stopped. The narrow version inside the product changed a product within a day.
- The first in-app version sorted by keyword and newest-first, and called a single month's burst 'emerging'. I rebuilt it in under nineteen hours.
- The eleven posts came from one source, found by a query that already asked about cancellations. It confirmed a hypothesis I had; it did not discover one. And confidence still rates that set HIGH, because a second source adds to confidence without being required.
06 Outcome
What changed
- 11 independent posts behind its first Problem
- A live run on 2026-08-31, as recorded in the commit that used them. All eleven came from one public source.
- 7 h 22 min from the rebuilt Problem Seeker to a redesigned product
- Commit times on 2026-08-31: Problem Seeker v2 at 11:33, Cancellation Recovery v1.1 at 18:55.
- 2 of 6 stages my first attempt built before it stalled
- The status list in that project's own README. Its last commit was on 2026-08-10.
- 19 / 19 tests passing
- Run on 2026-09-11. Thirteen test behaviour; six check the source rather than running it.
The first real Problem it produced - last-minute cancellations leaving salon capacity unsold - went into positioning and a lead search the same day, and then changed the product built for it. Cancellation Recovery v1.1 made a consented waitlist the product itself, because the evidence said the waitlist was what worked.
The chain it feeds ran end to end against live data and stopped where it should: at zero businesses shortlisted, because shortlisting is a person's job and nobody had done it yet.
What I measure next
- How much of what it reads is noiseThe rejected-noise counter each run already writes, added up across runs.
- Whether the gate is rightHand-label a sample of kept and refused posts and measure precision. There is no labelled set yet.
- Whether the weekly watch finds anything newWatch deltas - the columns exist, and nothing writes them yet.
07 Learning
What I learned
The count justified building the offer. The design came from one outlier among the eleven, which no counter would have picked out. A person reading the evidence is part of the system, not a step to automate away.
Narrow beat broad by a distance. The ambitious standalone version never got past collection; one source and one strict gate, wired into the product, changed a product within a day.
A count needs its provenance printed beside it. 'Eleven posts' reads as a market. 'Eleven posts, one source, one query that already asked about cancellations' reads as what it is.
What I would change next
- Require more than one source before confidence can read HIGH.
- Count distinct authors, not distinct titles.
- Build the labelled set, so 'the gate works' becomes a number.