Assortment Planning Software: Build Custom or Buy Off the Shelf?
This is one of the categories where the honest answer is usually buy. Under about 60 stores in one format, buy nothing at all: a planner who knows the estate will beat any system.
On this page
This is one of the categories where the honest answer is usually buy. Under about 60 stores in one format, buy nothing at all: a planner who knows the estate will beat any system. Between 60 and roughly 200 doors with a conventional merchandise hierarchy, evaluate Oracle Retail Assortment Planning, Blue Yonder, Nextail or RELEX Solutions properly and budget for a real implementation. The build case only opens above about 200 stores across formats that genuinely differ, and even then it usually turns on two narrow things: whether your attribute taxonomy is a competitive asset, and whether fixture capacity has to be a hard constraint rather than a post plan check. A first release runs $80,000 to $180,000 in 14 to 20 weeks.
When is off the shelf genuinely the right call here?
More often than in most categories we write about, and we would rather say that than sell you something. The packaged products here are serious. Oracle Retail Assortment Planning is deep and suits conventional processes with a standard merchandise hierarchy. Blue Yonder is credible at scale. Nextail handles localised ranging and allocation well in fashion and is a much smaller commitment than a build. RELEX Solutions integrates forecasting and space in a way that fits grocery and high frequency replenishment. First Insight is answering a different question altogether, testing consumer response to new product before you buy it, which for some retailers is worth more than any planning grid.
Below roughly 60 stores in a single format, buy neither a package nor a build. A planner who knows every store will outperform a system at that scale, and the money is better spent on product or on space. The estate is small enough to hold in one person's head, which is exactly the condition under which software adds process rather than judgement.
Between about 60 and 200 doors, or above that with a conventional process, the packaged route usually wins on three year total cost and it wins on time. Evaluate seriously, insist on a proper implementation budget rather than a licence figure, and pick the product that matches your rhythm rather than the demonstration.
What none of them will do is reshape themselves around you. Each expects an attribute model, a clustering approach and a hierarchy in a particular shape, and where yours differs you either reshape the business to fit or extend inside their framework at their pace.
When does a custom build actually pay off?
Build when two or more of these are true. Your attribute taxonomy is genuinely a competitive asset, which is common in specialty retail where merchandising judgement is the business. Your formats differ enough that fixture capacity must be a first class constraint rather than a check run after the plan is built. You already hold clean sales history in a data platform, which removes the single largest cost from a build. You have implemented a packaged assortment tool and abandoned it because merchants would not adopt it. Or your category mix spans buying rhythms so different that one vendor model cannot serve both.
The fixture point is the one that produces visible money. The assortment decision is made in options and units while the store operates in facings, linear feet and shelf depth. Plan 18 options for a 4,200 square foot store whose fixture holds 11 facings and seven of them end up in the back room, while a flagship with three bays runs the same 18 and looks thin. Both stores mark down at the end of the season, for opposite reasons, and the post mortem blames allocation. It was a range decided without knowing what those stores physically hold.
The attribute point is quieter and larger. Every meaningful assortment question is an attribute question: are we over indexed in dark neutrals, is there a gap at the opening price point in mid sizes, did sell through vary by sleeve length or by fabric. An item master with a description, a vendor style number and a department code answers none of them. Clustering on demand behaviour, modelling new options against comparable items, and estimating demand transference all rest on a controlled taxonomy applied consistently to several seasons of history. Without it, every model downstream is running on sand.
How do they compare on the things that matter in this industry?
- Clustering. Packaged tools cluster competently. The question is whether the result is operable. Fifty statistically optimal clusters are useless because your buying team cannot manage 50 ranges. Six to twelve stable clusters, with a documented reason each store sits where it does and marginal members flagged, is a tool people use. Ask any vendor how they constrain cluster count, not how they compute it.
- Fixture capacity. The dividing line is whether capacity is a constraint during planning or a validation report afterwards. If a merchant adds an option and the system says what comes out, the line review becomes a trade off rather than a contest of advocacy. That behaviour is what you are actually buying.
- Attribute taxonomy. Every product expects a shape. If yours matches, buy. If your taxonomy is the thing that makes your merchandising judgement work, extending inside someone else's framework at their release cadence is where retailers lose years.
- New item modelling. The items you most need to plan are the ones you have never sold. Picking a like item from memory is a reasonable heuristic executed badly. Attribute weighted comparable selection, with the comparison recorded for later review, is the improvement. Demand transference sits alongside it: a fifth navy option rarely creates demand, it takes it from the other four.
- Downstream handoff. An approved assortment has to become item setup, a buy that respects vendor pack configurations and minimums, an allocation plan and a planogram request. Four spreadsheets to four teams is where plans die. One stamped version generating all four is where the traceability comes from.
- Adoption. The most common failure in this category is not a missing feature, it is merchants who will not use the tool. That risk exists on both routes and it is not a reason to build by itself.
What does total cost of ownership look like at your scale?
A focused first release covering the attribute taxonomy with extraction assistance, multi factor store clustering constrained to an operable count, and option and depth planning against fixture capacity for one or two categories runs $80,000 to $180,000 and ships in 14 to 20 weeks in Digital Heroes delivery experience. A full platform adding new item modelling with transference, store level localisation, vendor pack and minimum handling and generated downstream handoffs runs $220,000 to $500,000 phased over 8 to 14 months.
A worked case: a specialty retailer with roughly 340 stores across three formats, two categories in release one, sales history already in a data warehouse, planogram data in a space planning system. Discovery and taxonomy definition, attribute extraction with a merchant review queue, retro tagging three seasons, clustering, fixture capacity mapping and capacity constrained option planning come to about $150,000 over 18 weeks. Extraction and retro tagging alone are $46,000 of that, and they are the two lines to defend when the budget conversation tightens.
Category count drives the number, not store count, and merchant availability during line review season is the real schedule constraint.
Ongoing, budget 15 to 20 percent of build cost annually for hosting, support, taxonomy curation and extraction model refresh, before any new category. Taxonomy maintenance is the line retailers forget: a controlled vocabulary nobody curates drifts back into free text within two seasons, and the models built on it degrade quietly rather than failing visibly. Fixture data currency is an operational cost that decides whether the capacity constraint stays true after refits.
Compare three years of that against three years of the packaged route, counted properly: licence, implementation and configuration, plus the internal effort spent reshaping your hierarchy and attribute model to match what the product expects. That last line is real and rarely invoiced. If your process is broadly conventional, the packaged route usually wins that comparison, and you should take it.
What does the hybrid look like, and when is it the honest answer?
The hybrid here is unusually clean, and for retailers between about 200 and 400 doors it is often the best value in the category.
Buy the planning platform. Build the two things the platform will not do well for you: the attribute layer and the capacity feed. Concretely that means a controlled taxonomy per category, attribute extraction from product copy, vendor specification sheets and images with confidence scoring and a merchant review queue, retro tagging of three seasons of history, and fixture capacity ingested and mapped from your space planning system at cluster level. In the worked example those four lines came to roughly $85,000.
What you get is a packaged tool fed with data it could never have assembled itself, which is where most implementations of these products actually fail. No vendor's product arrives knowing that your small format fixture holds 11 facings, or that your history from three seasons ago was described in free text a merchant wrote by hand.
Three seasons is generally the right depth for retro tagging rather than everything you hold. It is enough to cluster on demand behaviour and to build comparable item sets, and each additional season costs real merchant review time for diminishing return.
The hybrid stops being right when merchants have already rejected a packaged tool on workflow grounds. Better data will not fix a screen they will not open, and at that point the adoption problem is the project.
Which should you choose, by operator size and stage?
Under 60 stores, one format: neither. Spend it on product or space and let a planner who knows the estate do the work.
Sixty to 200 stores, conventional hierarchy: buy. Match the product to your rhythm rather than to the demonstration. Nextail if the pain is fashion localisation and allocation together. RELEX if you are grocery or high frequency replenishment. Oracle Retail Assortment Planning or Blue Yonder if the process is conventional and you can fund a real implementation. First Insight if your actual question is which new products to buy at all rather than how to range what you have bought.
Two hundred to 400 stores across formats that genuinely differ: hybrid. Buy the platform, build the attribute layer and the capacity feed at roughly $60,000 to $90,000, and run cluster level planning for a season before anyone mentions store level localisation.
Above 400 stores, multiple categories with different buying rhythms, or a packaged tool already abandoned: the first release build at $80,000 to $180,000 is defensible, with the full platform following in phases. Sequence new item modelling after a season of live clustering, localisation after that, and downstream generation last.
The signal that you have crossed the line is specific and worth watching for. If post season reviews keep finding the same stores marked down for opposite reasons, some carrying options the fixture never held and others left thin, your clustering does not reflect reality and no amount of allocation tuning will fix it.
When the shortlist is down to two and you need a tiebreaker, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- McKinsey reports that autonomous supply-chain planning can raise revenue up to 4%, reduce inventory up to 20%, and cut supply-chain costs up to 10% while maintaining service levels (the wider 20-30% inventory-reduction figure comes from McKinsey's separate distribution-operations research, not this page). Source: McKinsey & Company (2020) →
- Inventory carrying cost commonly runs about 20% to 30% of inventory value, covering capital cost, storage/warehousing, insurance, taxes, handling, shrinkage, and obsolescence - a recurring cost that better inventory and warehouse software aims to reduce. Source: APQC (2023) →
- Retailers connecting point-of-sale and loyalty data in an omnichannel strategy reported up to 15% lower cost per purchase and nearly 20% higher incremental store revenue. Source: Deloitte (2024) →
- The 2024 DORA report found AI adoption significantly increases individual productivity, flow, and job satisfaction, but negatively impacts software delivery throughput and stability - a paradox leaders must manage with fundamentals like smaller batch sizes and robust testing. Source: DORA / Google Cloud (2024) →
Frequently asked questions
What does it cost to switch off Oracle or Blue Yonder later?
The licence exit is a contract question. The expensive part is that your attribute model, cluster definitions and planning history were shaped to fit that product, and the shape does not always survive the move.
Protect against it by holding the taxonomy, the tagged history and the fixture capacity mapping in your own data platform and feeding the tool from there, rather than maintaining them inside it. That is the hybrid, and its main long term benefit is that switching becomes a change of planning grid rather than a rebuild of everything underneath.
What if our vendor changes pricing or bundles assortment into a wider suite?
Assortment tools are frequently sold as one module of a merchandising suite, so the realistic risk is not a line item rise but a repackaging that pushes you toward buying more of the suite. Price that scenario at renewal rather than reacting to it.
Your bargaining power comes from how portable your inputs are. If the taxonomy, tagged history and capacity data live in your warehouse, you can credibly evaluate an alternative. If they live inside the vendor's model, the evaluation is theoretical and both sides know it.
How long before the first range decision comes out of a build?
Fourteen to 20 weeks for one or two categories. The schedule risk is merchant availability rather than engineering, because controlled attribute values have to be defined by people who know the category and those people are least available during line review.
Plan discovery around your buying calendar rather than your delivery calendar, and run history normalisation in parallel. Retro tagging three seasons is review bound, not engineering bound, so it paces to how much merchant time you can protect each week.
Is Nextail a real alternative to building for a fashion retailer?
For localised ranging and allocation together, yes, and it is a considerably smaller commitment. It solves a well defined slice quickly, which is worth more than a broader tool you implement for a year.
Where it will not substitute for a build is if your attribute taxonomy is the asset, or if your formats differ enough that fixture capacity has to constrain the plan rather than validate it afterwards. Test both in the evaluation with your own data rather than a sample set, because that is where the fit or the gap shows.
Can we keep our planning tool and only build the data layer underneath it?
Yes, and for retailers between roughly 200 and 400 doors this is usually the best value available. You build the controlled taxonomy, attribute extraction with a merchant review queue, retro tagging of three seasons, and fixture capacity mapped from the space planning system, then feed the packaged tool from that.
In the worked example those four lines came to about $85,000 against a $150,000 first release. The requirement is that your planning tool can accept attribute and capacity data through an interface or a scheduled load rather than only through its own screens.
Can artificial intelligence reduce the attribute tagging cost?
Yes, and it is the strongest application in this category. A model proposes values against your controlled taxonomy from product copy, vendor specification sheets and images, with a confidence score and a merchant review queue, converting a manual project that is out of date before it finishes into a review workflow.
It does not remove the merchant. Treat any claim of full automation sceptically, because a wrongly tagged history is worse than an untagged one: it produces confident clustering and comparable item selection that are quietly wrong.
Should store level localisation be in the first release?
No. Run cluster level planning for a season first. Localisation multiplies computation and, more importantly, the volume of decisions somebody has to review, and per store recommendations nobody checks are an expensive way to be ignored.
It typically costs $50,000 to $120,000 as a later phase. Deferring it is the correct order rather than a compromise, because localisation built on clusters your merchants do not yet trust inherits that distrust.
Who owns the code and the attribute model if an agency builds it?
You should own the repository, the cloud accounts and any models trained on your product data and images, agreed in writing before kickoff. At Digital Heroes the client owns all of it from the first commit.
The model point matters more here than the code. An extraction model trained on your own assortment history and imagery is a merchandising asset built from data only you hold, and it is exactly the thing that should never sit in someone else's account under someone else's retention terms.
How much does custom inventory management software cost for a small business?
A single-location system with receiving, stock movements, and barcode scanning typically runs $15,000 to $40,000, based on Digital Heroes delivery experience across 2,000+ projects. Multi-warehouse, multi-channel builds land between $40,000 and $120,000, and manufacturing or forecasting features push past that. The biggest cost driver is logic rather than screens: lot tracking, unit conversions, and channel sync each add real engineering time.
What's a realistic timeline for building a custom inventory system?
A usable first version covering receiving, stock movements, scanning, and low-stock alerts ships in 8 to 12 weeks across Digital Heroes inventory builds. Full multi-warehouse systems with Shopify, Amazon, and accounting integrations run 4 to 6 months. Any quote under 6 weeks usually means the vendor has not scoped concurrency handling or data migration.
How does custom software stop us overselling across multiple sales channels?
By keeping one authoritative count per SKU and recording every change as an atomic movement, so two orders can never both claim the last unit. Channel integrations sync through a queue with idempotency checks, meaning a webhook that fires twice does not subtract stock twice. Ask any vendor to demonstrate concurrent orders against a single unit of stock; naive builds and generic connectors both fail that test.
How do I vet a software agency for an inventory project specifically?
Ask three technical questions before discussing price: how they stop two simultaneous orders claiming the same last unit, whether stock is stored as an append-only movement ledger or a single overwritable quantity field, and how they test channel sync under load before launch. A team that answers fluently has built inventory systems before; one that steers the conversation to screens and design has not. Then ask for a reference from a client whose system has survived at least one peak season.
We already use Fishbowl. When does replacing it with custom software make sense?
Replace Fishbowl when you are paying for workarounds: manual exports to cover missing reports, third-party connectors patching integration gaps, or processes bent to fit its QuickBooks-centric model. Fishbowl remains a solid choice for QuickBooks-linked manufacturing inventory, so if it fits your workflow, keep it. Custom wins when your process is the differentiator, for example serialized rentals, consignment stock, or a picking flow Fishbowl cannot model.
Who owns the code when an agency builds my inventory system?
You should, in full, with intellectual property assignment written into the contract before any payment is made. Insist on the code transferring to a repository you control no later than final payment, plus hosting and domain accounts in your own name. If an agency offers to license you their platform instead of assigning the code, you are buying another Cin7 with fewer features.
Should I hire a freelancer or an agency to build my inventory system?
For a simple single-user stock tracker, a strong freelancer works and costs roughly half as much. Once real revenue flows through the system, choose an agency, because inventory software fails in production rather than in the demo, and a solo developer is a single point of failure during your busiest week. The most expensive engagements Digital Heroes takes on are rescues of freelancer builds after an oversell incident.
What are the biggest mistakes first-time software buyers make?
Choosing the lowest bid, paying more than 30-40% upfront instead of on milestones, skipping a written specification, and having no maintenance plan for after launch. The most expensive of the four in Digital Heroes rescue projects is the missing spec: without written acceptance criteria, done becomes an argument instead of a checklist, and every disagreement resolves in the vendor's favor. Fix those four and you have avoided most of the ways these projects fail.
How many people does it take to build inventory management software?
A typical build runs with 4 to 6 people: a project lead, one or two backend developers, a frontend or mobile developer for the scanning interface, and a QA engineer. The backend carries most of the effort, because stock logic and integrations are where these systems succeed or fail. Be cautious of a one-person team quoting a multi-warehouse, multi-channel build.
What are the most common mistakes companies make on inventory software projects?
Three failures dominate: quoting from a one-line brief so real requirements arrive later as change orders, skipping concurrency testing so the first peak season produces oversells, and going live without running the new system in parallel with the old one. All three are process failures rather than coding failures. A two-week parallel run where both systems track the same stock catches most launch disasters before they cost money.
How do I calculate whether custom software will pay for itself?
Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.
What tech stack should a custom inventory system be built on?
A deliberately boring one: PostgreSQL for the stock ledger, a mainstream backend such as Node.js, Python, or .NET, a web dashboard, and a mobile app or mobile web interface for scanning. The data model matters far more than the language; an append-only movement log with atomic stock updates prevents overselling in any stack. Reject anything exotic that only the original developer can maintain.
Who can build a custom inventory management software system?
Digital Heroes builds custom inventory management software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other inventory management software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Aarav.
Backend Engineer · Delhi · 1 post on the site
Published · Last updated .
