Build or buy? When a tool your AI agent builds beats the software you'd pay for

For twenty years the sensible answer to "should we build this ourselves?" was no. Building meant an engineer for a quarter, and then that engineer forever. Unless the tool was the business, you bought something close enough and bent your process to fit it.

That answer was about cost, and the cost has changed. A coding agent such as Claude Code, Codex or Cursor builds a working internal tool in an afternoon, for someone who has never deployed anything. So the question is worth asking again, and the honest answer is: it changes for one kind of software and not for the rest.

We make Spryloom, which runs tools like these for the team that built them, so we have a side in this. We'll say where buying is still right, because it often is.

What got cheap, and what didn't

Two things were always bundled together under "building it":

Writing the software. This is what collapsed. A tracker, an approval flow or a dashboard that took weeks now takes hours.
Running the software. A place for it to live, a login so only the right people get in, a database that keeps what they type, and someone who notices when it breaks. None of this got cheaper because an agent wrote the code.

So the old question, "can we afford to build it?", has mostly gone away. The question that replaced it is "is this worth running?" Everything below follows from that.

The line between buy and build

The useful test is not how complicated the tool is. It is how many other companies have the same problem.

The more particular the problem is to you, the less likely anyone sells a tool for it, and the better building looks.

A vendor builds a product when thousands of companies share a problem. That is why payroll software is excellent: the problem is the same everywhere, the rules are written down by governments, and a company has spent years getting them right. Nothing an agent builds in an afternoon competes with that, and it shouldn't try.

The other end of the line is where no vendor will ever go, because the market is one team.

Buy when the problem is everyone's

Buying is still the right call when:

The process is standard. Payroll, accounting, a CRM, a help desk, HR records. If you would describe your need with the product category's own name, buy the product.
Rules change and someone must keep up. Tax tables, privacy law, payment card rules. You are paying the vendor to read the regulations so you don't have to.
It is the system of record. The one place the truth about money, customers or employees lives, for years. That deserves a vendor with backups, audits and a support line.
You'd need it to pass an audit. An auditor will accept a named, certified product far more easily than a tool one of you made.
Many other tools must connect to it. A product with two hundred integrations took a company years to build.

If your agent-built tool is a slightly worse copy of something you can buy for a reasonable price, buy it. A homemade expense system is not a win.

Build when the problem is only yours

Building wins when the tool passes most of these four tests:

Nobody sells it. The process is particular to your company: the seven steps you follow to approve a supplier, the comparison someone does by hand every Friday, the thresholds in your discount policy. You searched and found only general tools you'd have to bend.
Few people use it. Three, five, twelve. Too small a market for anyone to serve, and small enough that the tool can be simple.
It may not live long. A dashboard for a six-week migration. A tracker for one office move. An approval flow for one client engagement. Software with an end date was never worth a purchase order, and now it doesn't need one.
The bought alternative means bending. You are paying per seat for a product and using a twentieth of it, or running the real process in a spreadsheet beside it, with reminders in chat.

Some examples that pass all four:

Every Friday, a job compares what merged in GitHub with what the plan in Linear said, and emails six people the exceptions.
Two analysts review the 400 rows a model was unsure about, one at a time, and their answers are saved.
A client needs legal, then brand, then the regional lead to approve each deliverable. It exists for the engagement and is removed after it.

None of these is hard to build. They were never built because each cost more than it saved. That arithmetic is what changed.

The costs people forget

Both sides have costs that don't appear on the first day.

When you buy:

Seats for people who only look. Per-seat pricing charges the manager who opens the tool once a month the same as the person who lives in it.
The time to buy. Trials, security review and procurement can take longer than building the small version would.
Bending the process. The tool has opinions. Where they differ from yours, people keep a spreadsheet on the side, and now there are two sources of truth.
Leaving. Check what you can export, and in what shape, before the data is in.

When you build:

Running it. The login, the database, the address, the certificate. This is the part the agent didn't do, and the reason most agent-built tools never leave the laptop they were made on.
Who fixes it. If the person who built it leaves, can someone else change it? A tool an agent built from a clear description is easier to hand over than one a person wrote from memory, but only if the description and the code are kept somewhere.
The data in it. A tool that five people rely on holds data somebody would miss. Decide where it lives and whether there is a copy.
Who can get in. A tool on a public address with a password in the page is not protected. Access should be checked before anything is served, by a person's own email, and removable per person.

The pattern in the second list is that none of it is about the software. It is all about running it, which is why "is this worth running?" is the real question.

A quick way to decide

	Buy a product	A shared spreadsheet	Build with an agent
A process every company has	Yes	Outgrown fast	A worse copy
A process only your team has	Not sold	Until it needs rules	Yes
Needed for a few weeks	Slower to buy than to use	Yes	Yes
Steps, owners and reminders	If it matches yours	By hand	Yes
The record an auditor checks	Yes	No	Not yet

A filled dot is a good fit, a ring works with effort or only in some cases, and a dash is a poor fit.

The spreadsheet deserves its column. For a short-lived list with no rules, it is still the right tool, and nothing here argues otherwise. It stops working when the process has steps: this goes to her, then to him, and somebody is reminded on Thursday.

Where Spryloom fits

Spryloom is the "running it" half. Your agent builds the tool; one command gives it an address, a database of its own, and a sign-in for the people you invite.

npm install -g spryloom
spry login --email you@yourcompany.com
spry publish .

Publishing Expense Notes

  ✓ Runtime created
  ✓ Database created
  ✓ Sign-in enabled for yourcompany.com
  ✓ HTTPS enabled

https://expense-notes.yourcompany-com.spryloom.app

A new tool opens only for you. You invite coworkers by email, they sign in with a link sent to their own address, and the tool itself contains no login code. It can run a job on a schedule and send email, which covers the "every Friday" and "remind the owner" cases above. A report or a prototype with no saved data publishes as a page in a few seconds.

The use cases page has three examples per team, each with the sentence to give your agent.

What it doesn't do

It doesn't replace the products in the "buy" list. It runs the small, particular tools around them. It is not your payroll or your accounting system.
No backups yet. Start with data you could replace, and don't make a Spryloom app the only copy of something you can't lose.
Node only, for now. Apps run on Node, with a static or React front end. Python is planned and not built.
No file uploads, and sign-in is by email link. There is no "Sign in with Google" yet.
Outside services come from a list. An app can reach GitHub, Linear, Slack, Stripe, Notion, Airtable, HubSpot, Google Sheets and a few AI providers, and nothing else, so a tool that needs another service has to wait.

The short version

If this is true	Lean towards
You'd describe it with a product category's name	Buy
Regulations change it, or an auditor will check it	Buy
It is a list with no steps, for a few weeks	A spreadsheet
Only your team has this process	Build
A handful of people need it, or it has an end date	Build
You are paying per seat and using a sliver of the product	Build the sliver

The old rule was "don't build what you can buy". It still holds. What's new is the large amount of software you could never buy, because it was only ever for you, and which now costs an afternoon to make.