This article explains how PlanToIt was architected to operate at the level where inventory decisions actually happen, under real-world volatility and constraints.
As a CTO, I spend most of my time thinking about how systems behave under pressure, not how they behave in calm conditions. Planning systems rarely fail when the environment is stable, the geopolitical climate is calm, and there are no wars, pandemics, or trade wars. However, systems tend to fail when inputs shift faster than the system can respond, or when the assumptions on which they are based break and become irrelevant. The result is that by the time teams have to make a decision, the data is rarely complete, even though action is already overdue.
In the food industry, constraints are not theoretical; they are a reality. In such an environment, theory just adds more flames to the fires everyone is trying to put out. Teams deal with spoilage, locked ordering windows, and substitutions as part of their daily work. When shelf life is short, ordering cycles are fixed, substitutions happen constantly, and customer behavior can shift in the middle of a cycle, teams are already seeing on the ground what reports will confirm only later. This industry makes it one of the clearest examples of an environment where systems are tested under pressure.
The core challenge is not that teams do not have data. What limits them is how planning architectures are designed, and the level at which those systems are expected to operate. The truth is that these systems are not built to operate on a short time horizon when food decisions are made. This is why the same failures repeat across different companies, even when teams are capable, and systems appear sophisticated.
The Operational Reality Systems Must Match
Teams are forced to translate abstract signals into item-level actions when a system is oriented above execution. That translation takes time, hides risk, and often happens after the moment where different decisions could have changed the outcome.
Food decisions are executed at the SKU level. Orders are placed per item, expiration is tracked per item, and substitutions are handled per item. Meaning that when failures occur, they fail per item. When something fails, it is never a category that fails. It is one product, in one location, at one moment in time. If the core problem is obvious, why do systems not function at an item level?
Well, history shows that systems fail when they are designed from abstraction downward rather than from execution upward. Leonardo da Vinci approached architecture by studying where structures actually carried weight and where they failed, not by starting with idealized forms of structures and buildings. He sketched stresses, materials, and joints at the points where collapse would occur. The design followed the failure point, not the other way around.
Many platforms do not operate at that layer. Instead, they aggregate items into categories and plan over longer horizons, because it is easier that way. Engineering a system that way simplifies the engineering complexity and delivers teams cleaner dashboards, which makes forecasting feel stable. In food operations, the impact appears later, after orders are locked, inventory is already moving, and teams no longer have room to change the outcome.
Why Better Accuracy Does Not Fix a System That Is Oriented Wrong
When planning fails, the most common response is to demand greater accuracy, better features, more data sources, or more advanced models. The usual response is to push for higher accuracy by adding more data, which enables the development of new features or more advanced models. Accuracy matters, but it does not resolve the failure mode when the system itself is positioned too far away from execution.
In food operations, timing sets the ceiling on value. Once orders are placed and inventory is moving, higher forecast precision no longer changes the outcome. At that stage, the decision impact has already started to drop because the actions available to the team are shrinking.
This is why systems can look correct and still fail operationally. They can be internally consistent and still be late. They can be statistically improved and still be positioned too far away from the moment decisions are actually made.
The Design Tradeoff Most Systems Make
Most planning architectures make a deliberate tradeoff. They choose aggregation and longer horizons because it simplifies the problem. It reduces the number of signals they must process. It reduces variance. It reduces alert volume. It also reduces the engineering burden of resolving SKU-level messiness, like parallel SKUs, packaging changes, supplier disruptions, and substitution behavior.
Software vendors often treat these tradeoffs as a logical path toward system stability. But in a food environment, risk is a zero-sum game. When a system refuses to handle SKU-level complexity, it forces that burden onto the people executing the work. That hidden tax eventually leaks out of the P&L as physical waste and empty shelves, the direct result of a system that prioritizes clean code over the messy reality of the floor.
When one team says the forecast still looks fine while another is already seeing issues, the gap is rarely about math. It exists because the system is confirming reality after operations are already living it, meaning the system confirms the change after operations have already begun dealing with it.
How We Approached Architecture Differently at PlanToIt
When we designed the core architecture of PlanToIt, we started from a different point. We did not ask how to improve category planning accuracy. We asked where orders are actually placed, and what constraints exist at the moment decisions become irreversible.
SKU level planning is the baseline. Short horizons are the focus. Shelf life, ordering cadence, availability, and substitution behavior are treated as core inputs, not edge cases. Volatility is not smoothed away early because early smoothing removes the first signals teams need in order to act.
This is an architectural position, not a feature choice layered on top of an older system. It shapes how data is modeled, which signals are preserved, and how outputs map into decisions that teams can actually execute.
What This Enables in Practice
When planning operates at the right level and within the right horizon, teams spend less time compensating for system shortcuts. Problems surface earlier, while action still matters, and adjustments to orders or substitutions can still change the outcome.
Over time, this changes the operating posture. Fewer surprises become expensive emergencies. More decisions become controlled interventions. That shift does not come from better explanations or cleaner dashboards. It comes from building a system that lives where the work actually happens.
Closing Perspective
Most planning failures in food are framed as execution or forecasting problems. From an engineering standpoint, they are often system design outcomes. From an engineering perspective, many planning failures are system design outcomes. When systems are built above execution, they tend to confirm change too late, even when forecasts are accurate. If a system is built above execution, it will confirm the change too late, even when it is accurate.
PlanToIt exists because we chose a different orientation. We built for the level and the window where inventory decisions are actually made, before outcomes become irreversible.
For the business context behind these architectural decisions and why the company chose to exist, read the CEO’s perspective published here.