For companies looking to expand their supply chain software, the rise of AI-coded apps has shifted the old buy-versus-build trade-off. Historically, “build” was simply not a realistic option for most small and medium-sized companies: custom software meant a development team, a long project, and a maintenance burden that only large organisations could carry. Using AI to develop working applications in days rather than months has changed that balance.
So the question is no longer whether you can build, but when you should. For which kinds of solutions should you still look to SaaS? And in which situations is an AI-coded app the better option?
With the release of Claude Opus 4.5 in November 2025, AI-assisted software development shifted from a useful helper to something qualitatively different: agents capable of writing complete, high-quality packages of code, while still being orchestrated by a human. Models released since have raised the bar further. The practical effect is that the cost and lead time of custom software have dropped by an order of magnitude.
For supply chain teams, this unlocks something valuable: tailored solutions for the unique and complex problems that are difficult or expensive to solve with off-the-shelf products. Every supply chain has a handful of processes that don’t fit the standard mould, the ones currently held together with spreadsheets, e-mail chains and tribal knowledge. Those are exactly the problems that vendors rarely address well, because they are too specific to build a product around.
But AI-coded apps come with real risks, particularly around testing, security and maintainability. Cheap to build does not mean cheap to own. The rest of this article lays out when each route makes sense, and how to build responsibly when you choose to.
While the technical barriers to developing software have largely disappeared, several factors remain important in successfully launching a fully custom-built, vibe-coded app for Supply Chain without exposing your supply chain to new risks.
Deep domain expertise: Real supply chain knowledge is needed to design the right company-specific logic and process, not just any logic or process. Without the proper logic and process in place, we risk launching applications that degrade our Supply Chain performance instead of improving it.
There are situations where SaaS remains the logical option, and the arguments for it are largely unchanged.
Larger scale (users, locations). The more people and sites that depend on a tool, the more you need robust access control, performance under load, multilingual support and proper release management. Vendors have solved these problems once for hundreds of customers; you would be solving them for one.
Larger breadth of scope. A sophisticated APS suite represents thousands of person-years of accumulated functionality and edge cases. AI can write code quickly, but it cannot
compress the domain learning embedded in a mature product. Broad scope also means broad integration surface, which is where custom builds tend to become brittle.
Criticality of the solution. If the warehouse stops when the software stops, you want a vendor with an SLA, a support desk, disaster recovery and an audit trail. The same applies to anything touching financial reporting, customs, safety or regulatory compliance.
Commodity processes. Where your process is essentially the same as everyone else’s (order-to-cash, carrier booking, EDI with major customers), there is no competitive advantage in building your own. Buy it, configure it, move on.
Ecosystem and standards. Vendors maintain integrations with carriers, marketplaces, customs authorities and ERP systems, and keep them current as those parties change their interfaces. That ongoing maintenance is invisible until you have to do it yourself.
Forces in favour of AI-coded apps
Low scale (limited users, locations). A tool used by five planners at one site has entirely different requirements from one used by five hundred. Many enterprise features become unnecessary overhead, and the per-seat pricing of SaaS often makes small-scale deployments disproportionately expensive.
Limited breadth of scope. A narrow, well-defined problem is the sweet spot for AI-coded software: a single workflow, a clear input and output, a manageable set of business rules. The smaller the scope, the more completely a human can still understand, test and verify what the AI has built.
Uniqueness of the problem. This is the strongest argument. When your problem is genuinely specific to your products, your network or your customers, the SaaS market offers either nothing, an expensive customisation project, or a product that forces you to bend your process to its logic. A custom app lets the software fit the process rather than the other way around.
Speed and reversibility. An AI-coded app can be prototyped in a day and put in front of users the same week. If it turns out the problem was misunderstood, the sunk cost is small. Compare that to a SaaS selection, contracting and implementation cycle that typically runs six to eighteen months.
Filling the gaps around existing systems. Most supply chain software landscapes already have a core ERP or WMS. The pain is usually in the gaps: the reconciliation nobody owns, the report that takes a day to assemble, the exception handling that lives in someone’s inbox. These “edge” solutions are ideal build candidates precisely because they are small, specific and low-risk.
The buy-or-build matrix
The two sets of forces can be bundled into two axes. The vertical axis combines the forces in favour of SaaS: scale, breadth and criticality. The horizontal axis captures the single
strongest force in favour of building: the uniqueness of the problem. Plotting a solution on these two axes gives four quadrants.
Buy or build matrix
Buy and extend by partnership (high scale, high uniqueness). The hard quadrant: a process that is critical and broad, yet does not fit any product on the market. Do not start from a blank page and do not go at it alone. Buy the closest core system, then close the gap in partnership with the vendor or an implementation partner: through configuration, a co-developed extension, or a custom build held to the same standard you would demand from a vendor, with proper testing, security review and named ownership.
Build (low scale, high uniqueness). Narrow, specific problems used by a handful of people at one or two sites. The SaaS market either ignores them or overcharges for them. This is where AI-coded apps deliver the most value at the least risk, and where the build candidates listed above sit.
Keep it simple (low scale, low uniqueness). Small, ordinary problems that need neither a licence nor an app. A well-structured spreadsheet, a standard report from the ERP or an inexpensive off-the-shelf tool is enough. Resist the temptation to build just because building has become easy.
Most solutions do not sit still. A build that succeeds tends to drift upward as more users and sites adopt it; when that happens it has moved into the “buy and extend by partnership” quadrant and should be re-evaluated on those terms.
The matrix gives the overview; these five questions place a specific solution on it:
Questions one and two place the solution on the vertical axis; questions three and four on the horizontal one. Question five is the gate for anything in the two right-hand quadrants. The emerging pattern for most mid-sized companies is not buy or build but buy the core, build the edges: a solid SaaS or ERP backbone for the critical, broad, high-scale processes, surrounded by a portfolio of small, purpose-built apps that address the specific problems the backbone cannot.
AI-coded apps have not made SaaS obsolete. They have made the middle ground viable: problems that were too small or too specific to justify a licence, yet too painful to leave in a spreadsheet. For the supply chain manager, the opportunity lies in that middle ground. Buy what is broad, critical and commoditised. Build what is narrow, unique and yours. And treat the code you build with the same discipline you would expect from any vendor, because from the moment your planners rely on it, you are one.