"Can't We Just Build This Ourselves With AI?"
An honest guide to the build-vs-buy decision for ecommerce growth systems: what the data says, where each path fails, and how to de-risk whichever one you choose.
The Short Answer: Yes, You Could
AI tools have collapsed the cost of building software. A capable operator with Claude or ChatGPT can stand up a working prototype of a keyword tool, an ad-spend tracker, or a bundle recommender in a weekend. Anyone who tells you otherwise is selling something.
So "why wouldn't we just build this ourselves?" is the right question, and it deserves a better answer than hand-waving about expertise. The useful answer starts with an uncomfortable fact: most software, bought or built, ends up wasted. The decision that matters isn't build vs. buy. It's how you avoid joining that statistic on either path.
What the Data Says About Unused Software
The waste numbers are remarkably consistent across decades of research, and they cut both ways:
of features in internal software applications are rarely or never used, per the Standish Group's well-known study (45% never, 19% rarely).
Standish Group, via Mountain Goat Software ↗average budget overrun on large IT projects, which also deliver 56% less value than predicted, across 5,400+ projects studied by McKinsey and Oxford.
McKinsey & Company ↗of purchased software licenses go unused; roughly 30% of global SaaS spend is wasted on software that delivers no value.
2025 license management research ↗A caveat worth knowing, because most articles citing that 64% figure skip it: it came from a 2002 study of just four internal applications. Small sample, but that detail is the point. Internal builds, the exact category a DIY growth tool falls into, were where the waste concentrated. Software built in-house without a usage owner is precisely the software that goes unused.
Notice the buy side isn't safe either: half of purchased licenses sit idle. Waste doesn't come from choosing the wrong path. It comes from acquiring software, by any means, without first verifying that someone needs it, will run it, and can measure what it returns. Keep that lens for everything below.
A Prototype Is Not a Production System
A demo has to work once, on a good day, with clean inputs, while someone watches it. A production system has to work on Black Friday, when the API it depends on changes its rate limits, when the catalog has 400 discontinued SKUs, and when nobody has looked at it in three weeks.
The gap between the two is where DIY projects stall. The prototype gets built, everyone's excited, then it meets reality: edge cases, bad data, silent failures, a model deprecation. The person who built it has a real job to get back to. Six months later it's a tab nobody opens, which is exactly how internal tools end up in that 64%.
This isn't a story about incompetence. It's the normal life cycle of software built without an owner, a test plan, and a maintenance design. The failure mode is organizational, not technical, which is why "our team is smart" doesn't protect against it.
The Four Hard Parts
The code is the easy 20%. These four are the other 80%, and they're where systems live or die. They're also where the McKinsey overruns come from: none of them show up in the initial estimate.
1. System design and planning
Before a line of code, someone has to decide what the system should do, what data it needs, what it must never do, and how it fails safely. A bundle-recommendation tool that suggests out-of-stock products, or an ad-spend monitor that takes platform-reported ROAS at face value, is worse than no tool at all. Design mistakes are invisible in a demo and expensive in production.
2. Testing against real data
AI outputs look confident whether they're right or wrong. The only way to know the difference is to test against real order history, real margins, and real seasonality, then keep testing after launch. Edge cases like returns, bundles, gift cards, refunds, and flash sales are where automated decisions quietly go wrong.
3. Choosing tools that survive the churn
The AI tooling landscape turns over every few months. Models get deprecated, APIs change pricing, and yesterday's hot framework gets abandoned. Building on the wrong foundation means a rebuild within a year. Durable systems are designed so components can be swapped without starting over.
4. Keeping it improving over time
A growth system isn't done at launch. Search behavior shifts, ad platforms change their auctions, catalogs evolve. Systems need monitoring, guardrails that catch drift, and a design that gets better with more data instead of quietly rotting. That's an engineering discipline, not a prompt.
Experience matters here in a specific, unglamorous way: someone who has shipped and maintained systems has already paid the tuition on these four. That's the real argument for buying from an experienced builder. Not talent, but scar tissue: knowing what breaks, because it broke before, on someone else's budget.
The Real Build-vs-Buy Math
Side by side, the comparison isn't "free vs. expensive." It's what each path actually costs and where each one's risk hides:
| Building it yourself | Buying from an experienced builder | |
|---|---|---|
| Upfront cost | "Free", plus 3 to 6 months of your best person's time | A fixed one-time build fee, agreed before work starts |
| Time to a working system | Weeks to a demo; months to something trustworthy | Defined scope and timeline |
| Testing | Whatever there's time for | Should be validated against your order history and edge cases before launch. Ask. |
| Risk of building the wrong thing | High. Teams automate what's familiar, not what returns most | Lower, if the builder diagnoses before building. Not all do. |
| Running cost | Vendor costs plus ongoing internal maintenance time | Vendor costs; confirm there's no forced retainer on top |
| When the AI landscape shifts | The rebuild falls on you | Should be designed for component swaps. Ask how. |
The DIY column's biggest line item never appears in a budget: opportunity cost. The 3 to 6 months your best operator spends building and babysitting a tool is 3 to 6 months they're not running the business. And per the McKinsey data, the estimate that made the project look cheap was probably 45% short.
The buy column's biggest risk is buying from someone who builds whatever you ask for. If half of purchased software goes unused, the failure isn't in the purchase, it's in what happened before it: nobody verified the thing was worth owning. Which is what the next section is for.
How to De-Risk Either Path
Whether you build or buy, the waste statistics above have the same antidote: verify before you commit. If you're evaluating any outside builder, these five questions will tell you most of what you need to know:
1. What happens before you build anything?
A credible builder diagnoses first and can tell you the projected return of the system before writing code. If the first step is a contract to build, walk.
2. How will this be tested against my real data?
Get specifics: order history, seasonality, edge cases like returns and out-of-stock items. "We test thoroughly" is not an answer.
3. Who owns the system when you're done?
It should run in your accounts, on infrastructure you control, with documentation your team can follow. If it only works while you pay them, you're renting, not buying.
4. What does it cost to run per month, itemized?
Hosting, AI usage, and tool subscriptions should be small, predictable, and paid directly to the vendors. Vague answers here become surprise invoices later.
5. What happens when a model or API you used gets deprecated?
This will happen within the system's lifetime. The builder should have a concrete answer about component swaps, not reassurance.
If you're building in-house, ask yourself the same five questions. The honest answers usually decide the build-vs-buy question on their own.
When Building It Yourself Is the Right Call
Because the honest answer cuts both ways: sometimes DIY is right.
Build it yourself if you have an engineer with real bandwidth who will own it as a first priority, if the system is internal-only and low-stakes when it fails, or if you're experimenting to learn rather than to run revenue. You'll learn a lot, and the tools have never been better.
But if the system will make or influence decisions that cost money — where to spend, what to rank for, what to offer at checkout — and nobody on your team can own it as a first priority, the data above is a preview of how "we'll build it ourselves" usually ends: a demo in March, a dead tab by September, and the budget overrun nobody wrote down because the currency was your team's time.
Either way, the sequence matters more than the path: diagnose first, verify the return, then build or buy the smallest system that captures it. Software that starts with a verified reason to exist is the software that gets used.