Summary. Retailers deciding how to deliver store training face two separate build-or-buy questions, and conflating them is the usual mistake. One is about the platform. The other is about the content. The right answer is frequently different for each, and the content decision is the one that determines whether the program works. This paper separates the two, prices the internal build honestly, and gives you the single question that predicts which programs survive their first year.

Two decisions, not one

The platform question: do we use an existing internal system, buy a specialist one, or build something ourselves?

The content question: who writes, shoots and edits the material, and who keeps it current?

Retailers routinely resolve the first and assume the second follows. It does not. A specialist platform with nobody to produce content becomes an empty channel. An internal build with a strong content team can outperform a better platform that nobody is feeding.

Why this category exists at all

The software most organizations own was designed for people at desks. Emergence Capital, in research published in December 2020, put the deskless workforce at more than 2.7 billion people, around 80 percent of workers worldwide, and found that less than 1 percent of software venture funding had gone to companies building technology for them.¹

Those two numbers next to each other explain the state of most retail technology estates. The people who stock, sell, cook, drive and care for others are the majority of the working world, and almost none of the money that built the enterprise software category was aimed at them. What changed is that they now all carry a screen, which is why tools built specifically for this worker became viable at all.

The practical consequence for a retailer is that the systems already on the estate were specified for a different worker. That is not a criticism of those systems. It is the reason the store requirement keeps failing to fit inside them.

The platform decision

Building it yourself is almost always a mistake for this specific category, and the reason is not capability. It is that the hard parts are unglamorous and never finished: offline behavior on weak store connections, shared-device handling, fast user switching, per-person reporting to field hierarchy, multi-language, and content versioning for compliance. None of that is interesting to build and all of it has to keep working.

The honest exception is a retailer with genuinely unusual requirements and a permanent internal product team, who understands they are taking on a maintenance obligation rather than a project.

Using what you already own is the right answer more often than vendors admit, particularly if the requirement is durable, auditable content. If the material is compliance and onboarding, the system you have is probably fit for it. The evidentiary requirements are specific and existing systems are usually built for exactly that.

Buying a specialist tool earns its place when the requirement is timely, product-paced material for people who are standing up. That is a different specification, and it is the one general-purpose systems handle worst. How to tell the difference in a demo is worth its own reading.

What the internal build actually costs

The build case is usually presented as a one-time development number compared against several years of subscription. That comparison is wrong in a specific and predictable way, and it is worth correcting before the decision rather than in year three.

1. Take the development estimate for the first release, as quoted internally.
2. Add the annual run cost. Two operating system releases a year, device fleet changes, security review, penetration testing, accessibility, and the support load from four hundred stores. A defensible planning figure is a meaningful fraction of the original build, every year, forever.
3. Add the roadmap you have not written. The specification that gets built is the one you can imagine today. The requests that arrive in year two, from compliance, from a new market, from a format you have not opened yet, are all development you will have to fund.
4. Add the key-person risk as a cost, not a footnote. Internal builds of this kind typically depend on two or three people. When they move on, you are recruiting for a niche skill set to maintain software with no external community.

Run that and compare the multi-year totals honestly. The build sometimes still wins, and when it does it wins for a real reason, usually an integration or a data-residency constraint that no supplier will meet. What it should not win on is an unadjusted first-year comparison.

The content decision, which matters more

Content is where programs quietly die, and the reason is capacity rather than quality. Here is the test almost nobody applies before signing: who produces the fourth month of content?

Launch content gets made. There is budget, attention, an internal champion and often agency support. Month four has none of those, and month four is when the program either becomes part of how the business runs or becomes a channel with three-month-old material at the top.

Three viable models, and the failure mode of each:

• Internal team produces everything. Fastest turnaround, best brand fluency, and it fails when the person who makes the videos is also the person doing three other jobs. Requires a named role with protected time, not a volunteer.
• Outsourced production. Consistent quality and no capacity cliff, and it fails on speed if every piece needs a brief, a quote and a schedule. Works when there is a standing arrangement rather than project-by-project procurement.
• Hybrid, which is what most successful programs actually are. Outsourced for the flagship material where production values matter, internal for the fast, plain, this-week content. The discipline is agreeing in advance which is which, so nothing waits in the wrong queue.

“We will just use the system we already have”

This is the most common resolution and it is not always wrong. It is worth stress testing rather than dismissing, because when it fails it fails slowly and expensively.

Four questions settle it in an afternoon.

How long from a decision to a store seeing it? If the honest answer is measured in weeks, the system is fine for onboarding and unsuitable for anything on a product calendar.

Who can publish? If the answer is one team, and the material stores need comes from merchandising, visual, operations and loss prevention, then the constraint is a queue rather than a capability. That is a governance question before it is a purchase.

What does it do on a shared device with a weak connection? Try it in a real store on a Saturday, not in the office.

Can a district manager see an individual? Store-level completion is an executive number. Coaching needs names.

If the existing system answers all four acceptably, use it and spend the money on content instead. That is a legitimate and frequently correct outcome, and it is the one a specialist supplier will not volunteer.

What to insist on regardless of model

1. A named content owner with protected hours. Not a committee, and not someone’s twenty percent.
2. A publishing calendar tied to the product calendar, so content is commissioned when the buy is confirmed rather than when the product lands.
3. The ability to change something today. If correcting a wrong answer takes a change request and two weeks, the training will be wrong for two weeks.
4. A retirement rule. Content that nobody opens should come down. Libraries that only grow become unusable, and the unused material makes the current material harder to find.
5. Production standards low enough to sustain. A weekly two-minute piece shot in a real store beats a quarterly polished film, and the floor finds it more credible. The research on how people learn from video supports the simpler version more than most agencies would like.
6. An exit that you have actually read. Whoever owns the platform, you should be able to leave with your content and your engagement history in a usable form.

The question that predicts success

When evaluating any option, ask what happens in month four, and then ask who specifically will be doing it. If the answer names a person and a protected slot in their week, the program will probably work. If it names a department, it probably will not.

The reason this question outperforms every feature comparison is that platforms rarely fail. Programs do, and they fail on the supply of content rather than on the software that carries it.

Where to start

Before evaluating any vendor, write down who will produce content in month four, how many pieces a month, and where those hours come from. If you cannot answer, that is the constraint to solve first, and no platform choice will substitute for it.

Then run the four questions above against the system you already own, because that answer determines whether you are buying a platform or funding a content function. The calculator will model what the resulting capability change is worth on your own numbers.

References

1. Emergence Capital, The State of Technology for the Deskless Workforce, published 15 December 2020: the deskless workforce is “more than 2.7 billion strong and representing 80% of workers worldwide,” and of software venture funding, “less than 1% of it went to companies building technology for deskless workers.” emcap.com