Build vs. buy in the age of AI: lessons from vibe-coding an internal tool

When a product manager can vibe-code a functional prototype in an afternoon, is buying enterprise product management software still worth it? As generative AI tools lower the technical barrier to building software, product teams are facing a fundamental strategic shift. Questions that once had clear answers – such as whether to purchase off-the-shelf software or spend engineering quarters building custom internal tools – are now being reconsidered. 

To get a real answer, rather than a hypothetical one, we talked to Ben Nelson, a Group Product Manager at Lucid Software, who has spent the last few months building and living with a vibe-coded internal tool called Archie: an "Account Research Copilot" for Lucid's sales team.

Here’s the breakdown of why his team chose to build this time, what it's actually cost them, and what he'd tell anyone else standing at the same crossroads.

When the market falls short: the case for building

The decision to build internal software often stems from a simple gap: commercial software failed to meet highly specific organizational needs.

Ben's team sought to empower sales representatives with contextual intelligence by combining internal sales data, product usage metrics housed in Snowflake, and content marketing assets. The goal was to build "Archie" (Account Research Copilot): an AI tool capable of generating tailored meeting prep outlines, highlighting key conversation anchors, and ranking strategic recommendations for client accounts.

Before writing code, Ben evaluated existing market tools such as Gong, MadCudu, and ZoomInfo. None of them was close enough. “We did reject some of those options,” he says. “It all came down to the fact that we knew our data better."

The gap wasn’t simply a feature missing here or there: It was a ceiling on how deeply any off-the-shelf tool could be tailored to Lucid’s specific data and sales narratives.

Building their own solution seemed the right choice, not because it was a fun project to work on, but because there were no tools to meet their needs, and “the benefits outweighed the cost”. 

The unexpected bottlenecks: cost, quality, security, and maintenance

If anyone can vibe-code a tool in a couple of hours and tailor it to a team’s specifics, why not just build every single system?

While Ben Nelson is satisfied with the tool he created himself, he’s also honest about some unpleasant surprises that came with the decision to build rather than buy.

Volatile costs

After dramatically accelerating initial development, AI introduces financial dynamics that differ significantly from standard SaaS pricing models. Fixed subscription fees provide predictable operating expenses. LLM token usage, in contrast, can jump rapidly if unmanaged.

During Archie’s initial 30-person pilot, Ben discovered how quickly token consumption can escalate. “There was a moment we realized we'd spent hundreds of dollars a week on this for a pretty small subset of folks. We had done zero cost optimization up to that point... if we roll this out to the broader org, it would be a significant amount of money." 

To prevent cost overages, Ben had to divert time into active cost optimization, evaluating model tiers (such as Anthropic’s Opus, Sonnet, and Haiku) and exploring alternative LLM providers.

Code quality, security, and the Labrador analogy

Vibe-coding enables non-engineers and product managers to rapidly generate functional software using AI prompts. 

AI has made software development faster than ever. Speed is now guaranteed. The pitfall? LLMs prioritize immediate problem-solving over architectural cleanliness, maintainability, or security best practices.

Ben shares a striking example of this: "We built a bunch of SQL queries that were reviewed by our actual data team. As we added more features, AI added more and more SQL queries... It went from 50 lines of code to nearly 5,000. Had we not intervened and said, there would have been zero accuracy, zero confidence." 

Ben compares this core characteristic of AI models to a Labrador playing fetch.

Long-term maintenance and resourcing

Creating a v1 tool via vibe-coding is fast and exciting. Maintaining custom internal software is a different story. Beyond maintaining the code itself, managing external integrations and handling API updates requires dedicated technical oversight.

"Maintenance is the biggest unknown,” Ben reflects. “What does it actually look like a year down the road, when you've made 50 different enhancements, and they're all just add-ons? We have no idea. That is a huge risk, and we're taking that risk." 

Furthermore, scaling a vibe-coded prototype into an enterprise-ready internal platform often requires more organizational resources than initially anticipated. Here’s a side-by-side comparison of both scenarios.

To build or to buy? A decision framework

Ben Nelson doesn’t swear by either. For him, above all, it’s about finding the most effective and efficient response to a problem. Sometimes, a SaaS solution works; sometimes, building your own is the best option.

In his specific case, Ben stands by his decisions to build Archie because the potential business impact (pipeline growth and revenue metrics) outweighed the operational costs.

So, when should you choose one over the other? Ben offers a few key considerations for product leaders currently navigating this debate:

1. What is the true opportunity cost? Is the potential business value of a fully custom solution high enough to justify pulling engineering focus away from core revenue-generating products?

2. Does the commercial market offer an 80% fit? If a vendor solution covers 80% of your operational needs, buying avoids significant ongoing maintenance expenses. If market solutions deliver under 60%, building becomes a more practical alternative.

3. Have you accounted for hidden maintenance and AI operational costs? Account for token price fluctuations, model optimization requirements, code security audits, and continuous API integration upkeep.

eBook

The AI maturity gap:
Are product teams keeping up?

Read now