What software do companies build in-house, and what do they buy? In Alium's verified buyer interviews, it depends heavily on the type of system. Among buyers describing a move between in-house software and a vendor, ecommerce storefronts and email platforms move toward vendors about twice as often as they move in-house. Analytics and modelling capabilities show the opposite pattern: attribution, recommendations, testing and other customer-data tools more often move from vendors to internal solutions, though how strongly varies by category. CRM and order management move both ways about evenly. These are directions among reported moves, not estimates of how many companies run homegrown software, and they do not show whether a particular build performed better.
Which systems do companies build, and which do they buy?
In these interviews, the direction tracks what the system does. Where software runs the business's plumbing, such as the storefront, the email platform, content and product data, buyers are retiring their own builds for vendors. Where software models the company's own data, such as attribution, recommendations, testing and the customer data layer, they are doing the opposite. The systems of record in between, the CRM and order management, move about as often in each direction.
| System | Which way it moves ← to a vendor · in-house → | What buyers cite |
|---|---|---|
| Plumbing and systems of record | ||
| Content and product data CMS, PIM | Toward vendors, mostly |
The headcount to maintain it, and custom builds that never worked well |
| Ecommerce storefront | Toward vendors, about two to one |
Age, a site one person built, the engineering it takes to staff. A few large retailers and brands go the other way, for scale or cost |
| Email platform | Toward vendors, about two to one |
In-house tools outgrown as use cases became enterprise-grade |
| CRM and order management including ERP | Both ways, about evenly |
To vendors: scale. In-house: flexibility a vendor charges extra for |
| Loyalty | Leans in-house, few cases |
In-house: cost, simpler points engines. To vendors: decades-old systems |
| Models and single-feature tools | ||
| Single-feature tools referral, cancellation flows, feeds, cart add-ons | Toward in-house, more than two to one |
Cost and simplicity; in 2026, AI coding tools |
| Attribution and mix models | Toward in-house, about four to one |
Black-box models, cost, and dissatisfaction with past vendors |
| A/B testing | Strongly in-house, among reported moves |
Cost, and testing on first-party data the company already holds |
| Customer data CDP | Strongly in-house, among reported moves |
Cost, and a data warehouse already in place |
| Recommendations, search and personalization | Every reported move went in-house |
Control, per-feature pricing, and in-house models that tested better |
The storefront is the clearest move toward vendors. The homegrown sites being retired were often built by one person: a subscription brand left a commerce platform "designed by one of the co-founders" for a hosted one, and a European scale-up is moving its site off code one engineer maintains. A global prestige beauty group moving off its custom platform puts the case in staffing terms: "It takes off the pressure on our teams to staff all of the engineering behind a custom-built platform." The traffic in the other direction is real but narrow. A few large retailers, marketplaces and brands are replacing an enterprise commerce suite with their own services, for scale, for cost, and for use cases the suite could not handle. For what triggers a commerce move in general, see why brands replatform their ecommerce stack. The CRM and PIM versions of this story have their own pages: why companies switch CRMs and why brands switch PIMs.
The modelling layers run the other way, built by companies with the teams to do it. A department-store chain building its own attribution, a mass retailer moving its product recommendations to its own solution, a streaming service whose engineers think they can build a customer data layer "more powerful and less costly in-house": each has an engineering or data team of its own to build with. The category pages carry the detail. On customer data, see switching off the CDP; on mix models, what MMM buyers wish they'd known; on recommendations, why companies switch personalization engines.
Why do companies move each way?
The reasons split as cleanly as the directions. Toward a vendor, buyers cite age, missing features, maintenance and scale. Toward their own build, cost comes first, then control, then frustration with the vendor they had.
Off a build, the reasons are age and upkeep, and they arrive late. A national department-store chain that replaced its homegrown content system found that "the cost for a license, even sometimes when it's an expensive license is always less" than developing and maintaining the same features. A subscription business ten years into its own stack now sees "the time, energy, and cost of managing and maintaining homegrown software versus transitioning to buying a bit more and letting third parties who handle that specific vertical do that makes a lot more sense." A DTC nutrition brand describes the trap exactly. It built tools in its startup years, lost access to developers as it grew, and replaced them with vendors, even where its own version had been better: "we built this three years ago and it was actually better and we just couldn't maintain it."
Onto a build, the reason is usually cost, then control. A multi-brand retail group leaving a hosted site-search vendor over per-feature pricing decided it "just makes sense to build it internally because then we'd be able to roll out features without going back" to pay for each one. A marketing-services company built its own propensity models because "Outside solutions took longer, were more expensive, and led to that black box feeling when you don't understand how their models are built." A global retailer that evaluated a managed AI search service built its own semantic search instead, and concluded that managed platforms "are not automatically better than well-designed, in-house, domain-specific solutions."
Read side by side, the two lists describe one trade. Our reading, not a buyer's: a vendor's head start is widest on table-stakes features that every company needs, which is the storefront and the email platform. It is narrowest on models of a company's own customers, where the vendor sees less of the data than the company does and the black box costs the most trust.
What did AI change?
What has AI changed about build-or-buy decisions? So far, the discussion more than the number of finished replacements. In 2026 interviews through October, buyers linked AI to a build-or-buy decision about three times as often per interview as in 2025, while build decisions with no AI in them held roughly flat on the same basis. That is a larger role for AI in sourcing discussions, not three times as many internal builds. Buyers describe AI coding tools reducing the time or expertise some projects require, making in-house development a more realistic alternative for software they previously would have bought from vendors; many of those decisions are still evaluations, proposals or work in progress. One ecommerce and digital-strategy director who also runs AI development says, "I've kind of included a build versus buy stage of, is this something I can build? Which was not part of the process a year ago."
AI is touching more build-or-buy decisions than it has finished replacements. The completed ones are mostly contained tools: a small DTC apparel brand replaced a cart-drawer app, a workforce-software company replaced a workflow database with its own AI-built tool, and a jewelry retailer replaced a user-testing product with agents. A DTC accessories brand says, "It's almost like we don't need some of these apps for one single feature." A small manufacturer has rebuilt its CRM with an AI coding tool, so the pattern is not confined to add-ons, while larger efforts are still underway, such as a consumer-hardware company's organization-wide PIM. A luxury fashion retailer shows selective building: it rebuilt most of the commerce extensions it had been buying, but bought its promotions and voucher module because it had too many use cases to build in time. These cases show AI changing which projects buyers think feasible; they do not show the results will be cheaper or easier to maintain over several years. A global beverage company building CRM alternatives in-house rates them highly for their own use cases, but says "they don't have the level of reliability yet" of the platform they supplement. A few buyers say the ability to build is already a bargaining point at renewal.
The counter-current: some buyers say AI favours buying
A large regional bank argues the reverse: "the intensive resources that go into training those models make it much more sensible to be buying those technologies." A marketing analytics director at a data technology company would rather buy a tool "versus us tearing our hair out trying to build our own tool in one of these AI platforms." A digital bank that usually builds its own tools wants to try building its AI tools in-house first, but is blunt about the AI tools it already uses. "Accuracy is a main cause," it says, and on cost, "the rate at which we use tokens, it works out quite expensive."
When does building in-house go wrong?
Explicit reversals are uncommon in these interviews, but that does not establish a low failure rate for internal builds. Only a handful of companies describe giving up on a build and going back to a vendor, and these are documented reversals, not a measured failure rate. A large online retailer was close to signing an SMS vendor, "pivoted to trying to build it ourselves. And after two years of not successfully doing that," signed the contract after all. A consumer electronics brand that dropped its onsite capture vendor brought retargeting in-house, then found that capture "just required more than we could effectively do in-house," and went to a vendor for it. A direct-selling company spent years on a custom sales app ("It was not successful") and is now deciding whether to buy one.
A second risk is harder to see: a build that works at first and then becomes too expensive, fragile or hard to maintain as the company grows. Those cases tend to appear in the interviews as moves away from homegrown systems rather than as failed projects, which is one reason the small number of explicit reversals should not be read as evidence that most internal builds succeed.
Want this checked against your own stack?
Start my checkup →Why do companies that consider building end up buying?
Speed to market, and engineering time. A national retailer's marketing strategy director describes a repeated pattern: "There have been instances where we could have built it in-house, but we could get it live much quicker with a vendor when it comes to channel partners and integrations." A fast-casual restaurant chain whose engineers offered to build its loyalty program turned them down because "the industry is moving too quickly for us to keep up with it." At a consumer fintech, the team that owns internal builds has so many priorities that "it takes them five years to actually build something," so marketing goes to vendors.
The same buyer can hold both views. The CTO of an online specialty retailer says of its homegrown platform, "Your speed to market is much faster" with a vendor for table-stakes features. The same company moved customer service off two vendors onto its own build, because "we can build our own, especially with the AI revolution; we can easily build it." A global CRM operations leader states a rule other buyers echo in their own terms: "Unless it is a core function of what you do as a company, you should buy it rather than build it," because "when you build something on your own, you have to maintain it."
What this means if you are weighing a build
Should a company build or buy its marketing software? The evidence here suggests starting with the type of system, the capability needed and the resources the company can sustain. Companies changing storefronts, email platforms and content systems more often move from homegrown software to vendors, citing maintenance, staffing and keeping up with standard features; companies moving attribution, recommendations, testing and other data-driven capabilities more often bring them in-house, particularly when they already have the data infrastructure and technical team. Those are observed sourcing patterns, not rules.
Our recommendation, drawn from these accounts rather than a practice buyers describe, is to weigh building against buying on four things: how much the capability differentiates the business, the engineering and data expertise available, how fast it has to launch, and the total cost of ownership over several years, including maintenance, security, reliability, integrations, staffing changes and future features, not just vendor fees against the first build. For AI-assisted builds, separate what a prototype shows from what a production system will need; start with contained workflows, and ask for stronger evidence before replacing a critical system of record.
What not to read into this
The ratios on this page compare reported moves between vendor software and internal solutions. They are not adoption rates, market shares or estimates of how many organizations build software: most companies in these interviews described no completed build-or-buy change, and much of the AI-linked discussion is still evaluation or work in progress. The threefold rise in AI-linked build discussion does not measure completed implementations. And the small number of explicit reversals does not establish a low failure rate, since unsuccessful or hard-to-maintain builds may go unreported and many recent projects have not run long enough to show their longer-term costs. These findings describe what buyers report and have decided so far, not which approach will produce better outcomes across the market.
Common questions
Should a company build or buy its marketing software?
In Alium's interviews the answer depends on the layer. Among companies that changed how they source a system, storefronts, email platforms and content systems mostly move off homegrown code and onto vendors. Analytics and modelling layers move the other way: attribution and mix models, recommendations and search, testing and the customer data layer are far more often brought in-house than handed to a vendor. CRM and order management move both ways about evenly. These are directions among reported moves, not shares of all companies.
Why do companies replace homegrown systems with vendor software?
Buyers moving off their own builds most often cite age, missing features, the cost of maintaining the system and the need to scale. Maintenance is the reason that arrives late: a tool built by a small team years ago still needs people to keep it running, and buyers describe losing those people as the business grows.
Are AI coding tools making companies build their own software instead of buying it?
They are changing the conversation faster than the outcome. In 2026 buyers linked AI to a build-or-buy decision about three times as often per interview as in 2025, while build decisions with no AI in them held flat; that measures the discussion, not completed builds. More of those buyers are still weighing a build than have finished one, and the AI-built replacements so far are mostly small tools. Some buyers push back: a regional bank says the cost of training AI models makes buying more sensible, and others name token cost and accuracy.
How often do in-house builds fail and go back to a vendor?
Explicit reversals are uncommon in these interviews, with only a handful of companies describing giving up on a build and returning to a vendor, but that does not establish a low failure rate: builds that become hard to maintain often show up later as ordinary moves to a vendor. The clearest is a DTC supplement brand that dropped an in-house attribution model after about 15 months and went back to the vendor it had used before, while still building its mix model in-house.
Which marketing tools do companies most often build in-house?
Among companies that changed how they source a system, the layers that model a company's own data moved in-house most often: attribution and media mix models, product recommendations and site search, A/B testing, and customer data built on the company's warehouse. Small single-feature tools, such as referral programs, cancellation flows and cart add-ons, are moving in-house too, and in 2026 buyers increasingly credit AI coding tools for those.
Related reading: the great consolidation, on cutting the number of tools; do marketing tools follow people to their next company?; the loyalty platform rebuild, where homegrown programs meet their ceiling; switching off the CDP; what MMM buyers wish they'd known; and why companies switch personalization engines.
Get a checkup on your tech stack
A checkup for your marketing stack, built from hundreds of verified buyer interviews: what matters most to you, a shortlist for your stack, and your next steps.
Start my checkupFree · no password · your answers are anonymized before they inform research like this.