Buy vs. build sounds like a big technology decision, but for most small businesses it is much more practical than that. You are rarely choosing one approach for the whole company. Your CRM might already be perfectly capable of scoring leads, while the process of replying to a new inquiry after checking the CRM, accounting software, and a spreadsheet may still require someone to stitch everything together manually.

At Unprompted, we generally think businesses should use the simplest option that can actually handle the job. Sometimes that means turning on a feature you already pay for. Sometimes it means buying a purpose-built product. And sometimes the awkward part of the workflow sits between systems, or depends on rules that are specific enough to your business that something custom is actually the cleaner option.

This guide walks through how we think about those tradeoffs, when custom AI is genuinely justified, and the warning signs that you may be building something you would be better off buying.

Native Features vs. Standalone Software vs. Custom AI

There are really three places to look before deciding how much to build.

The first is the software you already use. Accounting platforms can draft collection emails, CRMs can score leads, inbox tools can summarize threads, and project management systems increasingly have AI features built directly into them. These are usually the easiest wins because your data is already there, your team already knows the software, and someone else is responsible for maintaining the feature.

The limitation is that native features can usually only see their own world. Your CRM knows what is in the CRM. Your accounting system knows what is in the accounting system. If the job depends on information from both, the feature may be useful without actually solving the whole workflow.

The second option is standalone software built around one problem. This makes sense when the problem is common enough that an entire product category has grown around it: scheduling, customer support, bookkeeping, note-taking, outbound sales, and so on. A specialist product will often go much deeper than a feature tacked onto a larger platform.

The downside is pretty familiar to any small team: another subscription, another login, another place where information lives, and another tool that eventually has to be maintained or replaced.

Custom AI is different because it can sit across the tools you already use rather than asking you to move everything into a new one. In practice, that often means an agent reads the inquiry from email, checks the CRM, looks at an outstanding invoice, applies your rules, then prepares the next step. The value is not necessarily that the AI itself is more sophisticated. The value is that it can operate across the workflow instead of inside one application.

There is also a newer case that is easy to overlook: sometimes a small DIY build is simply cheaper. If you are paying hundreds of dollars a month for a narrow product that performs a simple, repeatable function, a lightweight automation built with the tools you already have may have a lower total cost. That does not automatically mean “build,” but it belongs in the calculation.

Our default order is still simple: check what you already own, check whether a good product exists, then consider custom. But “buy by default” should not become “buy even when the economics make no sense.”

The Two Factors That Drive the Buy-vs.-Build Decision

The decision usually comes down to two questions.

First: does the job live inside one application, or does it cross several?

If the whole workflow starts and ends inside one system, the case for buying is usually strong. The vendor already owns the data, understands the use case, and has an incentive to keep improving the feature. It is hard to justify rebuilding something your CRM, payroll software, or accounting platform already does reliably.

The more interesting workflows are the ones where no single system owns the job. Imagine a new lead comes in by email. Before replying, someone checks whether the person is already in the CRM, looks at prior conversations, confirms whether there is an unpaid balance, decides whether the lead qualifies, updates the record, and then follows up. Every individual tool may work perfectly. The manual work is in the handoff between them.

Second: is the logic standard, or is it specific to your business?

Some rules are basically universal. Send a reminder when an invoice is overdue. Create a calendar event when someone books. Add a form submission to the CRM. These are good candidates for existing software or straightforward automation.

Other rules are much more specific. Maybe a “good lead” means a company of a certain size, in three industries, with no current conflict, unless the founder referred them. Maybe some customers get an automatic reminder after seven days while others always get a personal note. Maybe a project should only move forward once three different conditions are met across two systems.

That is where custom logic starts to earn its keep.

A useful way to think about it is this: the more standard the problem, the stronger the case for buying. The more the value comes from connecting systems or encoding the way your business actually operates, the stronger the case for building.

When Custom AI Is Actually Justified

Custom AI is not automatically the “advanced” option, and it should not be treated like an upgrade from software you can buy. A lot of custom projects are unnecessary.

The source research for this article points in the same direction. MIT’s 2025 State of AI in Business research found much higher reported success rates for solutions bought from or implemented with specialized external partners than for internal builds. That is a useful warning against building for the sake of building.

The workflows where custom tends to make sense have a few things in common.

The work crosses multiple systems, and the annoying part is the coordination between them. The rules are specific enough that a generic product would force you to change a process that actually matters. The workflow happens frequently, so the setup cost is spread across hundreds or thousands of repetitions. And somebody is willing to own the system once it is live.

It also helps if you have already tested the obvious alternatives. If a native feature gets you 90% of the way there, use it. If a $50-per-month product solves the whole job, great. Custom becomes compelling when you have tried to solve the problem with existing tools and the remaining gap is still expensive, repetitive, or important.

For a small business, “build” also rarely means hiring a team of software engineers to create a new application from scratch. More often, it means configuring an agent or automation on top of the software you already run. The custom part is the logic, the connections, the permissions, and the way the workflow handles exceptions.

That version of building is much lighter than the word suggests.

Red Flags You're Building What You Should Buy

The clearest red flag is that a mature product already solves almost the entire problem. If your custom specification looks suspiciously similar to an existing product’s feature page with two small preferences added, you probably do not need to own the software.

Another one is assuming your process is unique before writing it down. Most businesses have some genuinely specific logic, but not every follow-up sequence or approval rule is proprietary. If a common product handles the process well enough, changing one or two habits may be cheaper than encoding every historical preference into a custom build.

Building purely to avoid a subscription can also backfire. A $100 monthly tool may look expensive until the alternative requires someone to spend five hours a month fixing connections, checking errors, and answering questions from the team. The right comparison is total cost, not just the vendor invoice.

On the other hand, subscription cost does matter when the build is genuinely simple. If a product charges $500 a month to perform a narrow job that can be recreated safely with a small automation and minimal upkeep, DIY may be the rational choice. The point is to compare the whole economics of both options rather than treating buying as automatically cheaper.

Scope creep is another warning sign. A project that begins as “help us follow up on overdue invoices” and becomes “build our AI operating system” before the first workflow is live is almost guaranteed to become more expensive and harder to evaluate.

And finally, somebody has to own it. Custom systems do not maintain themselves. If nobody can answer who reviews errors, updates rules, or fixes the workflow when a vendor changes an API, that is not a build plan yet.

There is an opposite failure mode too: buying multiple overlapping products because each one solves a piece of the problem. If your team is paying for three tools and still manually moving information between all of them, it may be time to stop adding software and look at the workflow itself.

The Bottom Line

• Start with the software you already pay for.
• Buy when the problem is standard and well served by an existing product.
• Build when the value sits between systems, in your own rules, or when a simple DIY approach has substantially better economics.
• Compare total cost, including setup, maintenance, subscriptions, and employee time.
• Do not build something custom unless someone will actually own it after launch.