Build vs buy for small teams: when a subscription beats custom code

There is a moment every technically capable small team knows: you are evaluating some tool — a scheduler, a dashboard, a form builder, an inventory tracker — the pricing page wants forty dollars a month, and a voice says we could build this in a weekend. The voice is not wrong about the weekend. It is wrong about everything after the weekend, and the gap between those two truths is where small teams lose quarters of productive time. The opposite failure is quieter but just as real: teams that buy a subscription for every itch until the stack costs more than an employee, breaks in combinations no vendor will take responsibility for, and holds the business's data hostage across a dozen export formats.

Build versus buy is genuinely a decision, not a doctrine, and the teams that get it right are the ones doing honest accounting on both sides. This article is that accounting: what building actually costs once you include the part everyone omits, what buying actually costs once you include the parts the pricing page omits, the core-versus-context question that resolves most cases in under a minute, and the newer wrinkle — AI-assisted coding has made the weekend voice more persuasive than ever, while changing the long-run math much less than it appears to. The framing throughout is small-team specific, because the trade-offs at three people are different in kind, not just degree, from the enterprise version of this debate.

The build estimate that fuels the weekend voice covers version one: the happy path, working, demoed to yourself. The real cost structure of owned software starts after that. Every external service it touches will change an API eventually. Every dependency will need security updates on a schedule you do not control. Every edge case your weekend skipped — time zones, unicode, the file that is too big, the webhook that arrives twice — will surface as a small emergency on a day you had other plans. Industry experience keeps converging on the same uncomfortable ratio: across a piece of software's life, the initial build is a minority of the total cost, with maintenance taking the majority — often cited at sixty to eighty percent. The weekend was not the price; it was the down payment.

At small scale, the tail has a second, sharper property: it concentrates in one person's head. The teammate who built the internal tool becomes its permanent on-call engineer, its documentation, and its single point of failure — a bus factor of one, attached to infrastructure the business now depends on. When they are on holiday, the broken sync waits. When they leave, the tool becomes a haunted house nobody wants to enter. And the opportunity cost compounds quietly: every hour spent maintaining the homegrown scheduler is an hour not spent on the product customers pay for, which is the one thing nobody else can build for you. None of this means never build — it means the build option must be priced as years of ownership, not days of construction, and at that price most conveniences stop being worth owning.

The subscription's listed price is its most honest cost; the others take longer to see. First, it is rent: it never ends, it rises — per-seat pricing climbs as you grow, the plan you need next always exists one expensive tier up, and the cumulative spend on a tool you keep for six years can exceed building it several times over without the asset ever becoming yours. Second, lock-in is real even when exports exist: your workflows bend to the tool's shape, your history accumulates in its database, your integrations assume its API, and the cost of leaving grows every month in a way that the vendor's pricing team understands perfectly well. Third, vendors die, get acquired, pivot, or sunset the feature you depended on — and you have no vote.

Fourth, and most operationally aggravating: the gap. The bought tool does ninety percent of what you need, and the missing ten percent generates a permanent residue of workarounds — the spreadsheet that reconciles two systems, the manual step everyone has to remember, the duplicate data entry. Stacks of almost-right tools are where small-team hours quietly disappear, and the workaround tax should be priced into any buy decision alongside the subscription itself. The honest summary of buying: you are trading capital cost for operating cost, ownership for liability transfer — the vendor carries the maintenance tail, the security patches, the uptime pager — and accepting in exchange rent, lock-in, and the gap. For most context tools, that is a good trade. The point of listing the costs is not to scare you off buying; it is to make the comparison symmetrical.

The fastest correct filter comes from an old strategy distinction: is this capability core — part of how the business wins, something customers experience as differentiation — or context — necessary, but indistinguishable from how every other business does it? Your accounting, scheduling, email delivery, password management, and calendar booking are context: doing them brilliantly wins you nothing, doing them adequately is fully sufficient, and a thousand vendors compete to do them adequately for forty dollars a month. The capability that makes customers choose you — the product itself, the data pipeline that powers your differentiating feature, the workflow that produces whatever you are known for — is core, and outsourcing core means renting your identity from someone who also rents to your competitors.

The rule then writes itself: buy context, build core, and spend your scarce engineering hours exclusively where ownership compounds into advantage. Most real decisions fall instantly: the team agonizing over building an invoicing tool is misallocating attention (context — buy it and move on), while the team trying to find a SaaS that replicates their unique fulfillment logic keeps discovering that no vendor models their actual business (core — that gap is the differentiation talking; build it). The cases that resist the filter are the hybrids — a context-shaped tool wrapped around core-shaped data, like the dashboard that is generic except for the proprietary metrics flowing through it. Hybrids usually resolve by splitting: buy the generic shell, build the thin specific layer, and keep the boundary clean so you can swap the shell later.

Build and buy are poles, and a lot of small-team reality lives between them. Self-hosted open source buys you out of the rent and most of the lock-in — the software is yours to run forever — at the cost of becoming your own vendor: you do the updates, the backups, the security patches, the server. For a technical team, that trade is excellent for a few load-bearing context tools with strong communities, and miserable as a default for everything (ten self-hosted services is a part-time infrastructure job nobody budgeted). Managed hosting of open tools — paying someone to run the open thing — is often the best two-out-of-three deal available: someone else's pager, your data's freedom, modest rent.

Low-code platforms and automation glue (the spreadsheet-as-database tools, the workflow connectors) occupy a different niche: they make context workflows buildable in hours by whoever owns the process, no engineer required. Used honestly — small internal workflows, prototypes, the connective tissue between bought tools — they are the cheapest possible way to close the ninety-percent gap from the previous section. The failure mode is success: the no-code workflow that grows until the business runs on an undocumented tangle of automations nobody fully understands, which is the homegrown-tool problem wearing a friendlier interface, bus factor and all. The discipline is the same as for code: when a glued workflow becomes load-bearing, either document it like the SOP it is and assign it an owner, or graduate it to something properly built or properly bought.

The honest update for the current decade: AI coding assistants have collapsed the cost of version one. The weekend project is now a Saturday project; the internal dashboard that wasn't worth a week is worth an afternoon of prompting and review. That is a real change, and it legitimately moves some decisions — the threshold for building small, disposable, internal conveniences has dropped, and a team that treats AI-built tools as cheap and replaceable (rebuild it next year in another afternoon rather than maintaining it) can rationally build things that were not worth building before. Disposability is the key reframe: if the artifact is cheap enough to regenerate, the maintenance tail can be partially evaded by simply never maintaining — rebuilding instead.

What AI assistance changes much less is everything that made the tail expensive in the first place. The generated tool still has dependencies that rot, APIs that drift, edge cases that surface in production, and — critically — it still concentrates understanding in whoever prompted it, except now that person may understand the internals less than a hand-author would have, which makes debugging the eventual failure stranger, not simpler. The vendor's real product was never the code; it was the liability transfer — the pager, the patches, the compliance, the uptime promise — and no assistant generates that. So the updated rule is a refinement, not a revolution: AI lowers the build threshold for small, disposable, internal things, and barely moves it for anything load-bearing, customer-facing, or compliance-touching. The teams getting burned are the ones who heard "building is cheap now" and applied it to the second category.

When a real decision arrives and the core-context filter has not already settled it, run the comparison symmetrically over a three-year horizon — long enough for the tails and the rent to both show up, short enough to be estimable. On the buy side: subscription cost at your realistic growth (not today's seat count), plus the workaround tax for the gap, plus a switching-cost estimate for the lock-in you are accepting. On the build side: construction at an honest multiple of the optimistic estimate (doubling it is traditional and still usually generous), plus the maintenance tail priced at that sixty-to-eighty-percent-of-lifetime figure, plus the bus-factor risk if it lands on one person, minus whatever genuine strategic value ownership creates. Then compare not just the totals but the shapes: buy is flat and predictable, build is front-loaded with a long uncertain tail, and a small team's tolerance for tail risk is usually lower than its spreadsheet admits.

Two meta-rules improve every decision the worksheet touches. First, default to buy for anything urgent: you can always build later with full knowledge of what the bought tool got wrong, and "we will replace it with our own when it hurts" is a fine strategy that costs nothing today — whereas un-building a failed custom tool while the business depends on it is surgery. Second, audit the subscription stack twice a year with the same skepticism applied to build proposals: list every recurring charge, ask what each would cost to drop, downgrade, or consolidate, and kill the zombies — the tools still billing for a workflow that no longer exists are the purest waste in the entire stack. Build versus buy is not a single decision but a portfolio you rebalance: rent the context cheaply, own the core deliberately, and keep the engineering hours pointed at the only software nobody else can build — yours.

Step back from the worksheets and a pattern emerges in teams that consistently get this right: they are stingy with ownership and deliberate about it. They own remarkably little — a focused core where ownership is the strategy, a handful of well-chosen rentals around it, thin documented glue in between — and what they own, they own completely: documented, tested, with more than one person able to hold it. Their opposite owns everything a weekend voice ever suggested, maintains none of it well, and pays rent on top for the tools that were supposed to be replaced by the weekend projects. The difference is not technical ability; it is the discipline of treating every "we could build this" as the start of a costing exercise rather than the end of one.

If you want the entire article as a habit rather than a framework: whenever the voice says we could build this in a weekend, answer it with the second question — and who maintains it in year two? If the answer is "nobody needs to, it is disposable," build it and enjoy the new economics of cheap software. If the answer is a specific person's name said with confidence, you may have found genuine core worth owning. And if the answer is a shrug, the pricing page you were trying to escape is showing you what the shrug costs per month — which, most of the time, is the bargain.