Part 1: The Room Goes Quiet
A few weeks ago I showed a colleague a demo of a supply chain planning application I had built. A sharp, experienced supply chain planner who has been navigating demand forecasting, capacity management, and supplier risk for over a decade. She is exactly the kind of person who should be excited about AI.
"That's cool," she said politely when I opened the app. Then I clicked through the tabs — demand forecasting with manual overrides and natural language input, capacity planning by resource and plant, a bottleneck analysis with cost scenarios, a bill-of-materials navigator, an executive S&OP summary with assessment of three capacity scenarios, a supplier risk map, and more. Her tone changed: "Wait. Did you build this yourself?" When I told her it took about 30 hours, she went quiet for a moment. Then: "I had absolutely no idea this was possible."
That reaction — the quiet before the questions — is something I have now seen several times. In boardrooms, in workshops, in informal conversations with supply chain professionals at every level. And the discussions that follow are always similar:
- But how? I thought you needed a whole development team for something like this.
- We've been using ChatGPT for writing emails. This is... completely different.
- Do we still need that APS implementation we've been scoping for the last 6 months?
- Can I show this to our Head of Supply Chain? To our COO? Today?
The gap between what most people believe AI can do today and what it actually can do is enormous. I am not talking about theoretical futures or research papers. I am talking about right now. A planner with deep domain knowledge can build functional business applications in days, not months. I have to say: this genuinely blew my mind.
I want to be direct about one thing before we go further: the app I built does not replace a full-scale Advanced Planning System (APS). A production-grade SAP IBP, Kinaxis, or o9 implementation comes with years of validated data integration, enterprise-grade scalability, regulatory compliance, and dedicated change management. My 30-hour prototype does not have those things, and it is not trying to.
What I wanted to prove is what happens to the conversation when a supply chain leader or a planner has built something like this, even as a prototype. AI literacy fundamentally changes your ability to challenge software vendors — to ask hard questions about what genuinely requires a multi-million-euro implementation versus what could be solved with a smart, purpose-built tool. The organizations that have spent years and fortunes on custom APS configuration deserve better advocates in those rooms. People who understand what is actually hard — and what is not.
I built the test company in about 10 hours and the app itself in roughly 30 — all through conversation with an AI, no traditional coding. I will go into the full details in Part 3.
Part 2: First, I Needed a Supply Chain to Plan
You cannot build a planning application in a vacuum. You need a supply chain to plan.
So the first thing I did was create a fictional electronics manufacturer I called ElectroTech Industries. This part took around 10 hours. I designed and vibe-coded the structure of the company, including the BOM, historical demand, and full P&L, and validated the consistency in several interactive steps.
ElectroTech operates three plants — near Lyon, Karlsruhe, and Berlin — feeding two European distribution hubs and a portfolio of 10 finished goods across B2C and B2B channels. Smart home hubs, industrial controllers, power management modules. Products with real-world complexity: multi-level bills of materials, shared components, long-lead sub-assemblies, seasonal demand patterns, and spare-parts demand at both finished-product and component level.
I vibe-coded realistic master data — products, resources, routings, suppliers, historical demand, inventory positions, cost rates — and structured it into a relational database. This became the foundation on which everything else was built.
What is S&OP, in plain language?
(For readers already fluent in supply chain, feel free to skip ahead.)
Sales & Operations Planning (S&OP) is the process by which a company aligns what it expects to sell with what it can actually produce and deliver. It brings together demand forecasts from Sales, production capacity from Operations, inventory positions from Supply Chain, and financial targets from Finance — and asks: are we on track? Where are the gaps? What decisions do we need to make?
Done well, S&OP is one of the most valuable processes a company can run. Done poorly — with spreadsheets, disconnected systems, and weekly "alignment" calls that resolve nothing — it is one of the most expensive meetings on the calendar.
The application I built covers the core of it: demand planning, supply planning, capacity management, a cross-functional executive summary, and a set of analytical tools for BOM pegging, supplier risk, and what-if scenarios.
When I showed the experienced planner the app, her first instinct was practical: she started thinking out loud about which of her real planning challenges it could address. The demand override feature — which lets you type a command like "increase all products in the B2C channel in November by 10%" and have the app apply it across the forecast — made her lean forward. "That's exactly the kind of quick adjustment we do every month. Except right now it takes half a day with our mix of Excel, e-mail, and our system."
Then she said something that stayed with me. She realized, watching the app respond to prompts and questions, that interacting with generative AI is not like using a search engine or a reporting tool. It is closer to working with a new colleague who is extremely capable but has just walked in the door. They do not know your company, your terminology, your edge cases, your unwritten rules. You have to onboard them. You have to give context, explain constraints, describe what matters and why — the same mentoring and coaching you would invest in any talented person new to the role. If you just throw a task at it without that investment, you get something generic (or wrong).
"You have to treat it like a smart colleague on their first week, not a search engine, not a calculator."
That is one of the most honest and useful descriptions of working with generative AI I have heard. The organizations getting real value from these tools are the ones treating onboarding seriously.
Part 3: Building the App — What I Actually Learned
The application runs as a Flask web app with a SQLite database and a JavaScript front end. It has eight tabs: Demand Planning, Supply Planning, BOM Navigator, Capacity Solutions, Executive S&OP Summary, Flow Analysis, Suppliers & Risk, Planner Knowledge, and Analytics. I built it almost entirely through conversation with Claude — describing what I wanted, reviewing what came back, refining. Around 15 to 20 substantive sessions in total.
The demand planning tab should display the statistical forecast and allow the demand planner to update it and track those changes, enabling coaching. The visuals created were impressive, and after asking to add a text field to enter the changes in natural language, I was blown away.
The supply planning tab shows the unconstrained and constrained views, helping you understand bottlenecks and solve them. I also brainstormed and implemented a chain of bottleneck resolution paths to define priorities.
"Design an S&OP app" would have given me something. But it would have been a generic dashboard with some charts and a table or two. What made this actually useful was knowing the questions S&OP is trying to answer.
I knew that capacity planning needs to work at the resource level, not just the plant level — that overload scenarios should show not just utilization percentages but the revenue at risk. A planner needs to see whether a Saturday shift or a third shift would actually resolve the overload, and what it would cost. All of these were vibe-coded into the app, with real MRP, capacity planning, pull-forward, and more.
None of that came from random prompting — it came from years of supply chain experience. The AI is a very powerful team of builders that work for you, challenge you, and add meaningful details. The domain expert must always maintain control.
I wanted to be able to navigate the BOM — not the way you would by traversing MD04 screens, but meaningfully and efficiently. GenAI designed a BOM navigator that not only shows the structure, but also KPIs like supplier (in case of sourcing), lead time, inventory, and color coding for supplier reliability. I was amazed.
When I was building the supplier risk map, I asked Claude to "use realistic maritime shipping routes on the map." I did not specify the routes. What came back routed the Lyon plant's sea freight through Marseille, and the Karlsruhe plant's shipments through Rotterdam. Correct, contextually appropriate, completely unprompted. It understood the geography.
When I asked for capacity scenarios covering a Saturday shift and a third shift, I added: "Please consider the additional cost for these options." I did not provide the numbers. The AI researched the relevant shift premium rates — in Germany, the legal Feiertagszuschlag (public-holiday premium) is 100%, and the third-shift night premium is around 25% — and incorporated them into the cost calculations. In a real application, those premiums would need to be checked and maybe adjusted further — but always in conversation with the GenAI, not as code.
The pattern I found: the broader the creative or contextual judgment needed, the more latitude you can give. The more specific the business rule, the more precisely you need to describe it. AI fills the gaps intelligently when the gaps are genuinely a matter of judgment. It cannot fill the gaps when the answer is specific to your company, your contracts, or your legal context.
I did not write a requirements document or a technical specification. I described my ideas, checked what was wrong or missing, and described the next improvement.
The capacity table started as a flat list of 68 rows — one per resource per month. After building it, I could see it was unusable at that scale. So I asked for collapsible grouping by resource. The BOM navigator started without any pegging capability. Once I had the basic tree, I could articulate what was missing: "I want to enter a quantity and a target date and see what I need to order, and by when." The AI created an overview of the pegged quantity, indicating the bottlenecks. You cannot write that requirement clearly until you have seen what it would replace.
This is how experienced planners and supply chain professionals should be thinking about AI-assisted development. You engage in a series of increasingly detailed conversations, each one building on what the last one produced.
The scenario calculation for the exec S&OP meeting
Most S&OP processes I have assessed produce only one solution — preventing trade-off discussion and decision-making in the exec S&OP meeting. We can only accept the solution; rejecting it is not an option. My S&OP app should consider different options. I created an overload and asked for additional capacity to resolve it. The Capacity Solutions tab shows, for every overloaded resource in the planning horizon, four options: Saturday shift, third shift, combined, or working on public holidays. For each option, it shows the added capacity in minutes, the cost in euros, whether it fully resolves the overload, and the resulting new utilization percentage. There is a cost-per-resolved-minute comparison at the bottom and a KPI strip showing total revenue at risk across the planning horizon.
This, along with the overview in the exec S&OP tab, makes a real-scenario discussion possible. I also added a conversational assistant — the chat button in the bottom-right corner — to ask questions like "how much more expensive is the Saturday shift?"
Closing Remarks
I am not arguing that every supply chain team should go build its own planning software. I am arguing that the people who understand supply chains should understand what is now genuinely buildable — and how quickly.
That knowledge changes how you evaluate vendors. It changes how you scope projects. It changes what you ask for and what you are willing to pay for. And occasionally it means that the right answer is to build something targeted and functional yourself, rather than spending 18 months configuring a system designed for the average company rather than yours.
The point is not that you should replace your APS. The point is that, once you have built something real, you will never sit in a vendor meeting the same way again.
If you are curious about the test company, ElectroTech Industries — with its full master data, database, routing tables, demand history, and cost structure — the entire app is now open source. It is a useful sandbox for anyone who wants to experiment with planning applications, AI-assisted analysis, or simply learn what realistic planning data looks like up close. Clone it and it runs: Flask, SQLite, and vanilla JavaScript, no build step, no accounts, no API keys.
Send me an email if you have questions or want to compare notes on what you are building.