Pets, Cattle, and the “Should We Build This?” Trap (Even When AI Makes Building Easy)

You’ve probably heard the old cloud ops mantra:

• Pets are special. You name them. You nurse them back to health at 2:00 AM.
• Cattle are replaceable. If one gets sick… you replace it. No drama. No memorial service.

That metaphor gets tossed around a lot in infrastructure conversations.

But here’s the twist I want to explore with you:

The pets vs. cattle problem isn’t just about servers. It’s about everything we build.
Especially the internal tools, platforms, frameworks, and “we can totally code that” side quests that sneak into IT projects.

And yes… AI has made those side quests way easier to start.

It has not made them easier to finish.

Let’s talk about the real debate hiding underneath pets vs. cattle:

Should you build your own tool… or buy/license something that already exists?
And how does AI change the math without changing the reality?

The Metaphor We Forgot to Apply

Most teams understand pets vs. cattle for compute:

• Don’t SSH into a server and hand-edit config.
• Use automation.
• Use immutable images.
• Treat failure as expected.

Cool.

But then we do something like this:

“We’re going to build an internal deployment portal / ticketing system / logging platform / secrets manager / Kubernetes dashboard / configuration framework… because we can.”

And suddenly we’ve created a new pet.

Not a server-pet.

A software-pet.

It has a name (“Project Chimera”… you know it does).
It has feelings (“Please don’t refactor me this sprint.”).
And it absolutely will wake you up at night.

Pets aren’t bad… but they’re expensive

Sometimes you need a pet. Some systems are core to what you do.

But most of the time, the stuff we build “because it’s cool” becomes this:

• A maintenance obligation
• A bus factor risk
• A security surface area expansion
• A roadmap anchor that drags behind the business like a boat trailer with a flat tire

And the business doesn’t care how elegant your framework is.

They care that the thing they sell… sells.

The Build vs. Buy Question Is Really a Focus Question

I’ve seen teams frame build vs. buy as a technical decision:

• “Can we build it?”
• “Would it be fun?”
• “Do we dislike vendor X this week?”

But the grown-up version of the question is:

Is this where we should invest our limited time, talent, and attention?

Because you do have limited resources.

Even if your team is stacked with brilliant people, you still only get:

• so many engineering hours per sprint
• so much on-call tolerance
• so much security review capacity
• so many “big rewrites” before everyone quietly updates their LinkedIn

Every internal tool you build steals time from the product you’re actually paid to deliver.

That’s the part we don’t like to admit.

AI Makes Building Easier… Which Makes This Harder

Let’s talk about the elephant in the room.

AI is incredible for:

• spinning up prototypes
• generating scaffolding
• filling in the boring parts
• turning “blank page panic” into momentum

So now the argument sounds like this:

“Why buy this tool? We can build it in a weekend with AI!”

And you probably can.

But here’s the catch:

AI helps you build Version 1.
It does not automatically own:

• Version 1.1 bug fixes
• Version 2 feature requests
• security patches
• compliance evidence
• uptime guarantees
• user support
• documentation
• training
• deprecation strategy
• integration breakages when dependencies change

AI can write a lot of code quickly.

But it cannot magically eliminate the one cost that dominates the long-term budget: Ownership.

If you build it, you own it. Forever.
Even if you “finish it.”

(There is no finish. There is only maintenance wearing a different hat.)

A quick gut-check

If this tool breaks on a Sunday night, who gets paged?

If the answer is “us”…

You didn’t build a tool.

You adopted a pet.

A Practical Framework: 7 Questions That Save Careers

When someone proposes building an internal tool, I like to walk through these questions. Not because I hate building things (I love building things)… but because I love shipping value more.

1) Is this core to what makes your business unique?

If it’s a differentiator—something competitors can’t easily copy—building might be worth it.

If it’s a commodity capability (logging, auth, CI/CD, ticketing, secrets)… strongly consider buying.

2) Can we clearly articulate the business value in one sentence?

Not “modern architecture.”
Not “developer experience.”

More like:

• “Reduce deployment time from 45 minutes to 5.”
• “Meet audit requirement X by date Y.”

If you can’t say it simply, it’s probably not the real priority.

3) What’s the total cost of ownership (TCO) over 2–3 years?

Include:

• engineering time
• cloud costs
• incident response time
• security reviews
• upgrades and dependency churn
• onboarding and documentation

Most build-vs-buy discussions magically stop at “license cost.”

That’s like judging a car’s price without acknowledging gas, insurance, maintenance, and… the fact that you need wheels.

4) What’s the blast radius if it fails?

If failure is annoying, maybe it’s fine.

If failure blocks revenue, deployments, customer access, or compliance… are you sure you want a homegrown version?

5) Who will run it when the original builder changes teams?

If the answer is:

• “We’ll figure it out later,” or
• “It’s easy,” or
• nervous laughter

…you already know.

6) What’s the exit strategy?

Even vendor tools need exit plans. But internal tools especially need:

• how to migrate off
• what data portability looks like
• how to deprecate safely

If you can’t describe the exit, you’re signing a long-term lease without reading the contract.

7) Could we buy now, and build later if needed?

This is the one that unlocks sanity.

Start with something proven.

Learn what you actually need.

Then, if you discover a true differentiator… build intentionally.

The “Cattle” Move: Use Managed Services and Automate the Boring Stuff

If you’re building internal tooling because you need consistency, repeatability, and guardrails…

Good news: you can usually get that without building a custom product.

Example: Don’t build a platform—build automation and standards

HashiCorp Terraform is a great example of “cattle thinking” applied to infrastructure:

• you codify patterns once
• reuse them everywhere
• replace environments safely
• reduce hero-ops

Here’s a simple (copy/paste-ready) Terraform example that leans into managed services instead of DIY infrastructure. It provisions an Azure Resource Group, Log Analytics Workspace, and enables Container Apps-friendly monitoring patterns.

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 4.0.0"
    }
  }
}

provider "azurerm" {
  features {}
}

# Cattle mindset: create environments that are reproducible and disposable.
resource "azurerm_resource_group" "rg" {
  name     = "rg-cattle-demo"
  location = "East US"
}

# Use managed observability instead of rolling your own logging stack.
resource "azurerm_log_analytics_workspace" "law" {
  name                = "law-cattle-demo"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  sku               = "PerGB2018"
  retention_in_days = 30 # adjust for compliance requirements
}

output "log_analytics_workspace_id" {
  value       = azurerm_log_analytics_workspace.law.id
  description = "Workspace ID for connecting managed services to centralized logs."
}

Notice what’s not here:

• no custom logging pipeline
• no homegrown monitoring UI
• no “we wrote our own agent because reasons”

You’re using commodity building blocks so you can focus energy where it matters.

A Quick Checklist You Can Use in Your Next Meeting

When someone says, “Let’s build it,” run this list:

Build it if:

• ✅ It’s a true business differentiator
• ✅ You can staff it long-term (not just build it)
• ✅ Failure won’t cripple critical operations (or you can engineer it like a product)
• ✅ You have clear requirements and a clear exit strategy

Buy/license it if:

• ✅ It’s a commodity capability
• ✅ The market already solved it well
• ✅ Security/compliance and uptime matter
• ✅ You want predictable cost and vendor accountability

Use AI wisely when:

• ✅ You’re prototyping to validate the need
• ✅ You’re automating glue code and workflows
• ✅ You’re accelerating delivery of core value

Be cautious with AI when:

• ⚠️ It tempts you into building a product you don’t want to own
• ⚠️ It produces a “working demo” that hides long-term maintenance costs

The Real Win: Ship Value, Not Pets

Look, we’re builders. It’s what we do.

And yes—building a custom tool can feel like progress.

But the business scoreboard usually doesn’t track:

• elegance
• framework purity
• how many YAML files you eliminated

It tracks outcomes.

So here’s the guiding principle I keep coming back to:

Treat your infrastructure and internal tools like cattle whenever you can—
so you can treat your product and customer value like the thing you actually care about.

If you’re ever unsure, ask one question:

“Are we building this because it helps the business… or because it helps us feel clever?”

(And hey—no shame. We’ve all been there.)