Most "how we built it" write ups start with the tech stack. This one starts earlier: with 300 conversations a founder had with procurement leaders before deciding what to build at all.
Omnea's founder, Ben Freeman, spent that discovery phase hearing some version of the same complaint repeatedly, that procurement processes were widely disliked and the tools available were clunky, but nobody had actually rebuilt the stack from scratch.
Why this matters more than the eventual tech choices
It's tempting, especially as an engineer, to treat product discovery as a soft skill separate from the "real" work of building. But the actual technical decisions Omnea made afterward, betting on a two way data orchestration layer instead of a simple dashboard, prioritizing natural language intake over form based requests, only make sense in light of that discovery process.
If you skip straight to architecture without understanding the actual failure mode users are living with, you tend to build a technically impressive solution to the wrong problem.
From validated pain point to funding
The pattern that followed is a fairly clean funding trajectory worth noting for anyone tracking how enterprise SaaS companies scale post discovery: a $20 million Series A once the initial product had traction, followed roughly a year later by a $50 million Series B after the company had grown revenue roughly 5x and more than tripled headcount, bringing total funding north of $75 million.
Enterprise customers including Spotify, Wise, and MongoDB came on during that window, which is a meaningfully different growth signal than early consumer traction, enterprise sales cycles are slower and more scrutinized, so revenue growth at that pace usually reflects genuine operational value rather than a viral feature.
The discipline of staying narrow
One detail worth flagging for engineers specifically: Omnea didn't try to become a general purpose enterprise workflow tool. It stayed scoped to the supplier lifecycle, intake, approvals, risk management, renewals, rather than expanding sideways into adjacent problems the moment funding arrived.
That kind of scope discipline is hard to maintain once you have the resources to build more, and it's frequently the difference between a product that does one thing reliably and one that becomes brittle trying to do everything.
The takeaway
The unglamorous part of this story, the hundreds of unpaid conversations before a single line of production code, is usually the part that gets compressed into a single sentence in startup founder stories, right before the section about the funding round. But it's the part that actually determined whether the eventual architecture solved a real problem or an imagined one.
If you're building anything for an enterprise audience, the lesson generalizes cleanly: the discovery work isn't preamble to the engineering, it's the spec.
Top comments (0)