Build vs Buy Software When AI Writes the Code: What Still Costs You

Ask a room of engineering leaders whether they could build their own CRM, scheduling tool, or compliance tracker, and most will now say yes. AI coding assistants turned "could we build it?" into a question you can answer in an afternoon. That is exactly why the build vs buy software decision has become easier to get wrong. The question that decides it was never whether you can build the thing. It is whether you are prepared to own it.

Key Takeaways

• Many "we should build it" decisions are driven by outdated processes, a thin technical bench, or fear of vendor lock-in. None of those, by itself, is a strong reason to build.
• Steve Malko's test weighs speed, quality, cost, and your ability to maintain what you choose, and it starts with the business process, not the technology.
• AI changed one input: the first build is now cheap for narrow, well-defined tools. It did not change authentication, encryption, audit trails, patching, or who gets paged when it breaks.
• In regulated settings those ownership costs are requirements, not polish. Where a tool handles electronic patient data, HIPAA lists them as technical safeguards.
• The deciding question is no longer "can we build it?" It is "who owns this in year two, and what happens when they leave?"

Most "we should build it" decisions start with the wrong reasons

On a recent episode of Engineering Choices You Have to Defend, Steve Malko, a technology and operations leader whose career spans software development, product management, and consulting, walked through a decision he has seen play out more than once. A regional insurance company chose to build its own CRM instead of adopting Salesforce.

The reasons behind that choice will sound familiar to anyone who has sat in the meeting:

• The existing processes did not fit the product. The company wanted software shaped around the way it already worked, and those processes were outdated.
• The technical bench was thin. There were limited internal resources to design, build, and run a platform of that size.
• Vendor lock-in felt like a risk. Committing to a large SaaS vendor felt like handing over control.

Each of these sounds prudent. None of those reasons, by itself, makes a strong case for building. An outdated process should be questioned before it is encoded in software. A thin technical team makes long-term ownership harder, not easier. And avoiding vendor lock-in only helps if the organization has the capacity to maintain what replaces it. Otherwise it trades one kind of lock-in for another: lock-in to your own codebase and the handful of people who understand it.

Steve also described a large technology company that built a custom call center platform and ultimately abandoned it because of marketing and operational challenges. Writing the software was not what sank it. Running it, and getting the organization to adopt it, was.

How Steve Malko decides: build or buy

Steve's framework is deliberately unglamorous. Before anyone discusses technology, look at the business process. Then look honestly at what your organization can support. Only then pick the tool. Within that, he weighs four things:

1. Speed. How quickly does each option deliver value? For commodity functions like CRM, ticketing, or payroll, buying usually wins because the product already exists and someone else has debugged it.
2. Quality. Who is better at this category of software: your team, or a vendor whose entire business is this one product? Be honest about the answer.
3. Cost. Not the first invoice or the first sprint, but the full cost over the life of the system, including the people who keep it running.
4. Ability to maintain. Who fixes it, patches it, and extends it after the original builders move on?

In his view, building earns its cost when the requirements are genuinely unique to your business and the organization has the resources to support the result. Everything else defaults to buy, often combined with integrations that wire the bought product into the systems you already run. That default is not a lack of ambition. It is a decision to spend your engineering capacity where it differentiates you.

What AI changed: the first build got cheap

The episode that aired right after Steve's tested this framework from the other direction. Ovais Quraishi, an engineering leader focused on infrastructure, reliability, and software quality, described a healthcare compliance problem that runs on paper. Clinics have to keep detailed records of equipment temperatures, medicine storage conditions, and other regulatory checks. On paper, those logs are hard to store, hard to retrieve, and painful to pull together when an auditor asks.

Instead of buying expensive software, Ovais used Claude to turn the clinic's existing PDF forms into a working web application. By his own account it took roughly three hours of prompting, spread across several days.

The interesting part is the division of labor. AI produced the forms and the application code. Ovais supplied the architecture, the business rules, and the compliance requirements. He also deliberately kept the AI away from sensitive patient information. In other words, the software architecture and the compliance judgment were human work, and that is what made the generated code usable.

This is a real shift for one kind of project: a narrow, stable, well-understood tool that replaces paper or a spreadsheet. For that kind of tool, the old argument against building ("it will take a team a quarter") is weaker than it used to be. Steve makes a compatible point: AI helps teams build integrations, connectors, and custom components faster, but it does not hand an organization the expertise, governance, or operational maturity needed to run a complex platform.

Three hours demonstrated how quickly the application could be built. It did not establish what it would cost to secure, validate, deploy, and maintain it over time.

What AI did not change: owning it

Ovais was explicit that faster development does not remove the need for ongoing maintenance, security updates, and responsible management of the software. AI may reduce the effort involved in some of that work, but the responsibility, and the cost of getting it wrong, remain with the organization. That list is where the real cost of building lives:

• Authentication and access control. Who can see what, how accounts are provisioned and removed, and what happens when a staff member leaves.
• Encryption. Data protected in transit and at rest, with keys someone actually manages.
• Audit trails. A record of who changed which entry and when, which is often the point of a compliance tool in the first place.
• Data integrity. Confidence that a temperature reading logged last spring has not been silently altered or lost.
• Patching and dependencies. Every library the AI pulled in is now yours to update when a vulnerability lands.
• Backups, recovery, and on-call. Someone has to notice when it is down and know how to bring it back.

In regulated settings these are not nice-to-haves. The HIPAA Security Rule's technical safeguards name access control, audit controls, integrity, person or entity authentication, and transmission security as standards for systems that handle electronic protected health information. In healthcare, those obligations apply when a tool creates, receives, maintains, or transmits electronic protected health information. A log of fridge temperatures may never hold patient data. The moment a tool does, it inherits those obligations from the day it goes live, regardless of how quickly it was built. Outside healthcare, NIST's Secure Software Development Framework describes the same shape of obligation for anyone producing software, including protecting the code and responding to vulnerabilities after release.

AI can even make this side of the ledger worse. When building is cheap, organizations build more, and every internal tool is another system with credentials, data, and dependencies that someone has to own. Ten quick tools with no owner can carry more risk than one SaaS subscription with a vendor accountable for security.

That is why Steve's framework still holds. AI moved the cost input for narrow tools, so the answer can change at the edges. It did not remove the maintenance input, which is the one that sank the insurance CRM and the call center platform. AI changed the cost of building. It did not change who is accountable for what gets built.

A build vs buy checklist for the AI era

Steve's questions, updated for a world where the first version is cheap:

1. Is the scope narrow and stable? A form-based compliance log is a reasonable build. A CRM, a billing system, or a call center platform probably is not, no matter how fast the first version comes together.
2. Is the process worth encoding? If the process is outdated, fix it first. A product with a better default workflow may be worth more than custom software that preserves a worse one.
3. Who owns it in year two? Name the person. If the answer is "whoever built it, in their spare time," that is not an owner.
4. Does it touch regulated or sensitive data? If yes, list the safeguards it needs before you write the first prompt, and decide who verifies them.
5. Can you audit it? Logs, access reviews, and a way to show an auditor what happened. If you cannot answer that, neither can the auditor.
6. What is the exit if the builder leaves? Documentation, a handover plan, and code someone else can read. AI-generated code nobody has reviewed is a hard handover.
7. Are you comparing like with like? Compare the subscription against the full cost of ownership, not against the first build.

If you cannot name who will own the software and explain how it survives its original builder leaving, you are not ready to build it.

Where Code Particle fits

We help teams make this call before it becomes expensive. Sometimes that means confirming that buying and integrating is the right answer. Sometimes the build genuinely earns its cost, and we help design the architecture and deliver the web application so it is owned properly from day one. Increasingly, it means a software audit of an AI-built internal tool before it holds real data, checking authentication, audit trails, encryption, and dependencies against what the business actually needs.

For the full conversations behind this article, listen to Steve Malko and Ovais Quraishi on Engineering Choices You Have to Defend.