Reality check: this will not replace an ERP. But it is already better than the messy spreadsheets most teams are using to make multi-million-dollar decisions.
What this actually is
Think of this as a flight simulator for manufacturing decisions.
It is an interactive dashboard where a manager can say:
- “Semiconductor costs go up 15%,”
- or “Logistics costs drop 5%,”
- or “We give workers a 5% raise,”
and the system answers:
- How does that hit total gross profit?
- Which products are still safe?
- Which ones just became a problem?
It is built for people like a CFO, COO, or Operations Manager who live in questions like:
- “What happens to our portfolio if input X changes?”
- “Where are we secretly losing money?”
- “Which levers actually move the needle?”
The app turns those into numbers in a few seconds and hands them to an AI that writes a short strategic briefing instead of just leaving you alone with charts.
Why I cared enough to build it
Before this thing existed, the real workflow looked like this:
- Someone says “fuel is going up, what does that mean for us?”
- An unlucky analyst opens three giant spreadsheets:
- one with product recipes (BOM),
- one with labor and overhead,
- one with supplier and logistics costs.
- They change a few cells, hope the formulas do not break, and then:
- give a rough answer for one or two products,
- with zero visibility of the whole portfolio.
It was slow, fragile, and reactive.
It felt more like damage control than decision-making.
I wanted something where you can:
- move a single slider,
- see the portfolio-level impact immediately,
- and then have a decent conversation about strategy instead of babysitting Excel.
That was the itch.
What actually worked
Three parts feel “real” already:
1. The what-if engine
The core P&L simulator is the main win.
Moving a slider like “+15% on semiconductors” and watching the annual impact ripple through the whole product portfolio in real time is the moment where this stops feeling like a toy.
This used to take days of manual spreadsheet work. Now it is a single run.
2. The AI strategist
The AI is not just “ChatGPT stapled onto a dashboard.”
In a semiconductor shock test, it:
- correctly flagged chips as the immediate pain point,
- but recommended focusing on internal machine-time optimization as the highest-leverage move,
- and used the Feasibility scores from the cost table to justify why that was more realistic than trying to “fight the global chip market.”
So it behaves more like a junior consultant who has actually looked at your numbers, not just a summarizer of charts.
3. The portfolio health view
The “Stars” vs “At-Risk” view did something uncomfortable but useful:
- it showed that some high-volume, “successful” products were living on razor-thin margins,
- which makes them huge risk magnets when any cost driver moves.
Those products were technically visible in the old spreadsheets too, but nobody was seeing them clearly.
Now they are highlighted in one screen and force a conversation: raise prices, cut cost, or kill them.
What is still messy (being honest)
This is not production-grade yet. A few big limitations:
-
Static input data
All costs (materials, labor, logistics) live in CSV files.
For day-to-day use, this needs live APIs for:- commodity prices,
- FX rates,
- maybe a freight index.
-
Subjective Feasibility scores
The Feasibility column inmanual_cost_drivers.csvis basically my judgment call.
In a real deployment, those scores would come from workshops and structured input from operations, not “Ben’s vibe on a Sunday.” -
Over-linear world
Right now:- a 10% cost increase → 10% impact in the model.
There is no modeling of: - volume discounts,
- step changes (e.g. needing a new line or a new plant),
- realistic demand elasticity.
- a 10% cost increase → 10% impact in the model.
-
Simplified geography
The current version acts like everything happens in one generic region.
A serious implementation needs:- per-plant / per-region costs,
- taxes,
- tariffs,
- maybe different risk profiles per geography.
So: it is strong as a thinking tool and a portfolio x-ray.
It is not yet a full replacement for a corporate planning system.
What I would do next
If I had another focused sprint, I would prioritize:
-
Live data integration
Replace the staticmanual_cost_drivers.csvwith:- live fuel prices,
- currency rates,
- and at least one external index for logistics.
-
Multi-driver scenarios
Let users stack shocks in one run, for example:+10% Steel,+5% Labor,−3% Logistics, and see how they interact.
-
Monte-Carlo style forecasting
Let the user specify volatility ranges, then run many simulations to produce a distribution of possible outcomes:- best case,
- worst case,
- central band.
-
Interactive AI
Turn the static strategy report into a conversation:- “What is the ROI if we pull the machine-time lever you suggested?”
- “Compare the top three interventions and list pros/cons and implementation difficulty.”
Technical details (for people who care about the plumbing)
-
Tech stack
- Streamlit frontend,
- Pandas for data work,
- Plotly + FPDF2 + Kaleido for visualizations and export,
- OpenAI Chat API (
gpt-3.5-turbo-instruct) for the strategy brief.
-
Data model
bom_products.csv- one row per product,
- components, quantities, price, volume, elasticity, region.
manual_cost_drivers.csv- one row per cost driver,
- rate, unit, region, Feasibility score.
Joins happen in memory. The engine tries to match on
(Component, Region)first, and falls back to(Component, "Default")if needed. -
Engine
-
portfolio_simulator.py- bottom-up cost simulation,
- rolls per-unit costs into product-level and portfolio-level P&L,
- supports price changes and simple demand elasticity in the same run.
-
AI integration:
- persona: “top-tier management consultant,”
- Feasibility passed explicitly so it looks for realistic levers,
- negative instructions like “do not just restate the graphs.”
-
-
Engineering details I like
utils.pyruns validation on startup (duplicate entries, unit mismatches, etc.) so the app fails fast instead of giving wrong numbers quietly.- Core calculation logic lives in
/app/core, separate from the Streamlit UI in/app/main.py, so the “brain” can be tested or reused without the front-end. - OpenAI keys are handled with
st.secretsand only fall back to a manual input if needed, so it is set up with deployment in mind.
If you want to see the raw code or walk through a specific scenario, the repo is linked above. I am happy to talk through what is real, what is hacked, and what I would build next if I had more time.