Dev Mindset: Own the Future of Your Operations

"Just buy it" is the most expensive sentence in software. Not because the license costs too much — because it quietly gives away the only thing that makes your company hard to copy: how you actually run.

Amazon understood this before it was cool. It buys software, studies how it works, then rebuilds it in-house on its own terms. Between 2000 and 2006, Amazon's engineering teams standardized internal compute, storage, and databases to tame web-scale complexity. AWS came out the other side as a byproduct — a cash cow that started as an internal necessity.

Amazon never let a generic vendor sit at the center of how it ran. It kept the reflex to rebuild whatever mattered enough to own. That reflex is spreading. Nearly every portfolio company I talk to now describes rebuilding internal tooling with AI. The cost of building dropped so far that "just buy it" stopped being the default answer.

But the lesson from Amazon isn't "rebuild everything." It's sharper than that:

Own the things that decide how you operate. Buy everything that doesn't.

Buy the commodity. Own the differentiator.

There's a hard rule I use. If software is a commodity — heavy, mature, high-risk to replace — you buy it. ERP is the obvious one. Finance software is another. Nobody wins a market by rebuilding their general ledger. Your general ledger is not a moat. That's not where the business differentiates; it's where the business gets dragged down if you get clever. Commodity software exists because thousands of companies already paid to make it boring. Take the boring. Spend your build energy elsewhere.

The things worth owning are the internal operational systems that make your business run differently from the person next door. Those are the systems nobody sells, because they're specific to you. Your quoting flow. Your inventory logic. The way you route orders. The agent that triages customer messages.

If a vendor can sell it to a thousand companies, it's not your edge. If they can't, only you can build it.

That's the whole decision rule: build what differentiates your operations. Buy what's commodity.

Where I actually use this

I run a side business where this stopped being theoretical. (This is also my mentality for work — and probably a reason I've learned to ignore the vendor spam of "We can automate this and that with AI.") For my side business, I run an autonomous agent fleet. Not a demo. Agents doing real operations work — triaging inbound, drafting responses, watching listings, pulling reports. The orchestration layer is something I own, because it encodes how my business actually runs. There's no off-the-shelf version of "the way I run this." So we built it. It currently runs 90% of that business.

The same logic shows up in smaller, unglamorous places. I run vision models locally instead of paying a cloud subscription for every image. It's cheaper — and more importantly, it's mine. I control the latency, the data, and what happens when it breaks. When something is small enough to run on a machine I already own, owning it is the default, not a project.

Home Assistant is the same instinct at the house level. Self-hosted automation instead of renting someone's cloud and hoping they don't change the terms. Same muscle: if it runs my environment, I want it under my roof.

None of this is about being clever or anti-vendor. I still buy plenty — including the boring heavy stuff I just told you to buy. The point is a clean line: the closer something is to how you actually operate, the stronger the case for owning it.

The framework

If you want the rule in a sentence: solve your ops first, then treat that internal system as the product nobody can take from you.

Before you rebuild anything, ask whether the software sits on your differentiation or is just table stakes. If it's table stakes, buy it. Then ask whether a vendor is already great at it — if yes and it's not your edge, stop. Then ask whether you can build and maintain it with the people you have. Owning something you can't maintain is worse than renting.

Amazon rebuilt compute because compute was the center of how it ran. It bought plenty of other things. The discipline is knowing the difference.

Most companies get the order backwards. They buy the operational software that should be theirs, and spend a year rebuilding the commodity they should have bought. Flip it. Own the operations, rent the rest — and let the systems you build become the thing a competitor has to spend years catching up to.

That's the dev mindset. The future of your operations is either something you own — or something you're renting from whoever owns it next.