The APIs are cheap and well documented. The frameworks are free. A developer can wire a language model to a database and produce something demo-ready in a weekend. So the build option looks attractive, and for a certain kind of technical founder it is almost irresistible.
Sometimes it is right. More often the weekend prototype is the cheapest part of a considerably longer commitment, and the decision was made on the wrong number.
What building actually costs
The prototype is not the product. Between them sit a set of problems that are individually unglamorous and collectively substantial.
Error handling. Model APIs time out, rate limit and occasionally return nonsense. Production systems need retries, fallbacks and graceful degradation. This is not hard, it is just work that nobody enjoys and that the prototype skipped.
Evaluation. How do you know a change made things better? Without a test set and a way to measure output quality, every prompt adjustment is a guess, and you will make many. Teams consistently underestimate this, and it is the difference between a system that improves and one that oscillates.
Cost control. Token costs scale with usage in ways that surprise people. Without quotas, caps and monitoring, a loop bug or an enthusiastic user produces a memorable invoice.
Security and access control. Who can see what. Especially once the system touches customer data or connects to other systems.
Integrations. The genuinely expensive part. Each connection to a real business system means OAuth flows, token refresh, pagination, rate limits, schema changes and error states. Then it needs maintaining, because the provider will change their API and not ask you first.
Model churn. Providers deprecate models. A system built against a specific model needs periodic revalidation, because behaviour changes between versions in ways that are not always documented and not always obvious.
Compliance. If it processes personal data, you need a lawful basis, a record in your processing register, and appropriate agreements with any sub-processor you are calling. Building does not remove this. It moves it onto you.
The maintenance floor. This is the number people leave out. A production internal tool needs someone available when it breaks, and it breaks at inconvenient times. That standing obligation is the real cost, and it does not appear in the build estimate.
A reasonable rule from software generally: the prototype is roughly 10 to 20 percent of the total cost of a maintained production system. AI systems are, if anything, worse, because output quality degrades in ways that are harder to detect than a crash.
When building is genuinely right
The workflow is your actual differentiator. If the automation is the product, or a core part of how you compete, own it. Nobody will build your specific advantage for you.
Off-the-shelf genuinely does not fit. Not "does not fit perfectly." Nothing fits perfectly. Genuinely does not do the thing.
You have the maintenance capacity, permanently. Not enthusiasm. Capacity, allocated, in a team that will still exist in eighteen months.
Data cannot leave your infrastructure, for regulatory or contractual reasons that survive examination. Note that this often points to self-hosting a model rather than to building a whole application.
Volume makes per-seat pricing irrational. At sufficient scale the arithmetic genuinely flips. Check the arithmetic rather than assuming, because "sufficient scale" is usually larger than people expect once maintenance is costed.
When buying is right
The workflow is generic. Invoice processing, meeting notes, customer support triage, document generation. Thousands of businesses need the same thing, which means someone has already solved the edge cases you have not thought of yet.
You need integrations more than logic. If the value is in connecting to accounting, banking, payroll and CRM, buying that connectivity is almost always cheaper than building and maintaining it. This is the most common case and the one most often misjudged.
You are small. A five-person company allocating a developer to maintain internal tooling is allocating a fifth of its capacity to something that is not the business.
You need it soon. Buy, learn what you actually need from real usage, and build later if the case survives.
The middle path most people miss
The decision is rarely binary.
Buy the platform, build the specifics. Many products expose APIs or support custom configuration. You get the maintained infrastructure and the integrations, plus the parts specific to you.
Buy now, build later. Using a product for six months teaches you what you actually need, which is almost never what you specified at the start. Building second is cheaper and better targeted than building first.
Build the thin part only. A small script calling a maintained platform's API is a very different commitment from building the platform.
Mirage Cloud sits in this space for small businesses, with pre-built agents plus a bespoke agent service for workflows that do not fit the standard set. That pattern, maintained infrastructure with a custom layer, is generally the right shape for a company without a platform team.
The question that settles it
Not "can we build this." A competent developer can build most of it.
Ask instead: who maintains this in eighteen months, and is that a good use of their time?
If there is no clear answer, the decision is made. If the answer is a named person whose job this legitimately is, building may well be right.
Then check the arithmetic honestly. Build cost plus 20 percent of a developer's time indefinitely, against a subscription. The subscription usually wins for generic workflows and usually loses for genuine differentiators, and the mistake is almost always misclassifying which one you have.
Top comments (0)