.webp)
<aside> đź’ˇ
Headline lessons
Aiven started with a founding team that already had deep, practical exposure to the exact problems they were about to productize. The four founders had worked together before at F-Secure, which meant they already had a feel for how they operated together day to day. That mattered because it reduced early coordination overhead and let them move quickly without needing to “discover” basic trust and working dynamics from scratch.
The team was also deliberately complementary. Three of the founders came from a Postgres-focused consulting background where they had spent years operating and fixing open-source databases in production environments. Heikki, in parallel, had been driving a DevOps and cloud transformation track that focused on making development teams more independent and removing central bottlenecks. Together, that mix meant they understood both sides of the problem: the low-level infrastructure “plumbing” work and the organisational reality of how developers actually want to build and ship.
The Aiven founding team
Aiven started in the part of software that most people never see. Databases, networking, security, and other infrastructure “plumbing” power almost every application, but they are mostly invisible when they work and only noticed when they break. While every company depends on these systems, very few want to spend their time developing and managing them because it is rarely the thing that makes the company win.
That shaped the wedge they went after. Oskari saw their advantage to be a narrow expertise in areas where incumbents were not yet exploiting the opportunity. With that in mind they realised that if what you build is too easy for a cloud platform to bundle, your product could become just a feature inside someone else’s platform rather than a standalone company.
Heikki also realised they had one more constraint that made the arena choice sharper. From the beginning, they assumed this could not be a Finland-only business. They wanted something that could serve thousands of customers, and that required building for a global audience from day one. In practice, that meant choosing an arena and a wedge that could repeat at scale, not a niche that only works through one-off relationships.
Aiven’s earliest validation came from repeating the same operational work for years. The team kept fixing and running open-source databases, first for their employers and later for consulting customers. After enough cycles, the pattern was hard to ignore. If the same pain keeps resurfacing, the scalable answer is not another engagement. The scalable answer is to build the service you wish existed.
They validated the idea not just on pain, but on timing. They saw that cloud platforms like AWS had changed what “infrastructure” meant. The key shift was not that servers moved to someone else’s data center. The shift was that infrastructure became programmable which meant a developer could create what they needed with an API call instead of waiting for hardware to be purchased and installed. Once you see cloud that way, the initial product direction makes sense. Aiven aimed to make databases work the same way: self-serve, instant to start, and available to anyone who could enter a credit card.
On the engineering side, they treated scale as a design constraint rather than a later refactor. They took into account that manual hands do not scale, and customers do not want to “carry a pager,” which pushed them toward automation and self-healing as the only way the model works. At the same time, they avoided turning implementation perfection into procrastination. If market pull is real, you can rebuild parts later. The job is to move fast enough to reach real usage while keeping the fundamentals strong enough that you are not trapped by your own architecture.
It took the team about a year to reach their first MVP. Oskari sees that this timeline was reasonable for multi-cloud data infrastructure, as long as they were making steady progress toward something real. They were not trying to win by being fast on a calendar, instead, they were trying to get a service into the hands of real users.
The MVP bar was set by one non-negotiable constraint: the service had to stay online and recover from faults automatically. They intentionally postponed other concerns and focused on reliability first, because nothing else was meaningful until the core service could be trusted.
When the product was finally live, they ran into a different reality and realised that building it was not enough. Heikki and Oskari both look back to the moment during their launch when they realised they still needed to do marketing to attract customers, as they wouldn’t come on their own. As a result, they began talking about it publicly and running small experiments such as tweeting and using sponsored tweets.