Why the "Build" Conversation Sounds Different Today
Control. Fit. Ownership. Those have always been the reasons you think about building your own retail planning system. You want a tool that matches how your planners work. You want to move fast without waiting on a vendor.
Now there's a new reason on the list. AI has made building look cheaper than it used to. A competent engineer with Claude or Copilot can produce in two weeks what used to take three months. A CFO hearing the price tag on software now has an engineer whispering "we could build something ourselves." Some companies have gone further and issued top-down "build before buy" mandates. The result is that the build option is getting a serious look at revenue tiers where it used to be dismissed in the first meeting.
That shift deserves a real response. Here's the honest version. AI genuinely has changed the cost of building a prototype. It has not changed the cost of building what a retail planning system actually is: multi-season history, assortment logic, allocation rules, vendor constraints, markdown optimization, cross-channel visibility. The AI layer is easily accessible. The knowledge layer underneath it isn't.
The time and money you spend getting to that knowledge layer is time and money you don't spend improving forecast accuracy, tightening open-to-buy, or fixing allocation.
Brands and retailers are excited about what they can build. They're largely unaware of what they cannot.
What Brands and Retailers Can Build, and What They Can’t
When a retailer decides to build, the stack is almost always some version of the same thing: an LLM on top of an ERP, with planners working in Excel. Pull data into the warehouse layer, ask the LLM questions against it, manage the actual plan in spreadsheets. On paper, it looks like a planning system. In practice, it misunderstands what a planning system does.
A Planning System is Not a BI Tool
The majority of the work is write-heavy. Planners do more than ask questions of their data; they change it. They're setting next season's buy, reconciling top-down and bottom-up, adjusting receipts by week, pushing allocation to stores. Every one of those is a write operation that has to flow through interconnected logic: open-to-buy limits, vendor minimums, size curves, channel commitments. An LLM can answer a question about a plan. It cannot operate the plan.
A Large Portion of the Data Doesn't Exist Until the System Generates It
Forecasts, open-to-buy, allocations, reconciliations, elasticity curves. These aren't fields you pull from the warehouse. They're outputs of a data model that encodes retail planning logic. An LLM querying a warehouse can describe what's there. It can't produce what isn't.
Insight is a Small Slice of the Value
The core work lives in complex write-back workflows, intelligent forecasting, and supply optimization logic that are genuinely hard to design and operate well. An LLM + ERP + Excel stack can produce useful insight against well-structured data. It does not replace the data model that structures the data in the first place, and it does not replace the workflows that act on it.
This is the gap between what a prototype can demo and what a planning system has to do every week. The prototype answers questions. The system runs your business.
What are the Tangible Opportunity Costs of Building In‑House?
Focus Pulled Off the Core Business
Retail's core is merchandising and sales. Building software is not. Every sprint you run on UI, APIs, and QA is a sprint you're not running on pricing tests, mix strategies, size curves, or location clustering. Leaders feel this when category reviews slip or when next season's buy lacks insight because analysts were debugging.
And the spend doesn't end at launch. A business-critical app needs ongoing care, bug fixes, browser/OS updates, user requests, security patches, and key-person risk compounds. If your lead engineer leaves, velocity can drop for months. AI tooling helps a new engineer get up to speed on the code. It doesn't help them understand why a previous planner overrode a markdown recommendation in Q3 of 2022.
Capital Tied Up in the Wrong Work
Building even a bare-bones custom planning tool usually lands well into high six figures. True enterprise scope pushes into seven figures. And that's before you start adding global scale, advanced AI / ML, and stringent compliance requirements. That spend rarely "just buys a tool." It buys months of engineering attention on internal plumbing instead of margin and revenue.
The Costs You Don't See on Day One
The ongoing cost of owning a planning system in-house compounds quickly. Here's a conservative estimate of what that looks like over five years.
Some of these costs are negotiable with AI assistance. Most aren't. AI helps with code, not with cloud bills, SOC 2 audits, or breach risk.
Bottom line: The "build" path ties up capital, delays impact, and keeps your best people busy on tools instead of outcomes.
"Build vs. Buy": Quick Back‑of‑the‑Envelope Check
Use this quick math to ground the discussion with finance and IT.
- Delay cost: If better planning lifts full‑price sell‑through by 1–2% and trims weeks‑of‑supply by 1–2 weeks, what is that worth this season? Now multiply by 9–18 months if you build.
- People cost: Add 40–80 hours/month of developer time for maintenance. Use fully loaded cost. Add product/design/QA for features.
- Risk cost: Assign a probability‑weighted cost to outage, data errors, and security work. Include key‑person reliance and tech debt.
- TCO: Compare that to a module‑based subscription, including implementation, with upgrades and support included.
Most teams find "buy" wins fast, especially when you need value in‑season.
Why In-House Builds Don’t Hold Up
The long-run reason internal builds struggle isn't about software, but about fit.
It's Not in Most Brands and Retailers' DNA to Build Software
Brands and retailers tend to have small IT teams, stretched thin, with little time to iterate, support, and evolve enterprise software over time. The cost of ongoing ownership gets underestimated at the start of every build, and the pattern is consistent: the first version ships, the engineer who led it moves on or leaves, and the tool becomes a thing nobody wants to touch. You end up maintaining planning infrastructure instead of doing planning. You're now a software company, on top of being a retailer.
A Real Planning System is Genuinely Hard to Replicate
Data-science work is acute and specialized: forecasting, elasticity, tournament models, markdown optimization. The workflows are deep and interconnected, and they encode years of institutional knowledge about how retail planners actually behave. A purpose-built vendor also brings something a single retailer building for themselves structurally cannot: cross-retailer pattern recognition. The domain modeling and best practices that come from planning across dozens of retailers don't exist in any one retailer's data.
Scalability is the piece most builds underestimate. Retail isn't steady state. Seasonal spikes, promotions, and trend-driven surges put real pressure on the system. A stack that works fine in testing stalls when a planner triggers a full reforecast the week before holiday. Allocations lag. Stores get the wrong product. Revenue slips during the weeks that matter most. Engineering around peak load, high availability, and elastic compute is its own discipline, and it's one most internal builds don't budget for until it breaks.
The prototype hides all of these problems. The prototype is the strongest moment the build will ever have. Everything after it is the long tail of edge cases, maintenance, and the slow realization that the team isn't going to get the second version shipped.
Why a Purpose‑Built, Module‑Based Platform Wins
A configurable, cloud planning platform like Toolio solves these problems by design. You adopt the workflows you need, when you need them, starting with Merchandise Financial Planning to set a single top-down plan and OTB discipline, then adding Assortment Planning, Item/Store Planning, and Allocation as they prove value. Each module stands alone but connects to the same data and logic. You configure rules and hierarchies without writing code, and expand on your terms. No big-bang rollout.
Lower Total Cost of Ownership
You pay a subscription, avoid the build cost, the 40 to 80 hours a month of maintenance, and the upgrade treadmill. Updates ship automatically. Support is included. Pricing is predictable and module-based, so you expand when value is proven, without staffing an internal product team to keep the lights on.
Worth noting: AI inference pricing today is heavily subsidized by foundation model providers and is not where it will land long-term. A build sized to current AI costs is sized to a moment, not a market. A purpose-built vendor absorbs that pricing curve so you don't have to budget for it.
Out-of-the-Box Integrations
Modern planning platforms plug into ERP, POS, and e-commerce via APIs and pre-built connectors. Sales, inventory, purchase orders, product attributes, and store data flow in. Metrics align. People trust the numbers. Less time reconciling, more time deciding, and IT handles connections instead of custom rebuilds.
Best-Practice Planning and Ongoing AI Innovation
Templatized retail workflows come built in: top-down to bottom-up reconciliation, open-to-buy, attribute-based assortment, pack/size optimization, item/store plans, and allocation recommendations. You're not re-inventing planning math. You're tuning it. And the AI features that ship with a built-for-retail platform are trained on retail-specific planning logic across many customers, not built by your team from your data alone.
Toolio's Origin Story: A Build-vs-Buy Case Study
Toolio's founders, Eytan and Berk, were developers at Walmart. The planning team lived in Excel. Leadership didn't like the market alternatives, so they built an expensive in-house solution. The gaps never closed. That's what sent Eytan and Berk out to build Toolio.
If the most resource-rich retailer in the world, with the largest engineering org in retail, couldn't make "build" work for merchandise planning, the question worth asking before you start a build is: what's actually different about your situation?
Build vs. Buy: Your Best Path
Building a merchandise planning system in-house sounds strategic. A production planning platform is multi-season history, assortment logic, allocation rules, vendor constraints, and the institutional memory of a planning team that's been tuning it for years. AI makes the first 10% of that problem easier. It doesn't touch the other 90%.
The cost of getting that wrong is time. A year from now, you don't want to be the team that spent the season maintaining a half-built planning tool while competitors ran a real one. You don't want to sit in a vendor demo next spring realizing you're further behind than when the build started, with a roadmap you can't staff and a planning process your team has quietly worked around. That's the downside of the build path.
A module-based, configurable, purpose-built-for-retail platform gets you the opposite: faster value, lower TCO, clean integrations, scale for peak seasons, and AI features already trained on retail-specific logic and shipped to you, not built by you.
If you need planners focused on margin, turn, and growth, not middleware and bug queues, buy the right tool, start with the highest-impact module, and expand. That's how you move faster this season and set up next season to win.
