Picnic builds nearly all of its software in-house — the consumer app, last-mile distribution/routing, driver coaching, and warehouse/fulfillment systems — because these are the systems that differentiate the business. It only buys external software for non-differentiating back-office functions like accounting, where vendor change-request cycles (submit a request, wait weeks, pay, wait months) are too slow to matter competitively.
The underlying principle: build what creates competitive advantage or requires fast iteration; buy what is a solved, undifferentiated commodity where slow vendor cycles are an acceptable cost. See Moat via Proprietary Tooling and Exclusive Relationships for the related idea that proprietary tooling itself can be a moat, and Asset-Light, Just-in-Time Retail Model for the Picnic business model this in-house software has to support.
Picnic builds the app, distribution, and warehouse systems in-house because it sees these as sources of competitive advantage, and buys externally only for non-differentiating back-office functions like accounting — avoiding a purchased system's slow vendor change-request cycle.
That same choice is what creates Picnic's cross-team dependency problem: because nearly everything is developed internally instead of bought, the speed advantage the strategy is protecting is exactly what's put at risk by unmanaged cross-team dependencies between the internal teams. This is why Picnic invests so heavily in Cross-Team Dependency Pre-Alignment Cycle — the alignment overhead is the cost of keeping the build-in-house speed advantage.
Из тем: Transformation in Practice