Perspectives
How to Hear a Supplier's Warning Before It Hits Your Build Plan
By Supply Signal | October 19, 2026 | 6 min read
A part that was safe last quarter can become a program risk before your planning cycle sees it. The supplier moved. The software didn't.
Picture a power MOSFET on one of your programs. Last quarter it was fine. Coverage was green, the supplier confirmed the dates, and nobody on the program had a reason to look at it twice.
Then the supplier says something on its earnings call. Allocation on that product family is tightening. Lead times are moving out. Orders placed inside lead time will not be supported.
A supplier can say this on a call or in a filing before it shows up in a re-quote or a lead-time change. The time between the two is your warning.
If your planning tool only checks coverage against open orders, it did not hear it. It does that check well. It was not built to listen to what a supplier says about its own fab. If the next quarterly risk review is weeks away, the PO can slip before the review happens.
The ticket is slower than the supplier
Every procurement team has a list of risks its tools cannot flag. Country-of-origin exposure after a tariff change. A sole-source part whose supplier was just acquired. A low-cost boot chip that a fab deprioritizes in favor of a higher-margin line. A contract manufacturer that quietly moved your assembly to a second site.
Each one, when it shows up, goes into the same queue. Write it up. Wait for engineering capacity. Build the report. Test it. Roll it out. Often months, if it gets prioritized at all.
Your buyers and planners already know what to watch. Turning "watch this" into something the system does usually takes a software project. By the time the project ships, the supplier has moved again, and the thing you asked for is a report on last quarter's problem.
What an AI software factory changes for a buyer
Your next "watch this" request does not have to wait for a quarter-long software project. A new way of building software could close that delay. The term is "AI software factory". It sounds grander than it is.
Vercel defines it as "a repeatable development system in which agents perform defined work and pass their results through checks and review." The idea is the path from "we need this" to "here is the evidence to accept it", built as a production line instead of a ticket.
One software company, Ona, has run the test in public. It reports taking a note-taking app from a blank start to a live product that ships its own updates in 10 days, with no human-written production code.
People still did real work. They wrote the specifications, set up the automated steps and reviewed what the system sent up to them. In the first three days they worked 8 to 10 hours a day to build the factory itself. Ona's starting point is the one that matters on your side of the desk: writing code with agents has become trivial; the harder question is how to automate the full software lifecycle. Most of the bugs in one feature, Ona reports, came from specifications that were not detailed enough.
Ona built a note-taking app, not a supply chain tool. The test shows that the method can work. It does not show a supply chain result. Another company, Factory, now sells agents that, in its words, "run the full software development lifecycle: triage, planning, execution, review, and release."
For a supply chain team, the request can start from a sentence a buyer already says, rather than "build feature X". An example of such a request:
"Tell us when a component risk becomes important for this program."
That sentence is not enough by itself. Ona's lesson applies: the factory also needs acceptance cases and example parts. In a factory model, the output is a watched condition, tested against those cases, with the evidence kept beside it. The target is days, not a quarter.
What that looks like on your side of the desk
You never see the factory. Judge it by what comes out. A good one gives you:
- A path from statement to part. A supplier says allocation is tightening on a product family. The statement is matched to the parts you buy from that family, with the call, the date and the wording beside it. Your team should see it before the supplier re-quotes.
- Speed you can measure. A newly named risk should become a watched condition in days, not after a release cycle. Ask your vendor for their number.
- A source on every flag. Each flag should carry its source and its date: which call, which filing, which distributor note.
- No silent green. A missing input should show as unknown. Nothing should paint a part green because nobody loaded the data.
- Memory. The second time a risk of the same shape appears, the system should start from what passed and what failed the first time.
- Decisions that stay with your team. A good system shows its reason and leaves the recommendation to your team. Approving a PO change or contacting a supplier stays with the people who own it.
That last rule is deliberate. A system that can build software fast could also be allowed to do too much. The useful version keeps authority where responsibility sits, and makes the boundary visible.
A build system judged by volume tends to optimize for activity: more alerts, more dashboards, more generated code. One judged by the operating objective can decide that no new software is needed. A data source already exists. A workflow only needs to be connected. An existing view needs better evidence, not another screen. Ona makes a related point: "When output gets cheaper, judgment gets more important." Choosing the right thing to produce matters more.
What to check this week
- Pick three supplier statements from last quarter: allocation tightening, lead times moving out, orders inside lead time not supported. For each one, name the parts it touched and whether it should have moved a PO. Then ask whether your tools showed it to anyone.
- List the risks your planning tool cannot flag: country of origin, acquisitions, allocation statements, a fab retiring a line, a second source that routes through the same bottleneck. If the list has more than three items, your tools may be behind your suppliers.
- Write the objective and three past cases it should have caught. "Tell us when X becomes important for program Y" beats "add an alert".
- Ask any vendor the same question: from "we need to watch this" to "it is watched and tested", how many days?
- Audit what reaches the decision owner. Does each flag carry its source and its date? Does a missing input show as unknown?
- Document who approves a supplier contact or a PO change. If a tool can act, know where its authority ends.
The electronics supply chain will not wait for a release cycle. The software should aim to build new watches in days.
What should reach you is earlier visibility, the evidence beside the call, and a decision that is ready when you come back.
The supplier moved. This time the software can too.
Stay ahead of what changes next. Supply Signal Radar is free and weekly: the supplier moves that can reach a build plan, in procurement language. Subscribe to Supply Signal Radar
Sources: Vercel, "What is an AI software factory?"; Ona, "We built a software factory in 10 days. Here's what we learned."; Factory, Software Factory.