Build, Buy, or Bot? How to Choose Without Wasting Money

There used to be two answers to "how should we get this software?" — build it custom, or buy somebody else's. Now there's a third option that's quietly become the most popular one without anyone formally introducing it: have AI build it for you.

That third option is real, and it's useful, and ignoring it costs companies money. So does picking it for the wrong things. The trick is figuring out which option fits which problem, and there's a surprisingly simple way to think about it.

The three options, in plain English

Buy means using software somebody else already made — QuickBooks, Salesforce, Slack, whatever. You pay a subscription, you live within whatever they decided to build, and you mostly don't have to think about it.

Bot means having an AI tool (Claude, ChatGPT, Lovable, take your pick) build the thing for you — usually in an afternoon, usually by one person on your team, usually without an engineering background. The result works, more or less, for the use case it was demoed against.

Build means hiring people to do real custom development — the kind that gets architected, tested, secured, maintained, and supported.

All three are correct answers, depending on the question. Here are the three questions that actually decide which one fits.

1. How core is this to your business?

If the workflow is something every business in your industry does roughly the same way — payroll, accounting, expense tracking, basic CRM — buy. Don't build your own version of QuickBooks. Don't have AI build your own version of QuickBooks. Pay the forty dollars a month and move on.

If the workflow is your competitive edge — the thing that makes you better than the company down the street — build. The reason it's your edge is that nobody else is doing it your way. There's no SaaS for that, by definition.

If the workflow is somewhere in the middle — useful but not differentiating, internal but not negligible — bot is often the right call.

2. How sensitive is the data?

If the system touches customer data, payment information, health records, employee records, or anything regulated, you've already answered the question. Build. This isn't snobbery — it's that the cost of getting it wrong is enormous, and "I had Claude build it in a weekend" is not a defense that holds up in front of an auditor or a judge.

If it touches only public data, internal-only data, or your own personal stuff, the door is open to bot or buy.

3. How many people, and for how long?

A tool you'll use for two months and then throw away can be vibe-coded. A tool that ten teams will rely on for the next five years cannot. The number of users and the time horizon are what turn small architectural decisions into big problems — or into non-problems, depending on which way you went.

How this actually plays out

A few examples to make it concrete:

• Internal tool to summarize this week's customer feedback for the team meeting → Bot. Low stakes, one team, short shelf life. Build it in an afternoon. If it breaks next quarter, build it again.
• Customer-facing portal where clients log in to see their orders and pay invoices → Build. Customer data, regulated payments, long shelf life, central to the business. This is exactly the wrong place to vibe-code.
• Project management for the team → Buy. Asana, Linear, Monday, ClickUp — take your pick. Whatever you'd build is worse than what already exists, and existing tools have a decade of integrations and bug fixes you'd otherwise have to recreate.
• AI assistant that helps your support team draft replies → Build, with bot used for the prototype. Get a rough version working with AI in a week so you can prove the concept, then bring in a partner to do the version that touches real customers.

Notice that one of those four answers is "buy," another is "bot," and only two are "build." If a development partner ever tells you the answer is always build, that's a sales pitch, not advice.

The honest meta-point

Most companies under-spend on real engineering for the things that actually run their business, and over-spend on it for things they could have just bought off a shelf. The math has gotten a little more interesting now that "have AI build it" is on the menu, but the fix is the same as it's always been: be honest about what's core to you, what's a commodity, and what's actually at stake if the thing breaks.

When you're not sure — and you're often not, which is normal — find a partner who'll tell you the truth even when the truth doesn't bill any hours. We try pretty hard to be that partner. Sometimes that means we work together on something significant. Sometimes it means we point you at a forty-dollar-a-month SaaS and call it a day. Both are wins.