<aside> đĄ
Headline lessons
Woltâs starting advantage was the foundersâ prior exposure to how high-performing teams operate. Before Wolt, Miki had built Slush and then worked at Supercell when it was still a small company. He saw firsthand how experienced founders and operators ran product, hiring, and culture with intentionality, and used his prior experiences to build pattern recognition for what was needed to build Wolt.
The founding team was assembled deliberately as a complete product unit. From Mikiâs perspective, the goal of the early setup was to get the right people together and choose a market they could stay in for a long time, while remaining flexible on the angle inside it. In practice, this meant the founders could ship end-to-end themselves, and they did not hire anyone for the first stretch because the founding group already covered the core product-building functions.
The founders of Wolt: (from the left) Mika Matikainen, Lauri Andler, Oskari Pétas, Juhani MykkÀnen, Miki Kuusi, Elias Aalto.
The founding group was split so that Elias led the product build and coded the iOS app himself in the early years, setting a high bar for simplicity and polish in the core experience. Miki took the role of CEO and the âmomentum engineâ, focusing on keeping the company moving and making the right founder-level calls about the market, the angle, and what the company needed next. Juhani leaned into the operational work that made the marketplace function, especially getting close to restaurants and removing friction from adoption. Oskari focused heavily on product and payments early and later on the systems and infrastructure choices that made multi-country expansion repeatable.
Finland shaped an early constraint when building Wolt. The country was too small to build a purely local company, so the team had to assume international expansion early and build with global assumptions in mind. Even before scaling, that pushed them to treat things like languages and currencies as part of the starting architecture, not as late-stage polish.
They chose a category with high frequency on purpose. Food is something people buy constantly, and this exact daily habit is one of the reasons the market was so attractive to them. They also believed the market was structurally âgoing onlineâ because restaurants were the biggest local service and a huge share of food spending was still offline when they started.
When getting started, their first angle into the market was not delivery. The original idea was making it easier to order ahead for pickup or order at a restaurant table, basically removing waiting and friction from eating out. That version made sense on paper, but it did not create strong pull, because it did not solve a big enough pain to change behaviour at scale.
Zooming out from the specific behaviours around their initial product, the purpose behind building Wolt was to take local services online, following the shift of the likes of Uber creating a platform out of taxi services. The commitment was to the market, not to the first product shape, and the team expected to stay in the arena while changing the angle based on what actually worked. The team set out to build Wolt with the idea that they would stay purely a software company, as they wanted to keep operations lean and focus on what they did best. However, for Wolt to survive, the market demanded more out of them, which later forced them to transition into delivery.
Early prototypes of the Wolt app in 2014.
In the early years, Wolt validated by staying close to reality and forcing honest feedback loops. Juhani had a simple but effective approach for this. Ask directly whether someone would pay, then ask why not, and treat those reasons as the actual to-do list. This can be uncomfortable work for some, but it is where most of the real answers live, especially when you are still figuring out what will make people change behaviour.
At the same time, they did not wait for perfect proof before building. Oskari saw early iterations as something you should expect to throw away. The point was to get something into use fast enough that you could see what people actually did, then iterate until the value was clear. That attitude mattered because early versions often fail to communicate the real benefit, and you only find out what works by putting something in motion. This was seen as running âminimum viable testsâ before building rails. Early versions were deliberately manual, so they could prove the behaviour first and only automate once the train was clearly moving.
In the early days, momentum can be tricky when output metrics are flat or noisy. Instead of obsessing over lagging indicators, they focused on controllable inputs such as shipping improvements, tightening the experience, and pushing toward the next version of the product. That created a sense of progress internally even before the graphs turned up, and it kept the team moving through slow patches.
As a general note, the founders also had a few specific beliefs about how to do early product work. The first version of the product was built largely based on founder judgment and taste rather than classic customer discovery, using customer input mainly to catch mistakes rather than outsource direction. Additionally, in product design you need one clear âleap of faithâ in addition to keeping everything else familiar, so the team can concentrate novelty into a single behavioural step rather than spreading friction across the whole experience.
Woltâs first product philosophy was unique in the sense that they didnât believe an MVP should embarrass you. From the teams perspective, their earliest version was the best because it was small, fast, and had very few moving parts. Instead of shipping a wide, messy feature set, they protected the core ordering experience and polished it until it felt truly finished.