Technical ideas are easy to admire in a presentation. Investment decisions require a more demanding question: can this idea become a product that customers trust, use and pay for?
I do not expect an early-stage company to have every answer. I do expect the founder to understand which answers matter, to distinguish evidence from belief and to show that the team can learn quickly.
The following framework helps me assess technical ideas without being distracted by fashionable language or impressive demonstrations.
The problem must be specific and important
A broad problem produces a broad product. Broad products are difficult to explain, difficult to sell and difficult to prioritise.
I want to know who experiences the problem, when it occurs, what it costs and how people manage it today. A credible founder can usually describe this in practical terms because they have observed the workflow closely.
The strongest opportunities often begin with a narrow, persistent problem. The initial market may look smaller, but the value is easier to demonstrate and the route into the customer is clearer.
The customer must have a reason to change
A problem can be real without creating a market. Customers may tolerate it, work around it or decide that replacing the current process is too risky.
I therefore look beyond stated interest. Useful evidence includes:
- customers giving detailed feedback on a prototype
- a pilot with clear success measures
- users returning without being prompted
- a buyer allocating budget or signing a letter of intent
- an existing manual process that already consumes meaningful time or money
The important question is not whether people like the idea. It is whether the proposed improvement is strong enough to change behaviour.
The founder needs a genuine advantage
An early company cannot compete on resources. It needs leverage.
That leverage may come from technical ability, specialist knowledge, customer access, timing or an insight that established providers have missed. It may also come from the founder's ability to combine several disciplines that competitors normally separate.
I look for a clear explanation of why this team is well placed to solve this problem now. Personal commitment matters, but commitment alone is not an advantage. The founder needs a reason to learn faster, build better or reach customers more effectively than alternatives.
Evidence should improve with each stage
The standard of proof should rise as the company asks for more capital.
At the earliest stage, a thoughtful prototype and well-documented customer conversations may be enough to justify a small experiment. Later, I expect stronger evidence such as regular product usage, paid pilots, repeatable acquisition and a credible understanding of unit economics.
Progress is more persuasive than presentation. A founder who can show what changed because of customer evidence demonstrates an ability to make good decisions under uncertainty.
The product must be more than a demonstration
Many technical ideas work in a controlled environment. A commercial product must work repeatedly, safely and at an acceptable cost.
I consider:
- data availability and quality
- integration complexity
- expected performance at realistic volumes
- security and privacy requirements
- operational support
- infrastructure and third-party costs
- the team's ability to maintain the system
This does not mean every production concern must be solved before investment. It means the founder should understand the path from demonstration to dependable service.
Distribution matters as much as technology
Technical differentiation is valuable, but customers still need to discover, evaluate and adopt the product.
I want to understand who makes the buying decision, who influences it, how long approval takes and what proof is required. In enterprise markets, procurement, security review and integration work can shape the commercial model as much as the product itself.
A realistic route to market is more valuable than a large theoretical market with no practical entry point.
Security and reliability begin early
Security is not a final feature added before launch. Early decisions about data, identity, permissions and system boundaries influence the cost and credibility of everything that follows.
I do not expect a young company to operate like a bank. I do expect sensible controls, clear ownership and an understanding of the standards customers will require.
Ignoring these matters can delay sales, weaken trust and force expensive rework at the point when the company most needs momentum.
The economics must have room to improve
Early unit economics are rarely perfect. They should, however, point towards a viable business.
For software and AI products, I pay particular attention to infrastructure cost, model usage, implementation effort and ongoing support. Revenue that depends on heavy manual delivery may still be attractive, but the founder should know which work can become repeatable and which work will remain service-led.
The aim is not to demand certainty. It is to understand whether growth can improve the business rather than simply increase its workload.
The final assessment
I return to four questions:
- Is the problem important enough to create action?
- Does this team have a credible advantage?
- Is there evidence that learning and delivery are happening?
- Can the product become secure, reliable and commercially sustainable?
A promising technical idea does not need perfect answers. It needs honest assumptions, relevant evidence and a team capable of closing the gaps.
If you want useful feedback, share the clearest version of what you have built, the customer evidence you have gathered and the most important question you need to answer next.
The technical due-diligence reading path develops these questions into a more structured assessment of AI and SaaS risk. My operator-led investment approach explains how evidence shapes the kind of support I consider.