Note – These are reflections from my experience building and scaling deep-tech startup as a founding engineer. Not related to any specific company or product. Not all ideas are fully formed yet.

We’re not building salesy/marketting tools. We are building “deep tech”.

It is a fallacy that deep tech needs to be perfect before it can be used. At the end of the day, it’s a product that needs to be used, not a theory that needs to be proven.

Users don’t stumble into our product - they choose to trust it. That makes trust the real currency early on, not polish.

But trust != zero bugs. It’s honesty. Feedback loops. Fixes that land fast.

Taking example of SpaceX, they didn’t wait for perfect rockets before launching. They launched, learned, iterated. Deep Tech for them was about reducing launch costs, not waiting for flawless designs.

Raptor Engine

I don’t fully buy the idea that “Deep-tech(DB, Scientific computing, Infra etc) needs to be perfect before scale.”

You don’t even know what breaks until you’re in the wild.

Correctness under pressure - under real use, with real edge cases - that’s the only correctness that matters.

If we wait for perfect:

  • we overfit to theories, not usage
  • we build things nobody asked for
  • we ship slower, and probably heavier

And maybe worse - we send the signal that we’re more interested in appearing smart than being useful.

Early adoption doesn’t mean someone’s putting it in prod tomorrow. Some users are just exploring. They’ll forgive rough edges - but not if the door is locked.

It’s easy to hide behind “deep tech” as an excuse to move slow. But DeepTech != SlowTech.

Deep just means hard problems. Doesn’t mean we get to skip iteration. Our advantage is speed plus technical depth. Lose speed, and we’re just another heavy tool with good intentions.

Adoption is earned, not deserved. Trust is built, not assumed. Speed is strategic, not optional.

Just putting this down so I don’t forget.