A new VP of Sales had joined Opendoor, and — unbeknownst to me — he asked our Customer Experience engineering team to demo Salesforce.

I happened to be in the meeting room next door when the demo happened. Our office had thin walls. I overheard the meeting and walked out hot. Why would we pay hundreds of thousands of dollars for that bloated thing? We had some of the best engineers in the world, and they had just built us our own CRM.

Turns out, I was wrong.

Opendoor was an operationally intense business, so we spent a lot of engineering effort on internal software. Customer Experience was one of our largest ops groups, and at some point we spun up a CX engineering team staffed with some of the best engineers I've had the privilege to work with. Some of them later joined OpenAI as part of its early team.

They built us a CRM. And it was slick — like super slick. Extremely fast, beautifully designed, tightly integrated with the rest of our stack. Pipeline stages, omni-channel messaging, all the workflows around the customer lifecycle. I remember seeing the first version and thinking: we should take a stance here. Screw the cruft and baggage of the big platforms. Look what a great team can build in four weeks.

Hence me storming out of that conference room.

About nine months later, the team was starting to feel the weight of maintaining the thing. An operator wanted a new pipeline stage. Another wanted a different messaging sequence. Then came permissions, integrations, edge cases, and an endless stream of small feature requests.

None of these were particularly hard, which was almost the problem. There were five other, much harder problems in the CX organization that this team was uniquely positioned to solve, and instead some of our best engineers were maintaining CRM software. I could tell they were getting tired.

The final straw came during a chat with the tech lead. He asked me, “Hey, should we revisit Salesforce?” I would've gone to bat for the team, but when the tech lead lost conviction, I knew we needed to shift quickly.

Eventually we sunset most of the homegrown CRM and moved to Salesforce. We didn't throw everything away. We kept the internal state machine that encoded how an Opendoor transaction actually worked — deeply specific to our business, complicated, and something we truly needed to own. The commodity CRM bits, we outsourced.

I can't believe I'm about to defend Salesforce, but the lesson for me wasn't really about the software itself. Our CRM could match — and in plenty of ways beat — the product. What we hadn't recreated was the system around the software: the integrations, conventions, operators who already knew it, and the shared mental model for how a sales organization worked. When a new sales leader joined, Salesforce was something they already knew how to run.

That experience taught me a rule I repeated for years: Build Proprietary, Buy Commodity.

I've been thinking about that rule again because AI has made building feel absurdly cheap.

A reasonably technical person can now vibe-code an internal app over a weekend — a reporting workflow, an approval tool, an inventory app. And a lot of these things are genuinely useful. They can be better tailored to the team than whatever exists off the shelf.

I think this is great. There's a huge long tail of useful software that was never built simply because software used to be so expensive to create. If someone can make themselves a useful tool in an afternoon, wonderful.

But then the tool starts to spread. A teammate begins using it. Then the whole team does. It gets connected to a source system. A recurring process forms around it. Six months later, somebody expects it to work every Monday morning.

At that point it has acquired all the boring properties of software. Things upstream change. Edge cases appear. Someone asks for permissions. And somebody has to be responsible when it breaks.

There is a good counterargument here. If AI makes software cheap to build, it also makes software cheap to rebuild. Maybe the person who wrote the thing leaves and somebody else can recreate it in a day. Code itself is becoming disposable.

I think that's probably true.

But the code isn't really the thing you're taking ownership of. You're taking ownership of making sure the number is right on Monday morning. Of triaging issues when something silently stops working. Of continuing to maintain this thing ad infinitum.

Building is getting very cheap. Responsibility isn't. Which makes the build-versus-buy question a little different than it used to be. The question isn't really, could we build this? The answer is obviously yes. The better question is: is this something we want to own?

And that's where building first is very useful. A prototype is a wonderful way to learn what actually matters. You find out which parts of the problem are truly proprietary, and which just felt that way. Maybe you discover the thing is so specific — or so easy to maintain — that you should keep it. Great.

But if it turns into something the whole team depends on, the math changes. The same AI making your team faster is making vendors faster too, except they're seeing the same problem across many customers and accumulating all the boring edge cases you haven't hit yet.

So cheaper software doesn't necessarily mean you have to choose build XOR buy. It means you can build first, learn what matters, and make a more informed decision from there. And often, the answer is: Build to learn, then buy.