YC application review

“Show me companies whose customers keep coming back, but that have little revenue.”

The answer changes what a reviewer wants to know next. Are customers completing the work themselves? Is a founder delivering a service behind the interface? Has anyone paid again? Each question cuts across an application’s answers, and each result can suggest a different line of inquiry.

This workspace makes those distinctions available as controls over 600 fictional applications. Narrow the cohort, compare businesses, read the passages behind a finding and keep a question for follow-up. The model prepares contextual findings; the reviewer decides where the investigation goes.

The experience

Begin with repeated customer use and reported monthly recurring revenue below $1,000. In this authored cohort, 202 applications meet both conditions. Add firsthand experience of the customer’s work: 70 remain. These counts come from the saved analysis and cited numerical facts.

Now separate those 70 by how the product operates:

41 work after setup. Customers complete the recurring job without a founder performing part of every request.
19 depend on founder work. Customers return, but a founder still performs a recurring part of delivery.
10 have a mixture. Some customers work independently; others still require that intervention.

Three selected companies make the distinction concrete:

Willowpath handles estimate approvals for vehicle repair shops. Seven customers pay $175 in total monthly software revenue; three have renewed. Their employees check each result, but the founders stopped participating after setup. Human review by the customer is part of the product’s use.
Mosswork handles production handovers for manufacturers. Sixteen accounts repeatedly use its free service, while a founder performs the central work on every request. The activity evidence establishes demand for that work; the operating answer explains how it is delivered today.
Hillspan handles repair enquiries for bicycle workshops. Three accounts complete the work after setup. Three others need a founder to convert legacy inputs each time. Its next product question lies in that specific dependency.

Open Willowpath’s founder-involvement finding and the dated answer explains who checks the work. Open Mosswork’s repeated-use finding and two passages appear together: returning customers and the founder’s recurring role. Hillspan’s source separates its two customer groups. Save the prepared follow-up: “What does the founder do for each completed customer workflow after initial setup?” The question stays attached to the company and finding that prompted it.

Then widen the inquiry:

Look for complications within the current cohort. Of the 70 matches, 34 have evidence that complicates a finding. The original conditions stay in place; the view brings those qualifications forward.
Ask a different question across all 600. Evidence of a customer-acquisition channel working on separate occasions yields 88 matches. A single event that brought several customers does not establish repeated acquisition.
Inspect what remains unanswered. For that channel question, 96 applications need more evidence. They remain available for investigation, separately from the known matches and mismatches.

In the interactive example, Your review keeps the next step you choose for each company:

Review further — keep the company in your investigation.
Follow up first — keep the prepared question with the finding and sources that prompted it.
Set aside — record your current choice while leaving the saved findings unchanged.

Each choice retains the exact application and source context you were reading. The list is saved in this browser across inquiries and reloads. Reopen the evidence to revise a choice, or compare up to three companies from your review. Resetting the inquiry keeps the list; Clear your review removes only that list from this browser. No applicant decision is submitted.

The workspace exposes eight dimensions:

Customer need and repeated use.
Founder involvement and revenue quality.
Firsthand experience and recent progress.
Acquisition and the technical approach.

A missing answer remains Unknown from evidence. A finding that failed our acceptance check is Needs review. An application without analysis would be Not yet analysed. Those states stay distinct, and an unknown revenue amount never becomes zero. A known mismatch can exclude an application from the current filter; uncertainty remains visible as a reason to investigate.

The public example uses saved model analysis and makes no paid model requests. Filters and comparisons run locally over that prepared material. All company material is authored; this demonstration uses no internal YC applications and implies no YC endorsement.

The model and the tool

Every application is analysed with its full supplied dossier. The task asks for eight finite findings, their primary passages and any applicable conflicting evidence. Dates, operating scope and surrounding answers travel with the text. A statement about installation in August should not silently override evidence that customers operated independently in October.

The surrounding tool makes those decisions usable:

Bind evidence. Every finding belongs to an exact application, source version and task version. Citations must name passages in that dossier.
Apply conditions. A conflicting finding requires its contradictory source. Repeated use with recurring founder involvement also needs that operating context.
Compare facts. Revenue thresholds and customer counts use cited numeric values. The model does not perform the arithmetic or invent a missing amount.
Compose the question. Filters combine accepted findings and facts, preserving unresolved cases separately from known matches and mismatches.

full application dossiers
          ↓
independent, bounded analysis requests
          ↓
finite findings + exact source references
          ↓
conditional evidence joins + acceptance checks
          ↓
cited findings and numeric facts
          ↓
filter cohort → compare companies → inspect sources
          ↓
reviewer chooses a follow-up

One small join matters disproportionately. “Customers repeatedly use it” and “a founder processes every request” can both be correct. Showing only the first finding invites the reader to infer independent product use. The tool therefore joins repeated use to the separately accepted operating finding and carries that source into the evidence view. It preserves both decisions and their meaning together.

This division of work keeps exploration quick. Contextual interpretation supplies finite findings. Explicit rules decide when findings belong together. Deterministic operations update the interface. A new cohort filter works over the prepared material without asking a model to reread every application.

Spoken navigation is a separate decision task. The model interprets only the recognised sentence; the tool then checks that interpretation against the current filters, selection and view. This separates what the person asked from what the workspace can do next.

Two requests illustrate why the interpretation needs more than a convenient command name:

Customers returning to use a product is a finding about repeated use. A channel bringing in new customers on separate occasions is a finding about acquisition. Asking for both must retain both conditions; the tool refuses a combination its supported operations cannot express.
“Within those” and “across all six hundred” identify different scopes. The tool can add a condition to the current cohort or begin a new question across all applications. The interpreted scope travels with the decision and is checked before the view changes.

The tool compiles the interpreted operation, scope and conditions into a supported interface change. A comparison also checks the selected companies; a revenue filter preserves the requested period and strict threshold. These operations navigate the saved application analysis. They do not analyse all 600 applications again.

The navigation contract binds each reply to the exact dataset and interface state submitted with it. A reply for an older view cannot silently overwrite a newer selection. This protects the inquiry’s continuity: the person can see which question produced the current group, and the next operation starts from that same context.

What we checked

We froze the fictional source material, expected distinctions and eligible citations before running the analysis. The same 600 applications were evaluated with one final task revision. Of 4,800 findings, 4,794 passed the label-and-evidence acceptance checks. Six remain withheld as Needs review; the other seven accepted findings in each affected application stay usable. This produces 594 fully accepted applications.

The evidence compiler has its own tests. It cannot replace a semantic label, hide a required contradiction or add an operating caveat from an unaccepted finding. Raw labels and raw citations are retained separately from the compiled result. The source material uses shared authored scenarios, so these numbers describe this controlled example, not general accuracy on real applications.

The interface was also checked against the full dataset:

Filter counts, three-company comparisons and exact source text.
Personal review choices, revisions and persistence after reload. Clearing your review preserves the inquiry and separately saved follow-ups.
Keyboard navigation and narrow screens.

Those checks matter because an accurate finding attached to the wrong company would still mislead the reviewer.

A separate recorded session on 31 October 2026 used actual spoken audio, speech recognition and seven live navigation decisions. All seven selected the intended operation. Measured speech end to browser paint opportunity ranged from 0.764 to 1.012 seconds: six were below one second; the first took 1.012 seconds. The measurement includes trailing silence, recognition, the decision request and the interface update. Two animation frames estimate a paint opportunity, rather than physical display latency; recording alignment has a 43ms bound. These are results from this controlled session. The 600 applications and 4,794 accepted findings were already prepared; changing the view did not classify them again.

“Speech end” is an acoustic estimate: the end of the last 10 ms audio frame with RMS level at or above −45 dBFS, mapped to the browser’s estimated audio output time. Each prerecorded input plays in full before warmed GPU recognition. Live microphone endpoint detection was outside this run.

A useful research connection

Ben Shneiderman’s work on dynamic queries describes exploration through visible controls, rapid feedback and reversible changes. Its examples let people discover a question through interaction: adjust a condition, notice an exception, then investigate it. That is a useful design requirement here. The current conditions and result must remain legible as the reviewer changes direction.

The additional step is making contextual attributes available to that interaction. “Has the founder done this work?” and “Does repeated use depend on founder intervention?” require reading prose in context. A decision model can help prepare those attributes; the interface then supplies ordinary filtering, comparison and source inspection. Interpretation and exploration operate at different timescales.

The FEVER benchmark evaluates claim labels together with the evidence sentences needed to support or refute them, and includes a separate insufficient-information category. Our business distinctions are a different task. We apply the same useful separation between a finding, its evidence and what the material leaves unresolved. That is why Mosswork’s activity and operating passages belong in the interaction where repeated use is being compared.

Building it with SYSTEM1

A review team could commission this tool by describing the distinctions it uses and supplying examples where context changes the answer. Useful cases include:

A founder’s initial installation work versus manual intervention on every customer request.
A paid service bundle versus separately recurring software payments.
Several personal introductions versus a channel that produces customers in successive periods.
A roadmap versus a shipped mechanism with observed use.
A past limitation resolved by a later release versus two incompatible accounts of the same period.

The deliverable combines a task vocabulary, evaluated model behavior, source bindings and the interface through which a reviewer acts. Its definition should also specify how new evidence invalidates old findings. A later founder answer can change one dimension without making an earlier payment ledger disappear.

The current example uses a prototype decision model and saved analysis. A specialized model could learn recurring distinctions in the tool’s exact vocabulary, while receiving the current application as live state. That would need evaluation against the same source and task contracts; specialization does not remove the need for evidence checks. The broader decision architecture is what turns those findings into a continuing workflow.

Where this could lead

The next step is a workspace that stays useful as the reviewer learns. Several concrete extensions follow from the same mechanism:

An interview that changes the cohort while it is happening. A founder explains that two customers no longer need manual conversion. Attach the answer to those customers and the relevant period, recheck the operating finding, then update the filters and caveats that depend on it. Other evidence stays visible while that small update runs. The reviewer can see which earlier question was answered and choose the next one.
A comparison that produces a new search. Willowpath’s customer-side review and Mosswork’s founder delivery suggest a more precise question: who performs the indispensable step? A reviewer could define that distinction, inspect proposed examples and commission a new finding across the cohort. The next inquiry grows out of the source comparison rather than having to fit the initial menu forever.
A handoff another reviewer can continue. Share the three companies, the exact source passages and the unanswered follow-up. When a colleague receives a new answer, show which findings it changes and which comparisons used them. The shared object becomes an investigation with a history, rather than an isolated summary that each person must reconstruct.
The same interaction inside a business. A product team could ask which accounts repeatedly complete a workflow yet still need support at its hardest step. Compare those accounts, inspect the support exchanges and choose an experiment. As new results arrive, update the affected group while the team continues investigating the others.

These are proposed extensions. The working example establishes their starting point: contextual findings that can be combined, inspected and used to decide what to ask next. Small model decisions make the material navigable; the reviewer’s evolving questions give that navigation a purpose.