Scaling the Fleet: Using Delivery Vans to optimise Software Delivery
This article is the third in our series on digital platforms. Following on from “An analogy for digital platforms” and “Learning to drive digital platforms”, we now look at how platforms—when implemented correctly—can help an organisation optimise software delivery at scale.
In the previous articles, we established an analogy whereby a digital platform is like a delivery van, and the software teams are the drivers, delivering their software (parcels etc). We discussed the importance of learning to drive that van competently and safely. This article looks at why we would want to use a van in the first place, rather than just carrying items by hand or building a custom vehicle for every delivery.
The Reliable Fleet: Delivery Economy
Imagine you have access to a fleet of delivery vans (in this analogy the fleet represents the delivery capabilities of a digital platform). The vans are reliable and have standardised controls, so once you’ve learned how to drive one van, you can drive any of them. Whether you are delivering a single urgent letter or a bunch of boxes, the standardised controls: steering wheel, pedals, gears etc, work in the same way. You’re not swapping from van to scooter to helicopter for each parcel. This provides a significant economy to your deliveries, essentially allowing you to offer a better delivery service.
The Platform Equivalent
The platform equivalent is that once a team has learned how to use and leverage the platform’s capabilities, they can deliver every piece of software in the same way. The more they do it, the better they get at it, and the faster they become. Because the team utilises the same capabilities every time, they end up delivering highly consistent software. This consistency has measurable impact .
Consider a scenario where an engineer joins a new team mid-sprint. Without a platform, they’d spend days understanding bespoke deployment scripts, figuring out where logs live, and learning team-specific conventions. With a platform, they commit code on day one—the CI/CD pipeline, monitoring dashboards, and deployment process are identical to their previous team. What used to take a week now takes an hour.
Or consider the cost of an incident. When every service uses the same observability stack, any engineer can diagnose issues across the estate. There’s no scramble to find “the one person who knows how this service is deployed.” A team that previously spent 4 hours per incident hunting through bespoke logging solutions now resolves issues in 20 minutes using standardised dashboards.
The platform makes several things dramatically easier:
- Discover the organisation: A central catalogue shows what services exist, where they’re running, what they do, how they can be consumed, who owns them.
- Diagnose issues: Engineers don’t need to relearn the deployment architecture for every service they touch.
- Reduce cognitive load: Developers move between teams and are productive immediately because the “vehicle” they use to deliver software is the same.
- Automate operations: Tooling is built once to manage all services, rather than maintaining hundreds of bespoke scripts.
The Dashboard Warning Light
This standardisation proves equally valuable for proactive risk management. Just as a van’s dashboard warns drivers about engine problems or low tyre pressure, a platform can scan the entire software estate and surface security vulnerabilities to teams.
Building vulnerability scanning once and applying it to hundreds of services means the organisation avoids duplicating this effort across every team. More importantly, it eliminates blind spots—every service gets the same level of protection, not just the ones whose teams happen to prioritise security tooling.
When a critical vulnerability emerges (Log4Shell, for example), teams need to know within hours whether they’re exposed. Without a platform, this means manual audits across disparate codebases. With a platform, the answer is already on a dashboard: which services are affected, what versions they’re running, who needs to act.
Emergency Deliveries: Resolving Vulnerabilities
Identifying vulnerabilities is only half the battle—teams must also fix them quickly. In the physical world, when a customer receives a faulty item, the driver loads the replacement into the same van and makes the delivery using the same familiar controls. There’s no scrambling to rent a helicopter or build a custom vehicle for “emergency mode.”
The same principle applies to software. When a critical vulnerability lands on a Friday afternoon, teams need to patch and deploy without introducing new risks. Because they use the platform’s standard deployment pipeline—the same one they use every day—they can move fast with confidence. The CI checks still run. The deployment process is still familiar. The rollback mechanism is still there if needed.
When organisations lack this standardisation, emergency deployments bypass normal processes entirely. Patches get applied manually. Testing gets skipped. And incidents multiply because the “emergency fix” was rushed through an unfamiliar path. Platforms eliminate this trade-off: teams can move urgently and safely because the path is always the same.
Conclusion
The economics of platforms become clearer at scale. A single team might tolerate bespoke deployment scripts and custom monitoring. But multiply that cost across fifty teams—each reinventing the same wheels, each maintaining their own tooling, each creating new risks through inconsistency—and the inefficiency becomes untenable.
Platforms flip this equation through standardisation: Faster onboarding, quicker incident response, simpler operations, fewer blind spots in security etc. More importantly, these benefits compound. Each new service leverages the same capabilities. Each new team member is productive faster. Each vulnerability scan covers more ground.
Just as a delivery company scales by growing its fleet of vehicles, organisations scale software delivery by utilising platform capabilities thoroughly. Teams spend less time on the mechanics of delivery and more time on what they’re delivering—the business value that actually matters.
We’d Love Your Feedback
Does this extension of the analogy resonate with your experience of scaling software delivery? I’d love to hear from you! Feel free to drop me a message and share your thoughts.