From Farm to Fork

Inside Picnic's CTO's Technology Bet

Picnic’s CTO on building an end-to-end technology platform that now serves 5 million customers across 300 cities and towns from 20 robotized and automated fulfillment centers.

When Daniel Gebler and his co-founders set out to build Picnic in 2014, they were driven by a strong conviction that the existing food and logistics ecosystem was fundamentally broken—and that it could be radically improved by rethinking, from first principles, how people buy their food; at its core, their ambition was simple but bold: to completely redesign the grocery experience in a way that customers would genuinely love.

"We started Picnic not because we wanted to build a better supermarket," Gebler says.

Today, Picnic operates across the Netherlands, Germany, and France with a team of 400 engineers organised into around 50 product and engineering teams. It offers free delivery, a lowest-price guarantee, and an increasingly AI-powered shopping experience.

None of that was inherited from existing retail software. Every major system, from the consumer app to the warehousing infrastructure, was built in-house. Understanding why, and how, reveals a coherent philosophy about technology, growth, and competitive advantage that extends well beyond the grocery sector.

Buy a system, buy its limits

The question of whether to build or buy software is a familiar one in technology organisations, and the standard answer usually depends on time and resources. Gebler's answer depends on something else: what kind of company you intend to become.

"If you take something out of the box, you buy basically a system that automatically also has a ceiling," he explains. "You buy your limitations. And you have very fixed limitations already upfront." For Picnic, those limitations were incompatible with the ambition of what they were building: an integrated system connecting every point from farms to family dinner tables. Off-the-shelf components, even good ones, would have constrained how far the company could eventually go.

The alternative was slower at first. Competitors using ready-made solutions could launch features and processes that Picnic had to design and build from the ground up. Gebler is candid about the cost of that: "Especially in the beginning it is painful if you build it all yourself."

That pain, it turns out, was at times more than metaphorical. One particularly testing moment came during the scaling of Picnic's first robotic operations, when the seams of the in-house approach began to show. "One near-breaking point came when we were scaling our first robotic operations," Gebler recalls. "Our self-built material handling, routing and batching logic couldn't yet handle peak volatility. We saw service quality degrade and had to manually intervene to keep customers happy." The crisis forced a hard internal reckoning. Should Picnic stay the course, or reach for an external solution to plug the gap?

They chose to stay the course. "We introduced a full-fledged simulation environment to stress-test our systems before deployment," Gebler explains. The ability to rehearse the supply chain digitally before changes go live became, in his view, a durable competitive asset. "That capability became a lasting advantage we wouldn't have had if we had taken the shortcut." It is a telling example of how constraints, when confronted rather than bypassed, can generate capability.

The compounding effect of owning your systems became increasingly visible over time. "We now have lightning speed in building new features," he says, "because we have tailored it completely to our use case."

The principle Gebler describes is one of optionality. Rather than locking the company into decisions made by others (like third-party vendors), building in-house instead preserves the freedom to evolve. "As technologists, we don't like limitations. What we like is optionality. And optionality over time actually compounds and creates a competitive advantage that boosts your business into an entire new stratosphere."

Build one system, not fragments

The same logic that governed the build-or-buy decision also shaped how Picnic approached its supply chain architecture. The temptation, when studying an existing industry, is to copy what appears to work. Gebler resisted this deliberately.

"There's a high temptation to just copy what works," he says. "But there's a big problem with this approach: If you have a puzzle of 20 pieces and you copy 10, then essentially the remaining pieces that you can plug in are so limited that there's no other way than just rebuilding the other 10 in the same way as it was done before."

Instead, Picnic forced itself to reinvent processes even when existing solutions appeared functional, ensuring deep integration across the whole system. "We have never taken an isolated component, or a stand-alone fulfillment center, as isolated pieces. On one side we have food producers and brands, on the other side you have families that eat at the table, and everything in between we are connecting, plugging together, and trying to optimize in the most effective way."

This integrated thinking has material consequences for customers. Picnic's extensive forecasting systems, a result of owning the full stack, keeps food waste significantly lower than traditional supermarkets. Less waste means lower costs, and lower costs feed directly into pricing.

"We have built exceptionally strong forecasting systems, which means that our waste in the supply chain is also much lower than any other supermarket. If you have less waste, you obviously also are more efficient and you can give this back to customers with better prices."

With 50 product and engineering teams each maintaining custom-built components, the risk of accumulating technical debt, of complexity compounding rather than capability expanding, is real. "What keeps this scalable is that we actively design for replaceability," he says. "Every system is built with the assumption that it may be rewritten or replaced at some point." That single assumption, he argues, changes engineering behaviour in fundamental ways: it pushes teams toward smaller services, clear contracts, explicit constraints, and minimal hidden coupling between components.

Beyond the structural guardrails, Picnic has codified simplification in its technology strategy. "We run continuous 'evolution cycles' where teams are explicitly tasked not with features, but with simplifying or re-architecting parts of the system." And critically, the signal for when and where to intervene comes from the systems themselves: "We use production data as a feedback loop, not just for product decisions, but to identify structural inefficiencies in the architecture itself." The result, as Gebler describes it, is a kind of ongoing compression. "Complexity is continuously compressed rather than accumulated."

Move steadily and with conviction

Picnic's expansion strategy followed the same integrated logic as its technology decisions. Cities were added one-by-one over time. Waiting lists formed in areas where Picnic had not yet launched. For a period, this created a kind of organic demand signal and brand energy.

"Wherever we start, we want to provide the best service. And the best service can only be provided if every element of the supply chain plays perfectly together," he says. In such an integrated system, growth is limited by the slowest-moving part. "If there is one component that can grow only 5%, then you can grow in total only 5%." Constraining geographic expansion to a manageable area kept that dependency challenge tractable.

The same controlled scaling approach he applied also to the technology stack itself. In the very early days, Picnic's supply chain systems were third-party powered. The consumer-facing app was the primary focus, since proof of demand had to come first.

Once we had clearly demonstrated that people actually wanted to use the service, we started to replace external systems with our own proprietary ones. "We were already operating for two, three years. So we knew a lot about those systems, because we had used them. We knew which processes to automate and robotize, but also which pitfalls to avoid."

Separate brand from capability

With 400 engineers today, Picnic looks like a technology organisation from the inside. From the outside, as a company that delivers groceries in branded electric vehicles. Gebler has built this separation on purpose.

"Since the early days, we have deliberately built two distinct but complementary brands: a strong consumer brand as an online supermarket, and a compelling employer brand as a tech scale-up. We attract talent from around the world - people who are driven to push the boundaries of robotics and AI, and who want to be at the forefront of applying technology for good in the food industry. "

Internally, the company always understood itself as a tech-driven innovator. The analogy Gebler gives is Uber, a company that disrupted the taxi industry and whose technology credentials were not immediately obvious to outsiders, but which was built from the start on the assumption that engineering would be its primary differentiator.

For Picnic, that technical edge was developed in phases. The app came first, built to a high standard in the earliest days. Route planning and last-mile logistics came next. Robotic fulfillment and warehousing followed. Now, Gebler describes a fourth phase: "Everything gets lifted to an autonomous AI-powered integrated ecosystem that we are building, which is kind of the grocery logistical platform of the next generation."

Retaining engineers across that kind of multi-year, multi-phase journey requires more than competitive pay. Gebler identifies two things engineers consistently look for: meaning and challenge.

"Engineers look for meaning. You need to work on something that has some form of meaning, contributes in a meaningful way to the world, and is also something they can be proud of." On that front, Picnic's role in reducing food waste provides a clear answer. But Gebler is also clear about their ambition: "We are just getting started and there is so much more ahead of us and we are still in the early days of our journey."

Tooling for the future

The frontier that excites him most is the convergence of AI with physical infrastructure. "What I find especially interesting is how physical infrastructure, physical robotics, and AI is actually merging together and provides an entire new frontier of innovation." He sees the current wave of large language models and AI assistants as impressive, but as a preview of something far larger.

"There's another 10 or 100x transformation coming if that kind of technology is really touching in the physical world. So far it has only touched the digital world."

For Gebler, this transformation promises to solve one of the core difficulties of running a company like Picnic: scaling. Currently, the challenge is anticipating and positioning inventory before demand has even materialised: effectively pre-orchestrating the warehouse. "Instead of reacting to orders," Gebler explains, "we predict micro-demand patterns – down to neighborhood and time-of-day – and use that to proactively move goods within the fulfillment center and even across locations."

The difficulty lies in calibration: moving inventory too early or too often creates its own inefficiency. "Solving that trade-off in real time, with AI directly steering physical inventory flows, is where we're pushing the boundary today." It is the kind of problem that only a decade of integrated, owned infrastructure makes you ready to solve.

Picnic and Gebler’s story is ultimately a study in playing the long game: building a company that owns its technology, tightly integrates every layer of its operations, and anchors its advantage in a business deeply embedded in the real world.

Let's talk

Have a question or looking to get involved? Reach out to our founder, Valentina Colombo. Whether you’re curious about joining the CTO Connect community, our 2026 event program, or exploring partnership opportunities—we’re always up for a chat.