Reframing build vs. buy for digital commerce
Build vs. buy isn't a one-time decision -- it's a cycle that repeats with every technology shift. What's different now is that AI has unlocked a category of building that never existed before.
The build-vs-buy conversation comes back every few years. New technology emerges, companies rush to build, then the industry catches up and the thing becomes a "buy." The cycle repeats.
I've lived through several rounds of this. Early ecommerce, you had to build your own site to stay current -- especially as CI/CD practices advanced. Then platforms caught up. Mobile-first had companies going headless; now the platforms offer that too. Recommendations and smart shopping used to be competitive advantages; now they're commoditized features.
I built three PIMs before I found one worth buying. I never want to build another PIM.
The conventional wisdom -- buy what's commoditized, build your differentiator -- is still basically right. But something has shifted, and it's not just that AI makes building faster.
What's actually different now
AI hasn't just changed the economics of building your differentiators. It's unlocked a category of building that was never on the table before: internal tools that help with optimization and automation.
These aren't customer-facing products. They're not competitive differentiators. They're the operational tools that teams always wished they had but could never justify.
In the past, if you had a repetitive operational problem, you had two options: throw bodies at it, or buy a configurable tool and hope someone on your team could get the most out of it. Building custom tooling? That required engineering resources, and engineering was always allocated to customer-facing work. Internal tools lost that prioritization battle every time.
The math has changed. With AI assistance, you can build an internal tool in days that would have taken months. You don't need senior engineers. You don't need deep specialization. Someone who understands the problem can often build the solution.
Two examples
Compliance validation. A compliance scanner flagged 900+ cookies and scripts across a site. Most were false positives -- phantom discoveries that didn't actually execute at runtime. Manually validating each one would have taken days of tedious work.
Instead, we built a tool that crawled the site, captured what actually loaded at runtime, and cross-referenced against the scanner's output. Then we added AI-assisted classification to categorize what remained. The tool reduced days of manual work to hours. A year ago, no one would have funded that build. Now it took a few days.
Order reconciliation. Commerce teams operate across fragmented systems -- orders in one place, fulfillment in another, shipping in a third. When something goes wrong, support teams become human reconciliation engines, manually cross-referencing data to figure out what happened.
We built a tool that pulls from these systems, normalizes the data, and surfaces discrepancies automatically. AI summarizes the state of each order in plain language. The tool exists because we could build it in weeks, not months. Previously, the answer would have been "hire more support staff."
Neither of these tools is a product. Neither is customer-facing. Both solved operational problems that were real but never justified the investment -- until now.
The trap to avoid
The speed at which you can build internal tools is incredible. But there's a trap: confusing what's possible internally with what's appropriate for customers.
Building a tool that runs locally to solve an immediate problem is one thing. Promoting that to a shared internal tool that your team depends on -- something that needs to be maintained, documented, reliable -- multiplies the effort significantly. Making it customer-facing? Multiply again by 10 or 20.
The risk profiles are completely different. Internal tools can be scrappy. Customer-facing products need monitoring, fallbacks, and governance. Teams that blur this line move fast until something breaks publicly.
This is worth its own discussion -- we wrote about it in Internal tools vs production AI.
The configurable tool alternative
Before AI changed the equation, the answer to "we need internal tooling" was usually a flexible platform -- something that let teams automate through configuration rather than code.
These tools work. But they have a hidden cost: someone has to understand both the tool and the business problem deeply. The learning curve can take weeks or months. Finding that person -- or becoming that person -- is harder than it looks.
AI doesn't eliminate this tradeoff entirely, but it shifts the balance. Building something custom is now competitive with learning a complex configurable tool. For some problems, building is faster.
What this means for leaders
If you haven't started your AI journey, the question isn't whether to start. It's why you haven't.
This isn't going to happen overnight. Learning where, what, and how to leverage AI takes time. It's a journey for you and your team -- not a switch you flip.
The first step is simpler than most people think: talk to someone who's using it. Not the vendor pitch. Not the whitepaper. Find someone actually building with AI and ask what they're doing.
What they're doing may not be what you'll do. But hearing real examples -- not marketing materials -- is how you start to understand what's actually possible.
Where this goes
I don't know exactly how this plays out. Maybe the internal tools people are building now become products someone else sells in a few years. Maybe platforms emerge that let you deploy and share these tools more easily. The industry tends to catch up eventually.
What I do know is that we're early. The cycle is starting again, and this time the "build" category isn't just about differentiation. It's about operational capabilities that were never worth building before -- until now.
Techabo helps digital commerce teams figure out where to build, where to buy, and how to start the AI journey. Learn about our approach.