1
0 Comments

From Single-Source Fragility to Engineered Resilience in Contract Manufacturing

Aerosols are the kind of category that looks simple until it breaks. A can is small. The bill of materials is familiar. Demand signals are readable. Then one supplier slips on quality, one plant loses a safety clearance window, one input becomes constrained, and suddenly the “easy” category starts behaving like a high-stakes system.

That is the gap most organizations still underestimate in 2026: they treat supplier networks like vendor lists, not like engineered architectures. They measure unit cost, then act surprised when availability collapses. They optimize for efficiency, then pay for fragility.

Bhavuk Chawla has spent 16 years across packaging development, contract manufacturing procurement, and supply network leadership, most recently leading North America and global sourcing for aerosols and third-party manufacturing environments. He has operated at the point where procurement stops being a commercial function and becomes a continuity function, a perspective reinforced by his role as a judge with the Business Intelligence Group, where he evaluates operational excellence and innovation across industries.

We sat down with him to discuss what changes when a category is constrained by safety standards, market concentration, and regulation, and why resilience is now something you design deliberately.

Bhavuk, why do contract manufacturing networks that look efficient on paper consistently collapse when variability enters the system?

The operating assumption is outdated. Many networks were built around a quiet belief: the market will always offer enough optionality to correct mistakes. That assumption does not hold in high-constraint categories.

In aerosols, capability is not generic. A supplier is not interchangeable just because it has a plant. You have can-size complexity, formula complexity, safety compliance standards, and constraints around critical inputs. When one incumbent supplier fails, the organization learns an uncomfortable truth: it did not build a network; it built a dependency.

The other failure is that teams treat resilience as a contingency plan. Resilience is not a plan. It is an operating design. If the network cannot absorb variability without emergency behavior, it is not resilient. It is simply lucky.

What signals told you that the issue was no longer supplier performance, but a structurally fragile sourcing model?

It looked like the service was becoming a financial event.

The network had been single-sourced. The incumbent supplier began driving disruptions through quality issues, service failures, and cost increases. That is not just an operations problem. It cascades into lost sales, customer fines, inventory distortion, and internal firefighting that consumes decision capacity.

In that environment, the procurement question stops being “Who gives the best rate?” and becomes “How do I prevent a category from being held hostage by a single point of failure?”

Before expanding the supplier base, what had to change in how the organization understood risk, capability, and dependency?

Diagnosis, not negotiation.

The mistake teams make is jumping straight to supplier replacement as if the market is a simple swap. I started with a structured understanding of the portfolio: formats, can sizes, formulas, volumes, and where complexity was self-inflicted versus structurally unavoidable.

From there, the work became sequential. First, identify the realistic universe of suppliers. Then, validate capability through procurement-led visits, followed by deeper technical sign-off with R&D and quality. Only after that do RFIs and RFPs become meaningful, because now you are asking the market questions that map to risk, not just price.

This is where many transformation programs fail: they run an RFP before they understand what “capable” means in the category.

How did you balance cost goals against service recovery and compliance constraints?

By treating cost as one output of a designed system, not the starting input.

I ran benchmarking and should-cost modelling for conversion costs, then compared supplier economics across materials and formats. That work was grounded in the same analytical discipline I apply in my editorial role with the Sarcouncil Journal of Economics and Business Management, where methodological rigor matters more than headline numbers. I did not treat the cheapest bid as the best outcome, instead, I treated it as one data point in a broader network design problem.

On the compliance side, aerosols do not allow improvisation. New partners had to meet stringent safety standards and internal compliance requirements before scale could be responsibly assigned. That qualification work is slow if you treat it as paperwork. It becomes manageable when you stage onboarding, prioritize critical packs and build redundancy format by format.

On cost, I used scenario analysis to create negotiation leverage without relying on threats. Directed-buy clauses, price-matching requirements and structured renegotiation triggers created durable competitiveness without destabilizing supply.

Which constraints forced you to accept that resilience had to be engineered, not negotiated?

Market structure and regulation.

Some inputs are constrained by concentration. Some constraints are created by policy direction and enforcement. Teams can debate the politics, but the procurement job is to operate inside the constraints. In categories adjacent to climate regulation pressure, you cannot pretend tomorrow will look like yesterday. The AIM Act framework, for example, is explicitly built around stepwise reduction mechanics that narrow flexibility over time, consistent with the Kigali alignment direction.

That does not mean panic. It means you design supply with an expectation of tightening constraints: multiple qualified partners, backup formats, alternative sourcing pathways where feasible, and contract terms that preserve optionality.

When resilience is treated as architecture rather than contingency, what changes first: service behavior, economics, or decision confidence?

When resilience is treated as architecture rather than contingency, the first thing that changes is decision confidence. Behavior and economics follow.

In this case, the shift showed up across all three, but not all at once.

Service performance moved from breakdown tolerance to reliability by design. Delivery rates improved by 40%, eliminating a pattern of lost sales and customer penalties that had quietly become “normal.” What looked like execution failure was, in hindsight, structural fragility.

Resilience itself moved from effectively zero to near-complete coverage. Backup capacity was no longer hypothetical or heroic; it was embedded through a multi-partner network that assumed disruption as a baseline condition, not an exception.

The economic impact came last, but it was the most durable. Cost improvements didn’t come from squeezing vendors or cutting corners. They came from structural moves: conversion cost reductions, material sourcing shifts, and smarter input strategies that together surfaced multi-million-dollar annual savings. Cash flow resilience also improved, driven by operational design changes tied to service reliability and inventory dynamics.

None of this required perfect forecasts or extraordinary effort. It required treating resilience as something you design into the system, not something you respond to after the fact.

As a peer reviewer for the SARC Journal, my approach to assessing resilience in research is informed by my architectural practice: if it doesn’t change behavior, economics, and confidence under pressure, it isn’t architecture. It’s a contingency plan wearing a better label.

The point isn’t that every program will hit these numbers. The point is simpler and harder to ignore: when resilience is designed, it produces measurable outputs. When it isn’t, failure just gets better at hiding.

As supplier optionality narrows across regulated categories, what must procurement leaders stop optimizing for—and what must they start designing for instead?

That procurement is now an operating system function.

Organizations are moving toward platforms, analytics, and AI-embedded workflows in source-to-pay environments, but those tools only amplify the underlying network design. If the supplier's architecture is fragile, technology will expose it more quickly. If the architecture is resilient, technology will compound it.

The gap to close is straightforward: stop treating suppliers as a list and start treating supply as a system. In constrained categories, continuity is designed. Competitiveness is designed. Availability is designed.
That is where procurement leadership is headed, not as a softer business partner, but as a builder of networks that can hold under pressure.

on January 26, 2026
Trending on Indie Hackers
Agencies charge $5,000 for a 60-second product demo video. I make mine for $0. Here's the exact workflow. User Avatar 83 comments I wasted 6 months building a failed startup. Built TrendyRevenue to validate ideas in 10 seconds. User Avatar 53 comments Your files aren’t messy. They’re just stuck in the wrong system. User Avatar 28 comments Built a tool that finds which Reddit/HN threads are making ChatGPT recommend your competitors User Avatar 26 comments Why Direction Matters More Than Motivation in Exam Preparation User Avatar 14 comments I built a health platform for my family because nobody has a clue what is going on User Avatar 13 comments