How we decide
Six answers, and only one of them is a company.
Every opportunity we look at runs through the same questions, in the same order, and ends at the same decision: what should this become? The purpose is to make that decision repeatable without making it automatic. Most answers keep the work where it already is, and the most common answer is no.
Before the decision
Six questions, each narrowing the last. An opportunity that cannot answer one does not reach the next.
A signal arrives
Something recurs — a problem seen more than once, a research mechanism, a workflow that keeps failing. We record where it came from, what it is allowed to be used for, and who may see it.
The problem gets defined
Who has it, who would pay, what they do instead today, what it costs when it goes wrong, how often it happens, and why it matters now.
Mechanism and capability get mapped
What could address it — and, kept deliberately separate, which of that already exists and which would have to be built.
A bounded hypothesis gets written
The smallest coherent offer: customer, workflow, input, output, authority boundary, measurable outcome, the conditions under which it refuses, the delivery method, and a price to test.
Technical qualification
A bounded proof built to production shape. Schemas, failure handling, permissions, reproducibility, cost, recovery — and evidence that does not come from the thing being tested.
Commercial qualification
Buyer and user discovery, an explicit paid scope, the real delivery burden, and an honest comparison against doing nothing.
Before any reusable answer is chosen, one more check runs: customer rights, confidentiality, where the source came from, who would maintain the result, and whether the asset can be generalised at all without carrying customer material with it. An opportunity that fails that check is archived regardless of how well it did on everything above.
The decision
Six answers are possible. Five of them keep the work where it already is. The sixth is a separate company, and it does not proceed on this decision alone.
Nothing
The path is rejected or archived. This is the default answer.
A manual service
Some work should stay human and should not be turned into software.
A feature
It belongs inside a product that already exists.
A shared capability
More than one product needs it, and it has earned an owner, an interface, tests, and a support plan.
A product line
A different buyer, a different roadmap, and different economics — inside the same company.
A separate company
The last answer, and the one with a further test attached.
What has to be true first
A generated idea is not a venture. A blueprint is not a venture. One custom request is not a venture. Repetition, a market that supports the product independently, and a product boundary beyond the original engagement are all required before the question is even asked.
Past that, a concrete combination has to be true: distinct leadership, separate financing, a separate cap table, material liability or regulation, distinct intellectual property, independent contracts, independent sale or spinout potential, and economics capable of standing alone. Sharing a method or a component with the rest of the ecosystem is not enough.
Nothing has reached this branch. No company has been formed, no venture terms are set, and no interest has been issued.
After the decision
Three things follow, and none of them reopens the decision.
An operating and entity boundary. Only if distinct financing, ownership, liability, regulation, or management would justify a separate company. That is where Venture Formation begins, and the default answer is no.
Financing matched to the milestone. Capital can sit at the company, the product, a venture, a customer engagement, or a single project, depending on which asset is actually being funded. Which one is a question, not a default.
Scale, revise, or stop. Judged on customer evidence, technical reliability, unit economics, and fit with everything else. A failed wedge should produce a clean decision and preserve what was learned — without being relabelled as traction.
What this cannot do
This can help assemble the package an investor would ask for: the problem and buyer evidence, the specification, demonstrable software, the security boundary, the intellectual-property lineage, the risks and the stop conditions, and an explicit list of the claims that are not supported. Assembling that package does not make a company investable. Documents are not evidence of demand.