Everyone Can Build Software Now. You Should Still Buy It.

Broome is a software company that sells to commercial real estate teams. Read this post with that context.

As vibe coding progresses at lightspeed and Claude releases new capabilities every day, I wanted to spend some time on the build-vs-buy decision teams are facing right now and explain why I think there is still a huge need for exceptional, purpose-built, vertical software.

The question every team is asking

Every CRE team we talk to right now is having some version of the same conversation. They know they need to implement AI and acknowledge that the general-purpose tools are becoming more powerful by the day. However, there is so much noise that it is hard to tell what actually works.

We talk to dozens of CRE teams every week, and the shift over the past few months has been dramatic. In March 2025, I spoke with teams who had zero interest in adopting software, and some did not know what AI was. Today, every CRE team we speak to is actively experimenting and piloting tools.

What we have seen work and fail in the CRE space

Whenever I run into people who have vibe-coded a solution, it excites me. If I were working at a one-to-five-person shop, I would hack together tools to automate as many one-off tasks as possible.

The issues arise when people try to build full systems and automate more than just one-off tasks. So far, I have seen this play out in three ways:

1. They built tools, and they are useful: One team told us they extract data from an OM and apply their typical operating margin to come up with a going-in cap rate, then store it on their pipeline to compare across deals over time. This works because it is a specific, isolated task: pull data, run a calculation, save the output. Claude is perfect for that.
2. They built dashboards, but not that useful: Another team built an asset management dashboard: extract property financials into a CSV, upload it, see performance across the portfolio. It looked great in the demo, but no one is opening it. There is still manual effort to keep it updated, no connectivity to live data, and a dashboard on its own does not provide much insight.
3. They have half-built platforms and wasted a ton of time: The most ambitious teams try to wire everything together: financials flowing into asset management models, data getting standardized automatically, action items generated and routed to the right people. That is not a tool anymore, that is a product. As soon as you are dealing with multiple integrations and collaboration, the complexity becomes exponential. These teams consistently tell us they wasted a ton of time and still do not have something that works reliably.

I tried to build instead of buy

With demand for solutions so high, and barriers to build so low, the impulse to build in-house makes sense. But I think the gap between a working prototype and a product you rely on for serious work is larger than people realize, and I learned this by trying myself.

A few weeks ago, I needed help with a sales tool I was using, got frustrated with an existing product's support team, and decided to build it myself using Claude Code.

I spent about two hours a day on it for two weeks. After roughly twenty hours, I had a working product that did maybe 80% of what the professional tool offered, plus some additional customization that it does not have. Building was fun, even addicting. At first it was easy. I immediately thought, "Wow, this is even easier than I expected. Maybe people really will not need to pay for software anymore."

But as I expanded the functionality, the complications erupted. API connections were multiplying. I needed notes and files from one software to auto-sync into deal records, simple in theory. In practice, that meant different auth flows, writing token refresh logic, and parsing the same data point across three different response formats. Each fix led to another bug. The agent would propose a solution, I would approve it, and ten minutes later a new edge case would surface.

Everything is fixable, but that can also be the problem. Building becomes a never-ending cycle of bug fixes, new features, more bugs, and more fixes.

With a million other tasks on my plate and no support team to email, I started to understand why paying for software still matters.

Three things that have to be considered when vibe coding

1. Security is a concern: As someone with no technical background, it is remarkable how much code these agents produce, and alarming how easy it is to just hit accept on all of it. Every API connection adds complexity, more approvals, and more surface area for something to go wrong. For a tiny shop, maybe this risk is acceptable. But if you are managing institutional capital or handling sensitive deal data, the peace of mind that comes from a vetted vendor with proper data compliance is worth a lot.
2. There is a massive gap between an 80% workable product and a 100% hyper-efficient product: Getting a product to 80% functionality is easier than ever, but that last 20% - the smooth drag-and-drop, the collaboration with the team, the feature that does not break when you do something slightly unexpected - is what determines whether anyone actually uses it. That remaining 20% is the hardest part to build and the easiest to underestimate, and it is exactly what purpose-built software teams spend most of their time obsessing over.
3. You do not know what you do not know: This might be the biggest one. When you build for yourself, you are limited to your own imagination and experience. While AI is great at generating ideas, purpose-built software benefits from a feedback loop from real users. A team that has talked to hundreds of users has seen every edge case and efficiency opportunity. When building for your own use case, you can customize everything, but the product is frozen in time without manual upkeep.

So what do you do?

The counterargument to all of this is strong: security will improve, the tools will get better, and no one knows your workflow like you do. For small teams with specific, isolated tasks, building is often the right call, and I encourage it. An 80% tool built around your exact process can genuinely beat a polished product.

But everything changes when you need more than a single-user tool. A product team that talks to hundreds of users every month sees edge cases, workflows, and collaboration opportunities you would never think to build for yourself. As the technology shifts, what you built last month does not update itself. Without someone dedicated to pushing a product forward every day, your custom solution is frozen the moment you stop working on it.

Be honest about where building hits its limits. Experiment with the general tools because if you are not, you are falling behind. But when something needs to work across your team, connect multiple workstreams, and stay current as your process evolves, that is where purpose-built software earns its cost.

The teams spending six months hacking together an 80% solution will be behind the ones who recognized that line early.

We talk to teams every day who are figuring out the line between what they can build and what they should buy. If you want to think through where that line is for your team, reach out. Happy to chat.