How I vibe-coded an S&OP app in 30 hours

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 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, Blue Yonder 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.

It is all about AI literacy

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 and to ask hard questions about what genuinely requires a multi-million-EUR implementation versus what could be solved with a smart, purpose-built tool. The organizations that have spent years and fortunes on custom-specific APS configuration deserve better advocates. 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, France; Karlsruhe, Germany; and Berlin, Germany, feeding two European distribution hubs and a portfolio of 10 finished goods across B2C and B2B channels. Smart home hubs, industrial controllers, and 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 on finished product and component level.

Figure 1: The physical structure of the test company ElectroTech.

Figure 2: The Bill of Materials (BOM) of the test company ElectroTech.

I vibe-coded realistic master data, products, resources, routings, suppliers, historical demand, inventory postions, cost rates and structured it into a relational database. This became the foundation on which everything else was built.

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 your GenAI engine 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 Code, describing what I wanted, reviewing what came back, refining. Around 15 to 20 substantive sessions in total.

Learning 1: The result was impressively close to what I had in mind without over-specifying

The demand planning tab should display the statistical forecast, allow the demand planner to update it, track those changes and 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.

Figure 3: Demand Planning tab of the S&OP app showing KPIs, forecast, where to focus (scatter of FC Accuracy over revenue), manual update, and the possibility to enter a normal text to change the forecast.

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.

Figure 4: Supply Planning tab of the S&OP app - first unconstrained view, then optimizing considering constraints and additional capacity.

Learning 2: Domain knowledge is not optional—it makes the solution really cool

“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, etc.

None of that came from random prompting but 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 in the way you would do with traversing MD04s, but meaningful and efficient. GenAI did design a BOM navigator that not only shows the structure, but also KPIs like supplier (in case of sourcing), lead time, inventory, and color coding the reliability of the supplier. I was amazed.

Figure 5: The BOM navigator - expands the BOM and shows relevant KPIs like inventory, reliability of the supplier, and others.

Learning 3: You do not need to specify every single detail—let the GenAI surprise you

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.

Figure 6: The Supplier & Risk tab with correct maritime routes.

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 further adjusted, 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.

Learning 4: Iteration beats specification—in outcome and speed

I did not write a requirements document nor 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 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.

Figure 7: Solving the capacity shortages by adding Saturday, 3rd shift, and bank holidays - including color coding whether it worked or not yet.

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” etc.

Figure 8: Showing the scenarios with impact on cost, inventory and secured margin gives a clear recommendation on what to implement

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.

If you are curious about the test company, ElectroTech Industries, with its full master data, database, routing tables, demand history, and cost structure, I am happy to share it. 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.

Send me an email if you would like to get access, have questions, or want to compare notes on what you are building.

About the author

Knut Alicke is a supply chain expert, keynote speaker, and professor at the University of Cologne, KIT, Karlsruhe, and SKEMA. He is a Partner emeritus at McKinsey & Company and works at the intersection of supply chain strategy, planning systems, and AI.

Reactions, pushback, and war stories from your own planning implementations: knut@alicke–scm.com. Check out www.alicke-scm.com.

SC
MR