AI coding agents made custom software fast to build, which shifts the answer in any build vs buy software assessment. A small internal tool that used to take weeks of engineering time can now be ready in days, sometimes hours. That changes which tools are worth building. It doesn't mean you should build everything.
We use two questions for every tool a team pays for:
- If it breaks, how much does it hurt?
- How many other systems does it touch?
Low on both? Build it. High on either? Keep paying for it.
Not sure which square a tool sits in? Email it to hello@firstmate.tech.
Question 1: If it breaks, how much does it hurt?
Picture the tool down for a day. A broken weekly report goes out a day late. A broken login system can let the wrong people in.
Tools that hurt when they break usually move money, hold data you can't recreate, or carry legal weight. Payments, payroll, accounting and backups all sit here. The companies that sell them have spent years on the edge cases: refunds, tax rules, failed transfers, restores at 2am. That work is the product you're paying for.
Tools that break quietly are the opposite. If the internal tracker is down, someone updates a spreadsheet for a day and nothing is lost.
Question 2: How many other systems does it touch?
A self-contained tool fails on its own. A tool wired into your logins, payroll and customer data fails everywhere at once.
Every connection is something that has to keep working after launch. Another service changes its API, a token expires, a field gets renamed. A tool with one or two connections is easy to keep alive. An email marketing tool that syncs with your sign-up forms, customer list, website and billing is a full-time job, and that job is what the vendor is doing for you.
Reading the grid: SaaS vs custom software
| If it breaks | Systems it touches | Examples | Verdict |
|---|---|---|---|
| Quietly | Few | Internal tracker, approval flow, weekly report, office attendance | Build it |
| Badly | Few | Accounting, backups | Keep buying |
| Quietly | Many | Email marketing, website analytics | Keep buying |
| Badly | Many | Logins and access, payroll, payments | Keep buying |
Three of the four squares say keep buying. Most of your stack should stay bought. The opportunity is the one square that used to be too small to bother with.
A quick build vs buy software assessment
Run each tool on your list through these questions. If either of the first two answers lands in the right-hand column, keep buying. The other rows settle close calls.
| Question | Points to build | Points to buy |
|---|---|---|
| If it's down for a day, what happens? | Someone uses a spreadsheet | Money, data or legal exposure |
| How many other systems does it connect to? | One or two | Many, and they change often |
| How much of the product do you use? | A small slice | Most of it |
| Does the tool fit how your team works? | No, you work around it every day | Yes, mostly |
| Who owns it after launch? | A named person or team | Nobody |
| Is there a clear point where you'd switch to buying? | Yes, written down | Can't say |
A tool you only use a slice of, that your team fights every day, and that breaks quietly is the strongest case for building.
What AI changed about build vs buy software
Before coding agents, building even a small tool meant weeks of an engineer's time. For a weekly report or an approval flow, that never added up. So teams paid per seat for something close enough, or kept the spreadsheet, and bent their process to fit.
Now that small tool can be built in days, shaped around how your team actually works. What AI didn't change is the cost of a tool breaking or the work of keeping integrations alive. So more tools now fit the build square, and it's worth replacing some SaaS with custom software. The other three squares stay where they were. Knowing which is which is part of the build-vs-buy judgment our product-minded AI engineers bring to a project. If you already have one in mind, the MVP cost calculator scopes it and estimates the build time in a few minutes. For what drives the price of a bigger build, see how much it costs to build an MVP in 2026.
Two small internal tools we built
Our office attendance app. On office days our team used to sign in through a form. One of our engineers replaced it with a small app built with AI coding agents in a few hours. You sign in with your company Google account, tap once, and the entry lands in a Google Sheet. It connects to Google sign-in and a Google Sheet, and if it broke, we'd go back to the form for a day.
A client's spec sheet updates. After every sample review, someone on the client's team types the notes and changes by hand into the spec sheet the factory builds from. They keep paying for the big systems that run their orders. We built a working prototype of the small piece in between: the notes go in once, the app drafts the update, and a person approves it. Every save is a new file, so the original is never touched.
When to stop building and start buying
A tool can move squares as you grow. We built our own Slack pager in about two days: type a command and an engineer's phone rings until they answer. For a small team that's enough. But its README says that the moment we need on-call rotations, we should stop extending it and adopt a dedicated on-call tool.
Write that line down for anything you build. Decide up front what would make it worth buying instead, so the tool doesn't quietly grow into the thing you were avoiding.
Should you build your own CRM?
Usually not. A CRM is high on both questions. Losing your customer history hurts, and it connects to email, calendars and billing, so it belongs with the tools you keep buying. The exception is a team using a small slice of one, like a short list of deals and who owns them. That slice can be a simple tracker. The day you need email sync or forecasting, go back to buying.
Who looks after a tool you build?
Someone has to. A built tool needs an owner who fixes it when it breaks and changes it when your process changes. Small tools need little upkeep, but not none. If nobody on your team can own it, that's a reason to keep buying, or to have the people who build it look after it too. We settle that before we build anything: who owns it after launch, and what would make it worth buying instead. It's also why we test what we build: here's how we test AI-generated code.
Want a second opinion on your stack?
Send us your list of tools and the workarounds your team lives in at hello@firstmate.tech, and we'll tell you which ones are worth building.
Building something with AI?
First Mate is an AI engineer agency. Our product-minded AI engineers scope the problem before they build it. You can start with a rough cost and timeline, or talk to us directly.
