Build or buy? Choosing software for a fashion business
Custom software promises a perfect fit, standard software promises speed and lower risk. A practical framework for deciding which path suits each part of a fashion business.
KEY TAKEAWAYS Summary by the editors
- Buy software for processes that are common across the industry, and consider building only where a process genuinely differentiates the brand.
- The true cost of custom software is dominated by long-term maintenance, security and staff continuity, not the initial build.
- Standard software requires the organisation to adapt some processes, which is often a benefit rather than a compromise.
- A hybrid model, buying core systems and building thin custom layers through APIs, is the most common outcome for mid-sized brands.
- The decision should be revisited as the market and the brand change, because what was unique a few years ago may now be standard.
A fashion brand's sales director asks for a better way for buyers to place re-orders. The internal developer says it could be built in a few months. A vendor offers a ready-made solution. Both options look plausible, and the decision will shape the business for years. Build versus buy is one of the most consequential technology choices leaders make, and it is rarely as simple as comparing two quotes.
What is really being decided?
Build or buy is shorthand for a range of options. At one end, the brand writes and owns its own software. At the other, it subscribes to a standard product and uses it as delivered. In between sit configurable platforms, custom extensions to standard systems and low-code tools. The real question is how much of a given capability the brand wants to own and maintain itself.
| Option | Fit to process | Speed to value | Long-term effort | Main risk |
|---|---|---|---|---|
| Buy standard | Good for common processes | Fast | Low, vendor maintains | Some process adaptation needed |
| Buy and configure | High within the product's limits | Medium | Moderate | Over-configuration, complex upgrades |
| Buy core, build layers | High where it matters | Medium | Moderate to high | Integration discipline required |
| Build fully | Exact | Slow | High, brand maintains everything | Dependency on a few people, rising cost |
When does buying make more sense?
For most processes in a fashion business, buying is the safer default. Order management, invoicing, warehouse operations, product development workflows and wholesale ordering are broadly similar across brands. Vendors serving many customers can spread development costs, keep up with standards such as EDI or tax rules, and add features informed by the whole industry. Buying is usually right when:
- The process is common across fashion brands and not a source of competitive advantage.
- The brand lacks a stable in-house development team or does not want to build one.
- Speed matters, for example because a new channel must be ready for the next selling period.
- Compliance, security or industry standards are involved and must be kept up to date.
- Several mature products already exist and are used by comparable brands.
When can building be justified?
Building makes sense where a capability is genuinely distinctive and central to how the brand wins. That might be a unique client experience, a proprietary planning method or an unusual business model that standard tools cannot represent. Even then, it rarely means building everything. Typically the brand buys the core systems of record and builds a thin, differentiating layer on top through APIs.
Which hidden costs are often missed?
- Key person risk: custom software often depends on one or two developers. If they leave, knowledge leaves with them.
- Ongoing change: partner formats, operating systems, browsers and regulations change, and every change needs development work.
- Opportunity cost: internal teams maintaining a custom tool are not working on other priorities.
- Over-customisation of bought software: heavily modified standard systems combine the disadvantages of both paths, because upgrades become as hard as maintaining custom code.
- Change management: whichever path is chosen, training and adoption costs are real and often underestimated.
How should leaders make the decision?
A structured approach helps avoid decisions driven by enthusiasm or habit. Start by describing the business outcome rather than the solution, for example faster re-order processing or fewer order errors. Then assess how differentiating the capability is, how mature the vendor market is, and whether the organisation can sustain custom development over time.
It is also worth testing the assumption that the process must stay exactly as it is. Standard software embodies practices proven across many companies. Adapting to them can simplify operations and make onboarding new staff easier. Customisation should be reserved for cases where the difference is valuable to customers or buyers, not just familiar to internal teams.
A useful discipline is to write down, before any decision, what would have to be true for each option to succeed: the team size needed to maintain a custom build, the process changes a standard product would require, the budget over several years. Seeing those conditions side by side often makes the choice clearer than any feature comparison.
Finally, revisit the decision regularly. Capabilities that once required custom development, such as mobile ordering apps or digital showrooms, have become standard offerings. A brand that built a tool years ago may now be paying to maintain something the market provides more reliably. Good technology leadership means knowing not only when to build, but also when to stop.
Frequently asked questions
Is low-code a middle way between building and buying?
It can be, for internal workflows and simple tools. Low-code still creates software the brand must maintain, and it can become hard to manage if many unconnected apps grow without governance.
How do we avoid vendor lock-in when buying?
Check data export options, available APIs and contract terms on data ownership before signing. Keeping master data in systems the brand controls and using documented integrations reduces dependency on any single product.
Who should be involved in a build versus buy decision?
Business owners of the process, IT or digital leadership and finance should all be involved. The business side defines the outcome and how differentiating it is, IT assesses feasibility and maintenance, and finance compares total cost over several years.
One edition every weekday morning. Read in five minutes. Free for industry professionals.
