On Build vs Buy in the AI Era: The Doors You Build Yourself
TL;DR
- AI made the first version of almost any web tool cheap, but did nothing about the cost of patching, permissions, and upkeep.
- Every tool a team builds in-house becomes code it has to watch and patch, which makes build vs buy a maintenance and liability decision.
- Edgar Allan recommends building the layer that differentiates you and buying payments, hosting, and authentication from vendors built to carry that risk.
AI Made Building Cheap and Complexity Expensive
Somebody on your team can now build a client portal with logins, a quote builder that takes deposits, or a dashboard that pulls live data from your CRM in an afternoon with AI. That's a huge gift, and I'd never tell a team to stop accepting it. The catch is that the afternoon only buys you the first version. The patching, the permissions, and the edge cases that show up once people depend on the thing all land on whoever built it, for as long as it runs.
This series started with PHP2Shell, the flaw that sent IT teams scrambling in October (Part 1 covers it). The flaw got patched within days, and it left behind a question worth sitting with: every piece of code you run is code somebody has to watch. Part 2 looked at who does that watching on a marketing-run site. This one is about the doors teams now build for themselves, because AI makes it very easy to build a lot of doors in a hurry.
Anything You Build, You Adopt
On a recent Building the Next Web live, I described building in-house as closer to adopting a puppy than purchasing something. The tool comes home with you and stays, and as I put it to Jared and Witt, "puppies pee all over the rugs." Most people love the puppy and still underestimate what it’ll do to your floors.
The math changes once you count the whole life of the thing. A homegrown search tool can look done in a day, and my honest estimate for building one properly is two to three months, followed by managing, upkeeping, and patching it for as long as anyone uses it. Just because you can build something doesn't mean you should, and AI has made that sentence a whole lot more relevant.
A Tool That Looks Finished Can Hide Bugs or Vulnerabilities
We learned this on our own product. Slater Search started as an internal tool, and turning it into something the public could use meant revisiting early decisions on purpose: security, users and permissions, and the parts of the system that barely matter for one internal user and matter enormously at public launch. None of that work showed in the original version, which is exactly why it's so easy to skip.
Our comparison of Webflow and AI-native development describes a sharper version of the same gap. At Ship Studio, malicious code slipped through a developer whose access was compromised by a fake job interview scheme. Claude Code flagged it, but what would have stopped it outright was a process control: branch protections requiring code review before anything reaches the live codebase. Custom builds hand you full control, and full responsibility comes with it.
Rent the Layers That Could Hurt You
Some layers are worth renting from specialists because a mistake turns expensive: payments, hosting, authentication, and the infrastructure underneath them. Jared Malan, Technical Director, was blunt about payments: "You don't want to be maintaining someone's credit card. So you probably want to use something like Stripe."
I think of these as primitives, the well-built pieces you compose with instead of rebuilding. Think Stripe for payments, Okta for logins, and a managed platform like Webflow for hosting, for example. They all carry the liability for their layer, and each has a team watching it that's far larger than anything a marketing department could staff on the side. When the next PHP2Shell-sized flaw lands in one of those layers, the vendor's engineers are the ones up at 2 a.m., not your marketing team of two.
Build the Layer That Makes You Different
The strongest setup is usually a thin custom layer on top of bought pieces. That layer is where your brand lives: the experience, the content model, and the interactions and integrations that make your site feel like nobody else's. It's also where AI-assisted building earns its keep, because the work is specific to you and it sits on foundations someone else is guarding.
Jared called this "a superpower time for those of us who choose to lean into it," and I agree with him. The teams getting the most from AI right now point it at the work only they can do.
Run the Puppy Test Before Anyone Opens a Prompt
Jared's two questions on the live were how critical the service and its data are, and what resources you have to support it. I'd add a third that settles most marketing cases, and together they make a quick check we've started calling the puppy test.
The puppy test is Edgar Allan's three-question check before building anything in-house with AI: how critical is the data it touches, who will maintain it every week, and what breaks when the person who built it leaves.
If any answer lands in the right-hand column, rent that piece and build on top of it. For anything you do build, put branch protections and required code review in front of production before launch day, since that's the control that would have stopped the Ship Studio incident.
How We Draw the Line
This is how we build for clients, and it's why we made Slater and Slater Search: Webflow teams kept rebuilding custom code and site search from scratch, so we turned them into primitives they can build on. If you're weighing what to build and what to rent, let's start a project.
Build the part that makes you different, and rent anything that would make the news if it broke.
FAQ: Build vs Buy Software in the AI Era
Should we build or buy software now that AI makes building so fast?
AI has made the first version of most tools cheap, so the build vs buy decision now turns on who maintains and secures the tool afterward. Build the parts that make your product or brand different, where the work is specific to you. Buy the parts where a mistake becomes a breach, like payments, authentication, and hosting. A thin custom layer on top of bought pieces usually gives you both speed and safety.
What parts of our website stack should we buy instead of build?
Payments, logins and authentication, hosting, and core infrastructure belong with specialists who carry the liability for them. Stripe, Okta, and managed platforms like Webflow each have dedicated teams watching their layer for vulnerabilities. Rebuilding any of them in-house means your team takes on that watching for as long as the tool runs. Spend your build effort on the experience and content model that set you apart.
Is AI-generated code safe to run on our website?
It can be, with the same controls you'd put on any custom code. Require code review and branch protections before changes reach production, and name a person who owns the tool after launch. AI-built tools often look finished before the security, permissions, and edge-case work is done, so ask about that work specifically. The fewer critical systems the code touches, the lower the stakes.
How long does it take to build an internal tool properly?
A working first version can take hours or days with AI. A durable version takes much longer: for something like a site search tool, a realistic estimate is two to three months once you include security, permissions, and edge cases. After that, the tool needs ongoing maintenance and patching for as long as it runs. Count that ongoing cost before comparing it with a subscription.