“We couldn’t build something like this ourselves.”
I heard that line a few weeks ago in a discovery session with a client. We were walking through their processes and the tools they’d bought to support them, and when we got to one tool in particular, that line came up. Building their own version was off the table, they said. It always had been. I hear some version of that from many of the SMB leaders I talk to.
I didn’t push back. I was there to listen, and I didn’t know their requirements well enough to have an opinion yet. But I filed the comment away, because it rests on an assumption that used to be true and quietly isn’t anymore. AI took a wrecking ball to the barrier that kept custom software out of reach for small and mid-size businesses. The cost of building collapsed. It didn’t disappear, though. It moved.
Build was never really on the table. Now it is.
The old rule existed for a reason. Custom software used to require a team: an architect, a developer or three, someone for the database, someone for UI, someone thinking about security. For a 50-person company, that meant six figures and months of runway before anything worked. Buying was the only rational move.
What changed is that AI can now fill most of those roles. The objection here has a name: vibecoding. Prompting your way to something that demos beautifully on Friday and buckles the first time a real customer touches it. That objection is fair, and it is not what I am describing. The same disciplined processes that built the biggest software of our lifetimes still apply. AI just made the whole team affordable.
Here’s the part that gets skipped, though. When you build, you own it. Something breaks at 9am on a Tuesday and there’s no vendor to call. That operational burden is real, especially for low-tech shops, and it’s the strongest argument left in the buy column. It is not unanswerable, though. The same capabilities that collapsed the cost of building can be pointed at running the thing: an AI-queryable operations handbook, written against your own system, resolves most of what you would have opened a support ticket for.
Six questions that make the decision for you
No single question below settles it on its own. Together, they usually do.
How specific are your requirements?
The tighter the scope, the stronger the case for building. A clear, narrow set of capabilities that won’t break the bank is a build candidate. Sprawling or fuzzy requirements point back toward buying, because vendors have already spent years discovering what you haven’t defined yet. The flip side is that vendors sell mansions. You need the kitchen, but the price includes forty rooms you’ll never walk into. Tight requirements protect you in both directions: they tell you when a build is justified, and they tell you when a suite is overkill. We’re weighing exactly this with a client right now: a lightweight custom CRM on an Airtable back end, or a HubSpot implementation. The honest answer is we don’t know yet. The requirements will decide, and that’s the point.
Who actually uses it, and how?
Per-seat pricing punishes broad, shallow usage. Take a 100-person company considering Claude licenses for everyone. That’s nearly $3,000 a month. But does everyone need the full platform? If 75 of those people just need to ask questions of company knowledge, a purpose-built integration against an AI API might cover them for far less. There’s an upfront bump to build it, sure. We’ll get to that trade shortly. The pattern to notice: lots of light users is where SaaS pricing quietly stops making sense.
How fast are the requirements changing?
Changing requirements create operational friction, and friction lands on whoever owns the tool. If that’s a vendor, they absorb it. If it’s you, someone in your shop is fielding the change requests. This is less a reason to avoid building and more a test of how the build is scoped. A build done right accounts for the long term: defined SLAs, a support model, data management, a plan for feature development. Those questions belong in the conversation before any code gets written.
What happens when it breaks?
Pushing mission-critical systems to a vendor is a legitimate de-risking move. It’s also not a silver bullet, because vendors have outages too, and theirs come with a support queue. The better question for any tool, bought or built: what can you still do manually when it’s down? And weigh this against how the custom option is actually built. A custom solution running on proven cloud services like Airtable, Supabase, Notion, or Microsoft 365 inherits the redundancy and availability those platforms already guarantee. Custom doesn’t have to mean fragile.
Where does the money come from, and where does it go?
Buying is an operating expense: easy to start, and a meter that never stops running. Building is closer to a capital expense: more upfront, then the tool is yours. For a long-term need with real usage, that upfront investment can pay for itself quickly, and it scales without the per-seat tax as your team grows. There’s a second cost hiding in the buy column too. One business owner described it to me as being held hostage: years of data living inside a vendor’s system while the price climbs, and leaving would hurt more than paying. And in some industries, there aren’t many domain-specific vendors to begin with, so the buy side of the ledger offers less choice than the advice assumes.
How complex is the build, really?
Here’s a tell that requires zero technical knowledge. Talk through the requirements at a high level and notice how it feels. If you’re grounded, you can see the problem clearly, and you can describe what the solution does in a few sentences, complexity is manageable. If listing the use cases already feels overwhelming, believe that feeling. It’s telling you the scope will creep and the build will become more than anyone signed up for. The more moving parts a custom solution needs, the harder the argument for building it.
Four more that occasionally tip the scale
A few factors don’t need their own deep dive but deserve a seat at the table. Urgency: buying can be live this week; building can’t. If the need is on fire, that alone may settle it. Competitive differentiation: nobody should build their own accounting software, but if a tool touches the thing you do better than anyone, ownership starts to matter. Compliance and security: in regulated spaces, an established vendor carries certifications and patching you’d otherwise carry yourself. And training: every tool needs it, bought or built. Custom solutions have a quiet advantage here, though. A build can ship with an operations guide your team queries through AI, which turns troubleshooting from a panic into a conversation.
The requirements decide. Someone just has to ask.
“We couldn’t build something like this ourselves.” That statement was true for decades, and it quietly stopped being true. Not because building became free, but because the cost moved: away from the six-figure team you could never justify, toward ownership questions you can actually evaluate. That’s what the six factors are for.
The failure we see most often isn’t a broken custom build. It’s the company paying for a mansion because nobody asked whether they just needed the kitchen. Sometimes the answer really is an off-the-shelf product, and when it is, we help clients select it, stand it up, and migrate their data. Other times a tight, well-scoped build serves them better for a fraction of the ongoing cost. We built our AI Advisory practice around navigating exactly this decision, because the answer isn’t build or buy. It’s knowing which questions decide it.
