For about fifteen years, the correct default for a software team was to buy. Any internal need, whether tracking, scheduling, dashboards, or approvals, had a SaaS product behind it. The product was cheaper than an engineer’s time, and building your own was a sign you had not learned the lesson everyone else had already learned. Buy, integrate, move on. It was good advice, and for most of those years it was right.
It is quietly stopping being right, and the reason is not ideological. It is arithmetic. Three numbers in the build-versus-buy calculation have all moved in the same direction at once, and most teams have not rerun the sum since the inputs changed.
This is not an argument to build everything. Building everything is its own expensive mistake, and we will get to where the line actually sits. It is an argument to rerun the calculation, because the version most teams are still using is several years out of date, and a stale calculation produces confident wrong answers.
What changed
The cost of building dropped. Not by a little. A competent engineer with Cursor open can stand up an internal tool, a real one with a database, an interface, and authentication, in a fraction of the time the same tool would have taken five years ago. The boring parts that used to eat the schedule are now mostly handled by the framework or the assistant. For lighter data-driven UIs, Retool or Internal.io let a non-engineer wire a CRUD interface to a Postgres database in an afternoon. Glide and Softr take that further, generating mobile-ready interfaces over Airtable or an existing database with no code at all. Bubble handles more general app logic. For teams with engineers, AI-assisted editors like Cursor and GitHub Copilot compress the work on custom queries and business logic; for larger structural changes, tools like Claude Code handle refactors that used to require a sprint. The build estimate you carry in your head is probably the estimate from the last time you actually built something, and that estimate is stale. Most teams are quoting themselves 2021 prices.
The cost of buying rose. Per-seat pricing was designed for a world where you bought one or two tools. Teams now run thirty or forty, and each one renews annually with a quiet increase. Worse, the pricing model has drifted. The feature you actually need has a habit of living one tier above the one you are on, so you pay for a whole bracket of capability to reach a sliver of it. Add it up across the entire stack and the number is genuinely surprising. Most teams have never added it up, which is itself the problem.
The cost of integration rose. This is the number teams miss entirely, because it never arrives as an invoice. Every tool you buy is a tool you must connect to the others, keep in sync, govern, and account for when something three steps away breaks. Zapier works well until you hit its task limits and the per-task cost starts to compound; at that point, teams often move to Make (formerly Integromat), n8n on a self-hosted instance with flat pricing, or Pipedream for code-first workflows. That migration itself costs something. Forty tools is not forty problems. It is the set of all the ways forty tools can disagree with each other, and that set is much larger than forty. Every new subscription quietly raises the cost of every existing one.
There is a fourth shift, harder to put a number on. The reversibility gap has narrowed. A few years ago, building meant a long commitment to code that only one person fully understood. Today a small, well-scoped internal tool is genuinely cheap to throw away and rebuild. Supabase gives you Postgres, auth, and file storage in a single project you can spin up in minutes; Pocketbase ships as a single binary with SQLite and a built-in admin UI; Neon gives you serverless Postgres with branching, so you can test schema changes without risking production. The infrastructure to stand something up and then abandon it has never been cheaper, which means a build decision is no longer a one-way door. That changes the risk calculation as much as the cost one.
Run those four shifts together and the build-versus-buy line has not vanished. It has moved. The set of tools that are now cheaper to build than to keep renting is meaningfully larger than it was, and it grows a little every year.
The framework
So which tools fall on which side of the line. We use four questions, in order, and we stop at the first one that gives a clear answer.
One: how specific is the workflow? This is the most important question by a wide margin. A bought tool is a frozen average of how a thousand companies do something. If your process is close to that average, whether payroll, email, or video calls, buying is correct and building would be vanity. But if your process is unusual, and the unusual part is where your actual advantage lives, a bought tool forces a bad trade. You either contort your process to fit the software, or you pay, in workarounds, for the gap between them. Build the tools that touch the work you do differently from everyone else. Buy the rest without guilt.
Two: how stable is the need? Some needs change every quarter as you learn. Others have not changed in three years and will not change in three more. Counterintuitively, the stable needs are the better build candidates. A tool for a stable need is built once and then quietly amortizes for years. A tool for a volatile need is a maintenance commitment that never ends, and a vendor whose entire job is to absorb that volatility starts to look like a bargain. Build the boring, settled things. Rent the things still in motion.
Three: what does the integration actually cost? Sometimes you buy a capable, fairly priced tool and still lose, because making it talk to your other systems is its own permanent project. A modest tool you built, sitting directly on your own database with no sync layer and no webhook glue, can beat a better bought tool that has to be wired in and rewired every time an API changes. Count the wiring. The wiring is real, and it is the cost teams most reliably forget.
Four: who carries it afterward? Every built tool needs an owner. Not a person who fixes bugs, but a person with the authority to refuse features. If you cannot name that person before you start, do not start. Buy instead, and let the vendor be the owner. An unowned internal tool does not stay small. It accumulates scope until it is its own small, unloved product, and then it is worse than the thing you were avoiding.
These four questions are not meant to produce a surprising verdict. They are meant to make you state the reasoning out loud, because a decision you can explain is a decision you can revisit later without re-litigating it from scratch.
The framework applied: an analytics dashboard
Take a concrete example. Your team needs a dashboard showing pipeline conversion, support ticket volume, and revenue by cohort. You use this every week in a Monday review. The data lives in your own Postgres instance.
Run it through the four questions. Question one: is the workflow specific? Weekly pipeline reviews are standard. The data schema, though, is yours, and the metrics you care about are composed in a way that does not map cleanly to any off-the-shelf chart. Slightly specific, but not decisively so. Question two: stability? You have been reviewing the same five metrics for eighteen months without changing the definition. Stable. Question three: integration cost? If you buy, you need a data connector to your Postgres instance and ongoing maintenance when the schema changes. If you build, the tool reads directly from the same database. Question four: owner? Your head of operations already manages the Monday review and has the context to refuse scope creep.
Three of four questions point toward build. Here is what that actually looks like in practice. The build path: Retool connected directly to your Postgres database, custom SQL queries written in the Retool query editor or refined with Cursor for anything complex, deployed in about three to five days of engineering time. Cost: Retool’s free tier covers small teams; the business tier runs around . The buy path: Metabase Cloud or Mode, one-day setup, approximately $150 to $500 per month depending on seat count and tier, plus the time to configure the data connection and rebuild your metric definitions in their query language. At small team sizes, Metabase or Mode wins on speed to first chart. At the point where the custom metric logic becomes load-bearing, and especially once the database schema is something your team controls entirely, the Retool build stops feeling like a project and starts feeling like a normal part of the codebase.
The four questions do not always land this clearly. Sometimes question one terminates the whole exercise immediately. A CRM is a maximally standard workflow: use HubSpot or Pipedrive, configure it, move on. A help desk is the same: Intercom or Zendesk exists precisely so you do not have to think about this. For accounting, Xero or QuickBooks has absorbed decades of compliance complexity you genuinely do not want to reconstruct. Auth for a compliance-heavy product belongs to Auth0 or Clerk, not to a bespoke session handler someone built before they fully understood PKCE. The point of the framework is not to surface clever build candidates. It is to rule out the obvious buys quickly, so you have real attention left for the middle cases.
Build the tools that touch the work you do differently from everyone else. Buy the rest, and do not feel clever about either decision.
What this looks like in practice
For most small teams, applying the framework honestly produces a stack in three layers.
There is a layer you should always buy and never reconsider. Email, calendars, video, payroll, accounting: the operating-system-level tools. These are maximally standard, maximally stable, and ferociously well served by vendors who have spent a decade on them. Building any of them would be a story you tell against yourself later.
There is a layer you should always build, or at least always seriously consider building. The tools that sit directly on top of the specific way you work. The thing that encodes your particular pipeline, your particular review process, your particular definition of a customer. These are the tools where a bought average actively costs you, because the non-average part is the part that matters, and no vendor will ever model it for you. For teams comfortable with a little code, Supabase as the backend and Retool or a Lovable-generated frontend as the interface gives you a working v1 without much ceremony. For teams with almost no engineering bandwidth, Airtable as the database with a Softr or Glide layer on top gets surprisingly far for surprisingly little.
And there is a wide, genuinely contested middle layer, where the answer depends on this quarter’s numbers and should be revisited as they move. The framework is most useful here. The mistake is not landing on the wrong side of a middle-layer decision once. The mistake is never deciding at all, defaulting to “buy” because that was the right default in a calculation you ran years ago and have not run since.
A useful exercise: take your current tool list, mark each tool with the layer it belongs to, and look hard at the middle. That is where the savings and the risks both live.
The cost nobody quotes you
Honesty requires the other side of this.
A built tool has no price tag, which is exactly what makes it dangerous. A bought tool announces its cost every month. You can see it, resent it, and cancel it in ninety seconds. A built tool’s cost is silent and ongoing: the bug nobody is assigned to, the dependency that needs updating, the new hire who needs the tool explained because there is no documentation and no support article and no one whose job it is to write either. That cost is invisible, and invisible costs are the ones that quietly compound until someone finally notices the team is spending a day a week maintaining its own software.
So the framework is not “build more.” It is “build deliberately, and account fully.” Before you build, write down two things: who owns the result, and what you expect to spend keeping it alive, not just making it. If you cannot answer both, you have not found a build candidate. You have found a reason to buy.
The teams that get this right are not the ones who build the most. They are the ones who buy the standard layer without guilt, build the specific layer without hesitation, and treat the middle as a live decision they rerun on purpose. The default of the last decade, buy everything, was a reasonable answer to the conditions of the last decade. The conditions changed, and the Retool dashboard your team would have farmed out to a BI vendor in 2020 now takes a few days and costs less per month than a single Metabase seat.
