Imagine a collectible-toy CIO whose network has grown from twenty to one hundred stores and from two IPs to more than a dozen. Stores increasingly report stock differences—not simply in overall totals, but after unpacking. A carton becomes individual boxes without a corresponding unit conversion. Rare variants, store shelves, back rooms and transfers develop competing balances. New releases add pre-orders, limits and allocations, leaving headquarters to reconcile spreadsheets to determine what is actually available.
The technology team may conclude that generic retail software is inadequate and an in-house system is needed. Before making that decision, ask whether the difficult requirements are common to the industry or distinctive sources of competitive advantage.
1. Industry complexity alone does not justify an in-house build
One IP can contain several series with regular, rare and limited variants. Products may arrive by carton, be unpacked into boxes and sell in smaller units. Releases may require pre-sales, limits and store allocation. A model focused only on a single SKU balance may not represent those movements adequately.
The issues are real: conversion records, traceability before and after unpacking, transferred units and the relationship between pre-order commitments and store availability. But complexity does not mean every brand must develop its own answer.
Unpacking, rarity, multi-level units, pre-orders and limits recur across brands and can become specialist product capabilities. Brands retain responsibility for product strategy, IP development and customer relationships. Distinctive collection mechanics, collaboration entitlements or proprietary blind-box probability logic may justify internal development when market products cannot support them. Rebuilding mature product, inventory, sales and basic loyalty functions deserves a different cost assessment.
2. Calculate the cost of continued change
The initial build budget—product management, engineering, testing and implementation—is only part of ownership. IPs, packaging, stores, franchising, channels, payment methods and loyalty mechanics continue to change after launch.
Each release rule may affect products, stock, orders and loyalty. Each channel may alter prices, reservations and settlement. Staff turnover adds maintenance and knowledge-transfer costs. Assess the next three to five years: how often will requirements change, and who will design, develop, test and operate each change?
| Cost area | In-house | Specialist software |
|---|---|---|
| Initial investment | Product, engineering and testing | Purchase, implementation, configuration and interfaces |
| Iteration | Continuing internal product and engineering capacity | Supplier product evolution plus brand-specific configuration and integration |
| Operations and upgrades | Internal responsibility for runtime, maintenance, versions and skills | Responsibilities allocated by agreement |
| Integration | Build and maintain ERP, WMS and OMS interfaces | Evaluate existing connectors, openness and actual integration cost |
| Long-term exposure | Continuing product and engineering obligations | Purchase, implementation, customisation and upgrade lifecycle cost |
A supplier serving several brands can turn recurring project requirements into configuration and standard products. That benefit is not automatic. Ask where past work now resides. If every customer has an independently modified codebase, custom maintenance can eliminate the expected economies of a common product.
3. Buying software still requires scrutiny of “we can do that”
A complete demonstration of products, POS, stock, loyalty, promotions and orders does not show how collectible-specific requirements work. If every question about unpacking, rare variants and reserved inventory receives “we can customise it,” establish how much of the industry model already exists.
| Supplier answer | Interpretation |
|---|---|
| Standard functionality | Established product capability |
| Configuration | Supported flexibility within the product |
| Integration | Dependencies, boundaries and connection cost |
| Custom development | Additional delivery and maintenance obligations |
| Unsupported | A business or architecture decision is needed |
A nominally standard product may still become a dedicated system if each client depends on its own custom branch. Ask whether a capability has been delivered before, whether it is now part of the product, and whether the next upgrade requires rebuilding it.
4. Test actual collectible-toy workflows
Generic feature labels offer little distinction. Use the brand’s own data and record prerequisites, steps, expected and actual results, exceptions and implementation category. Begin with the two or three most painful scenarios.
Scenario 1: Receive a carton, unpack, transfer and sell
Unpacking happens in stores, often beside checkout. Test a carton containing twelve boxes. Receive it, unpack through store POS, transfer six boxes through dispatch, transit and receipt, sell two at the receiving store and count stock.
Check whether staff can unpack directly at POS; whether the carton deduction and box increase share an auditable document; how partial unpacking is recorded; whether transfer states remain distinct; and whether the final sale and count reconcile. Every step should be traceable backwards.
Warning signs include manual balance changes without a transaction, transfers that lose required item detail, or a back-office-only unpacking process requiring headquarters intervention.
Scenario 2: Confirm actual variants after opening
A system cannot know whether a sealed blind box contains a regular or rare variant without physical confirmation. The test is what happens after staff open and identify it.
Use a series with twelve regular designs and one rare design. Simulate scanning opened boxes and identifying one rare variant, then sell, transfer and count it. Check an independently traceable variant dimension, correct stock allocation after confirmation, retained design detail, headquarters visibility and audited corrections.
A variant existing only in a name or note, manual spreadsheet correction or series-only totals are warning signs.
Scenario 3: Pre-orders, allocations and available stock
Brands may separate online and store stock, share it or delegate availability to OMS or an inventory platform. Test the brand’s own model rather than assuming one answer.
Configure a release with pre-order commitments and store availability, plus allocation by store tier or historical performance if that is the actual rule. Run simultaneous online reservations and store sales, then cancel a pre-order.
Identify the authoritative stock system, distinguish reserved, available and in-transit states, demonstrate allocation, and show where stock locks and releases and how quickly stores see the result. Manual reservation ledgers, conflicting channel balances, manually calculated allocations or invisible releases indicate gaps.
Scenario 4: Multiple units and PDQ packaging
Card products may use carton, box, pack and card levels; toys may use PDQ displays, complete sets and individual units. Purchasing and selling units can differ.
Use a real hierarchy through receipt, splitting, store receipt, sale and count. Check where ratios are maintained, how larger units become smaller balances, whether original carton or batch references remain, what the cashier sees and whether headquarters can query suitable units.
Manual conversion, unexplained fractional PDQ balances and cashiers needing to calculate packaging ratios suggest the model is not supporting everyday work.
Scenario 5: Company-owned, franchise and unattended formats
These formats have different requirements. Company-owned stores may need full POS and loyalty; franchisees may need authorised ordering and applicable commercial rules; unattended devices need stock and sales connections.
Configure the same IP product across all three. Run a store sale, an authorised franchise order and a device sale followed by replenishment handling. Inspect shared product and inventory definitions, store-level product and promotion scope, device sales and stock updates, replenishment triggers and consolidated reporting, including separate format comparisons.
Interfaces that never return stock or sales, replenishment dependent entirely on inspections, chat-based rule communication and manually combined reporting are warning signs. Franchise pricing requirements must be established within the brand’s approved scope.
Scenario 6: Turn purchase history into useful IP data
A collector buying three series of one IP and a one-time full-box purchaser may spend similar amounts but have different relationships with the brand.
Simulate Member A buying different series of one IP monthly for three months and Member B making one box purchase. Inspect profiles and ask operations to filter, tag and group by IP.
Check whether purchases retain IP, series and design details; whether collectors can be selected by actual criteria; whether brand rules create explainable preference and collection-depth tags; and whether those tags support differentiated invitations or launch eligibility. Spend-only profiles and unexplained claims of automatic AI preference detection are insufficient.
5. Keep clear boundaries with other systems
Limited releases, lotteries, identity checks, anti-bot controls and reseller risk may span online campaigns and specialist systems. Retail can verify members and orders, handle collection and execute transactions without owning the entire registration, allocation and risk process.
For omnichannel stock, identify the source of truth, availability calculator, reservation point, release owner and synchronisation method. Retail normally records products, stores, stock, transactions and members. Online systems may own campaigns and lotteries; OMS, ERP, WMS or inventory platforms may own routing, supply, warehousing and channel-wide availability.
The exact division varies, but responsibility must be clear. A mature system handles its scope well and collaborates through reliable data models and interfaces.
6. Build and buy can coexist
For industry-wide needs such as unpacking, variants, units, store stock and pre-sales, first assess specialist products that already model them. Internal development becomes more compelling when a distinctive capability affects competitive advantage, market products cannot support it and the brand has the organisation to maintain it.
A proprietary combination of collection mechanics, point redemption and IP collaboration benefits may justify a brand-owned application on top of a retail foundation. Recreating basic POS and inventory is a different proposition.
A balanced architecture uses mature software for common retail facts and open interfaces for distinctive applications. Assess the openness of both data models and APIs.
7. An eight-question selection checklist
| Question | Evidence |
|---|---|
| Is this an industry-wide problem? | Reason to buy first or consider building |
| What does “supported” mean? | Standard, configured, integrated, custom or unsupported |
| How are units modelled? | Actual packaging and sales hierarchy |
| How does unpacking create accurate stock? | Relationships, physical confirmation and traceability |
| How do pre-sales and stores coordinate? | Authority, reservations, releases and boundaries |
| How do formats coordinate? | Organisations, permissions, products, prices and stock |
| Does loyalty data support IP operations? | Detailed purchases, tags and operating rules |
| How will the system change in three years? | Product evolution, custom maintenance, data access and migration |
Frequently asked questions
What makes a specialist collectible-toy system?
Industry requirements such as IP structures, unit conversion, variant handling, releases and fan purchase data must exist in its data model and workflows, not merely as possible future development.
Why does stock become inaccurate after unpacking?
Purchasing, storage and sales units differ. Test receipt, conversion, sale, transfer and count as one continuous chain.
Is unpacking just changing one carton into twelve boxes?
No. Preserve product relationships, stock movements and subsequent sale and transfer references, using the brand’s real model.
How should costs be compared?
Compare at least three years, including internal product, engineering, testing and operations or purchased software implementation, interfaces, customisation and upgrades.
How can product maturity be verified?
Require the five implementation categories and actual tests. If every core workflow needs redevelopment, reassess the supplier’s industry maturity.
Where should ERP, OMS and WMS responsibilities sit?
According to the existing architecture. Clarify stock authority, availability, reservations, fulfilment and synchronisation.
Does buying weaken internal digital capability?
Not necessarily. Open models and interfaces let the brand build IP, segmentation and marketing applications on a standard retail foundation. Closed data and pervasive custom dependence are the risks to examine.
When is an in-house build justified?
When the capability is materially differentiated, strategically valuable, unsupported by available products and backed by a durable product and engineering organisation.
Choose which capabilities the brand should own
The useful distinction is between reusable industry capabilities and proprietary business advantage. Test product maturity, complete workflows, boundaries and future maintenance rather than compare feature counts.
PEKON’s collectible-toy delivery experience covers IP product structures, units and conversion, unpacking, variant management, releases, loyalty and company-owned or franchise formats. The collectible-toy retail solution and related insights provide further detail on that scope.