Picnic 10 years: 2022 — Building a Store Platform to Scale Beyond a Million Customers
Lessons learned from 8 years of building the Picnic Store
Picnic’s story has always been about growth. In just a few short years, grocery delivery went from a niche curiosity to something that close to a million families now rely on week after week. For many customers, having groceries arrive at their doorstep has become as natural as unlocking their phone and opening the Picnic app, where they go to discover, select, and buy everything they need for their family.
When we started out, we made a simple assumption: customers already know what they want, so the fastest way to help them is to enable them to add that to their basket as quickly as possible. As such, our app was optimised to quickly add known products to a basket and then check out.
That worked — extremely well. The store became a champion of efficiency, and customers loved how quickly they could reorder groceries. But over time, we found out that the customer problem to solve for was much bigger: deciding what meals to buy for their families. Our store didn’t help customers solve this problem as it lacked features to inspire people, didn’t help them decide what to cook for dinner, and didn’t showcase the full breadth of our assortment.
In other words: the store was great at reordering, but it wasn’t helping customers with the real challenge of grocery shopping.
By year 8, with close to a million customers across several countries, we needed a store that could do both.
Our Early Store Architecture and Its Limits
Technically, the first version of the store was built using classic architectural patterns. On the backend, we were using a service-based architecture powering our mobile apps built for iOS and Android using native technologies. It worked, but every new feature followed the same repetitive pattern:
- Build a persistence layer for new data
- Build a logic layer to interpret and manage access to that data
- Expose the logic through a RESTÂ API
- Call it from a backend-for-frontend (BFF) service or directly from the client
- Write logic to combine the data and transform it into a meaningful presentation
- Render it on the client
This pattern was predictable, but also wasteful. We were reinventing the wheel for every new use case, solving the same problems again and again.
In 2019, we took a first stab at increasing our efficiency by moving our mobile development stack towards React Native. This allowed us to reduce code duplication and increase consistency. We could finally share more code across platforms and focus our engineering effort on customer-facing improvements instead of platform parity.
Still, most of the business logic lived inside the client apps. That meant customers needed to update their apps in order to get changes in functionality. If we wanted to tweak the checkout flow, experiment with a new layout, or update images or text, we had to wait until customers downloaded the latest version. Many didn’t, leaving us with long iteration cycles, frustrating delays. And on the backend, we still found ourselves repeating the same pattern over and over again and saw an increasing amount of technical debt in the form of old code we needed to keep around for backwards compatibility.
Why We Needed a Store Platform
By the end of 2018, our increased ambitions were at odds with the limits of our architecture. We wanted to innovate faster, test more ideas, and support a growing assortment and new propositions like recipes, loyalty programs, and increased personalisation. At the same time, we wanted to keep our engineering team nimble and maintain our start-up culture.
With this in mind, the goals for the next step in our evolution became clear:
- Speed — shorten the time-to-market for new features
- Flexibility — rollout new functionality without relying on app releases
- Empowerment — enable our pool of SQL-savvy business analysts to create and adapt store features themselves, without waiting for scarce engineering capacity
- Scalability — build an architecture capable of supporting international expansion and new business models
To achieve this, we needed to fundamentally rethink how the store worked.
The Shift: From App Logic to Server-Driven UI
The breakthrough idea was deceptively simple: move the business logic out of the app and into the backend.
Instead of the app “knowing” what a product tile or a category page looked like, the app would become nothing more than a rendering engine. The backend would describe what to show, and the app would simply render it.
To make this possible, we needed:
- A generic data layer to define and store attributes without spinning up purpose-built services
- A query engine to democratise data access over SQL
- A server-driven UI framework to transform data into meaningful layouts
- A rendering engine to interpret these layouts on the client and render them to the user
Pages were no longer hardcoded. They became dynamic, configurable, and instantly updatable. We could change what customers saw in the store without waiting for them to update their app.
This was a huge bet. Not only did we redesign the underlying architecture, we also launched it together with a complete redesign of the app’s visual language. Rolling out both at the same time was risky — but it worked.
Building the Store Platform: PPP
We called the new architecture the Picnic Page Platform. It is composed of four main building blocks:
- Attribute Data Store (ADS) — a generic data persistence layer, configurable at runtime. Instead of writing new services for each use case, analysts can define attributes (for example: “favourite articles” or “customer value contribution”) with a few lines of configuration.
- Query Engine — all analysts at Picnic already speak SQL. With the query engine, they can combine attributes and other data sources into meaningful datasets that power store pages.
- Page Framework — a lightweight JavaScript/React-like framework that transforms data into layouts. Analysts and developers can use it to define how a page looks and behaves.
- Powerful configuration tooling to tie it all together.
Together, these components follow a simple but powerful pattern: Define → Extract & Transform → Present.
Originally, PPP supported only read-only use cases — great for showing off our assortment and purpose-built promotional pages. Over time, we extended it to support interactivity. Today, features like the meal planner or self-service forms run entirely on PPP.
Strategic Journey — Accident or Design?
Looking back, it’s tempting to describe PPP as the result of a clear, top-down strategy. In reality, it was more organic — a combination of pressing pain points, opportunistic experiments, and leadership creating space for bold bets.
The journey began with small proof-of-concepts. A project to redesign the look and feel of our Storefront was the first to explore server-driven UI. From there, the approach scaled into a domain-wide vision.
Along the way, we learned a few key lessons:
- Write things down early. Complex architectural ideas are hard to communicate; documentation helps align everyone.
- Zoom out. Don’t just solve the immediate problem — ask if there’s a more general solution that can pay dividends elsewhere.
- Talk, talk, talk. Big ideas rarely click instantly. Share them widely, refine them in conversation, and repeat until they stick.
- Optimize for Picnic’s unique context. We build more in-house than most companies, and our business analysts are unusually technical. What might seem strange elsewhere makes perfect sense at Picnic.
PPP wasn’t the inevitable outcome of a grand plan. It was the product of iteration, persistence, and a willingness to rethink fundamentals when the old way no longer worked.
Impact and Multiplying Effect
The impact of PPP was immediate and profound.
- Iteration speed skyrocketed. What once took weeks or months can now be done in days. Analysts can create and publish new store pages themselves.
- Business teams gained autonomy. Engineers focus on platform improvements, while analysts experiment with layouts, promotions, and personalisation.
- New propositions became easier. Recipes, loyalty programs, discounts, and contextual promotions all leverage the same underlying framework.
- Platform improvements multiply. Any investment in PPP — better observability, performance tuning, new UI components — benefits every feature built on it.
Perhaps most importantly, PPP changed how we think. Instead of asking “how do we build this feature?”, we now ask “how do we extend the platform so that this and the next ten features can be built more easily?”.
Looking Ahead
Almost four years into this journey, the platform we built is no longer just about the customer store. We are currently looking into opportunities for extending the platform to other Picnic apps. The vision is to create a unified platform that powers experiences across Picnic, whether customer-facing or employee-facing.
The north star remains the same: a flexible, adaptable platform that keeps Picnic’s customer experience continuously state-of-the-art.
Page platform as a testament to the amazing engineering culture at Picnic
Building the Store Platform was not just a technical achievement. It was an organizational and cultural one.
It required engineers willing to rethink everything, analysts eager to step into new roles, and leaders ready to back bold bets. It reflects Picnic’s DNA:
- Solve hard problems in-house.
- Empower people closest to the problem.
- Think long-term while moving fast.
Year 8 was a turning point. By investing in a platform approach, Picnic built the foundation to scale far beyond a million customers in the years to come.
The store is no longer just an app. It’s a living, adaptable platform — and with it, we’re ready for the next 10 years of growth.
Thanks to Stephan Schroevers for contributing ideas to this article, reviewing drafts and being an allround amazing partner in crime in this whole endeavour.
Picnic 10 years: 2022 — Building a Store Platform to Scale Beyond a Million Customers was originally published in Picnic Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.
