Really liked this, especially the emphasis on not confusing a lab with a company.
One nuance from the hard deeptech side is that sometimes you genuinely can’t get to a trivial MVP. The very thing that makes the company non-obvious is often buried deep in the stack. If you abstract it away too early, you lose the point.
You still need something customers can touch. In practice that often means building a thin, usable surface around a very unfinished core. It means being explicit with early design partners that they’re seeing “inside the factory,” not a polished product. And it often means using simulations, constrained environments, or narrow workflows as proxies until the deeper technology is stable enough.
That’s also where the engineering vs customer split gets subtle. A 50/50 balance sounds right in theory, but in early hard deeptech the split is really about risk. Engineering reduces technical risk. Customer development reduces market risk. The weighting depends on what would actually kill the company at that stage.
If you raise a small pre-seed, you’re not funding parallel machines. You’re funding proof of inevitability. That usually means depth has to move slightly ahead, but always in service of unlocking real customer conversations.
At Qognetix we’re leaning into regulated markets, where engineering is done for the customer and science is done for validation. In that context, depth isn’t optional. But it has to be tightly coupled to auditability and real-world constraints.
The art, at least for us, is keeping that depth narrowly scoped and obsessively tied to a few painful, ownable problems, rather than trying to MVP the entire stack at once.
Really liked this, especially the emphasis on not confusing a lab with a company.
One nuance from the hard deeptech side is that sometimes you genuinely can’t get to a trivial MVP. The very thing that makes the company non-obvious is often buried deep in the stack. If you abstract it away too early, you lose the point.
You still need something customers can touch. In practice that often means building a thin, usable surface around a very unfinished core. It means being explicit with early design partners that they’re seeing “inside the factory,” not a polished product. And it often means using simulations, constrained environments, or narrow workflows as proxies until the deeper technology is stable enough.
That’s also where the engineering vs customer split gets subtle. A 50/50 balance sounds right in theory, but in early hard deeptech the split is really about risk. Engineering reduces technical risk. Customer development reduces market risk. The weighting depends on what would actually kill the company at that stage.
If you raise a small pre-seed, you’re not funding parallel machines. You’re funding proof of inevitability. That usually means depth has to move slightly ahead, but always in service of unlocking real customer conversations.
At Qognetix we’re leaning into regulated markets, where engineering is done for the customer and science is done for validation. In that context, depth isn’t optional. But it has to be tightly coupled to auditability and real-world constraints.
The art, at least for us, is keeping that depth narrowly scoped and obsessively tied to a few painful, ownable problems, rather than trying to MVP the entire stack at once.
This is very true - finding "the way" to get milestones validated with limited resources is one of the biggest defining factors for founders