When I tell people to keep paying for SaaS.

A man who sells rain gauges will find you a drought. I build custom software for a living, so “you should probably build” is the least surprising sentence I could say to you. It’s also the least useful, until you’ve seen the cases where I say the opposite. Those cases exist. Some scoping calls end with me recommending the subscriptions the caller came in wanting to replace, and those calls aren’t failures. They’re the reason the other calls can be trusted.

§1Why you should distrust this advice

Every build-versus-buy article you’ll find is written by someone selling one of the two answers. The enterprise frameworks come from platform vendors; the “always go custom” posts come from agencies. Mine comes from a developer who charges $8,000 to $40,000 per build, so treat it accordingly: don’t trust my intentions, check my criteria. That’s what this entry is — the refusal rules, published, dated, and specific enough to hold me to. If I ever recommend a build that fails these six tests, you’ll have this page to quote at me.

One structural note keeps the incentives roughly aligned. My scoping week is unpaid, and the deliverables from it are yours either way. When the week ends in “don’t build,” I’ve spent five days to earn nothing but the right to write entries like this one. It’s not sainthood — it’s the cheapest marketing I know of, and it only works if the advice stays real. A single client who catches me recommending an unnecessary build burns the whole mechanism down.

Two wrong ways to read this entry, flagged in advance. It isn’t permission to never build; the status quo has a lobby too, and §8 covers when the answer flips. And it isn’t a gauntlet where failing one test shames you back to your subscriptions. Most of these “no”s are “not yet”s with a named condition attached — watch the condition, not the calendar.

§2You need it live this week

Custom software takes 6–8 weeks for most projects, and rushing it produces the tangled, undocumented systems that other entries on this site warn you about. A subscription takes an afternoon. If the need is real and the deadline is now, rent — urgency is a legitimate reason, not a character flaw.

What I’d add, and what the vendor won’t: treat it as a sequence, not a settlement. Rent the tool today, run your process through it for six months, and let it teach you what you actually need. The workaround spreadsheets that accumulate next to it become the specification for the build, if a build ever earns its case. Rent-then-own is how several of my scoping conversations started; the subscription was the prototype nobody had to design. The mistake isn’t renting under deadline. It’s the auto-renewal doing your annual strategy review for you, silently, at 12.2% a year.

Done deliberately, the bridge has a shape. Month zero: rent the closest tool, configure it properly, move the work in. Months one through six: run everything through it, and keep a file of every workaround the team invents. Month six: read the file. If it’s nearly empty, you’re in §4 territory: the tool fits, keep it. If it’s thick, you’re holding a specification. Six months of subscription fees turn out to be the cheapest requirements document money can buy. A rushed build’s cut corners would have been permanent; the bridge is disposable by design. One warning for the bridge months, though: don’t customize the rented tool so deeply that leaving it becomes its own project. Light configuration, yes. A thousand hours of custom formulas inside someone else’s platform is a build — just one you don’t own.

§3Your process still changes monthly

Custom software encodes a process — that’s its entire advantage and its entire risk. Build while the process is still moving and you’re pouring concrete around wet clay. Every pivot afterward is a change order: quoted, built, tested, redeployed. A subscription’s configurability, the exact thing that makes it almost-fit a stable business, is what makes it right for an unstable one. Toggling a setting is cheaper than commissioning one.

The test I use on calls is simple to run yourself: has the workflow survived the last three months without a structural change? Not tweaks — structure. Who does what, in what order, decided by what. If the answer is no, keep renting and revisit in a quarter. Building custom for a monthly-changing process is renting from me at worse terms, and I say that sentence out loud on calls because it’s true.

“Structural” has edges, so here are three changes that count and one that doesn’t. Adding an approval step before jobs go out: structural. Changing who assigns work, or what triggers an invoice: structural. Renaming statuses and reordering a form: cosmetic — build through it. And notice that a moving business usually has a still center. The churn lives at the edges, in pricing experiments and marketing tools. The core ledger (jobs in, work done, money owed) hasn’t changed shape in years. A build can target the still center and leave the moving edges rented. That split, stable core owned and volatile edge rented, is how several of my builds are actually scoped.

§4The tool genuinely fits

Some tools earn their line on the bill forever. I have never once proposed replacing Slack. At $7.25 per user per month, it does its one job too well to compete with. A custom chat system would be an expensive way to get fired from your own project. A standard online store belongs on Shopify, whose Basic plan runs about $29 a month. The checkout, fraud, and payment problems it solves are ones you should be delighted to outsource. Accounting, payroll, email — solved problems, priced fairly, maintained by someone else. Renting them is the correct answer, full stop.

The line I actually watch for is almost. A tool that fits gets used quietly. A tool that almost fits grows a shadow system around it. The export-to-Excel ritual every Monday. The “don’t touch column F” spreadsheet. The person whose actual job title should be “human integration.” When Zapier at $19.99 a month glues two tools together, that’s the product working. When there are eleven zaps, three of them broken silently and one maintained by someone who left, the glue has become load-bearing. That’s the tell. It has a number, too. When the connectors cost as much per month as the tools they connect, the stack is telling you its shape is wrong. Fit is measured by the absence of workarounds, not the presence of features.

So audit for workarounds, not satisfaction. Nobody loves their tools; the question is whether anyone is compensating for them by hand, on a schedule, in a spreadsheet with a superstitious name.

Price the workarounds while you’re at it, because they’re the invisible half of the subscription. Three hours a week of hand-moving data is roughly 150 hours a year. At any wage you care to assign, that dwarfs most tool bills. The audit takes one week and no consultant: every time someone moves data between two tools by hand, they add a tally mark. Seven days of tally marks prices the “almost” in almost-fits better than any feature comparison ever will.

§5The math says rent

Below a certain spend, the five-year arithmetic just doesn’t close, and pretending otherwise would contradict the entry where I do that arithmetic in public. My two published floors: if your relevant software spend is under $300 a month, or your build budget is under $5,000, keep renting. Under those numbers, payback stretches past 24 months and past the point where switching earns its keep. The homepage triage table says the same thing in one row. The calculator will say it with your own numbers; it prints “keep renting” when renting wins, and that’s not a bug.

What to do instead, since “you’re too small to build” is useless alone: spend one afternoon configuring the tool you already pay for. Most almost-fit pain at small scale is a settings problem wearing a software problem’s clothes. An unused field. A default view nobody changed. A report that exists but was never scheduled. The vendor’s own onboarding docs, read once properly, are the cheapest consultant you will ever hire.

The floor in numbers, once. A flat $200 a month at the same 10% yearly increases is $14,652 over five years. An $8,000 build with $50 hosting doesn’t cross even with it until around month 44. The math technically closes. But a 44-month payback is a different bet than a 20-month one. Past two years, the business, the tools, and the assumptions have all moved. The floor isn’t where building becomes impossible. It’s where the bet stops being safe, and I’d rather not sell unsafe bets.

One exception, so the rule doesn’t overreach. The calculator counts costs, and some tools cap revenue instead. A booking tool that can’t take deposits never shows up as a software cost; it shows up as empty Tuesday slots. If the constraint you feel is lost sales rather than monthly fees, the $300 floor doesn’t apply. Bring the revenue numbers to the call instead.

§6The idea is unproven

If the process you want to encode has never survived contact with real customers, custom software is certainty you haven’t earned yet. This is the whole argument of Eric Ries’s The Lean Startup (2011). Validate with a minimum viable product, the smallest thing that tests the idea, before building the real thing. Rented tools are the natural MVP kit. A form builder, a spreadsheet, a $29 store, and manual effort behind the curtain will answer the question in a month. A $20,000 build answers the same question in a quarter, at a hundred times the price of being wrong.

My incentive admission, since this entry runs on them: I also prefer it this way. A build specified from a validated, running process is a build that ships on schedule and survives its warranty quietly. A build specified from a founder’s guess is a change-order machine. When the idea proves out, the rented-tool version becomes the specification: real fields, real edge cases, real volume numbers. The custom version gets built once, correctly, instead of twice, expensively.

What “proven” means, concretely, since it decides the whole section. Strangers pay for the manual version, more than once. Volume grew until the spreadsheet started to creak. You can name the three most common exceptions the process hits, because they’ve happened. Ries documents a pattern worth copying here — the concierge MVP, a human performing the service by hand behind a plain order form. Nobody can tell there’s no software yet, and every order teaches you what the software must eventually do. The creaking spreadsheet is a feature of this phase, not a failure. Every creak is a requirement announcing itself early, while requirements are still cheap.

§7You need more than one person

I’m one person, on purpose, and some situations need more than one. Some needs are team-shaped: same-day response written into a contract, several parallel workstreams, a vendor whose org chart survives any individual. For those, hire an agency and pay its overhead with open eyes. The overhead buys real redundancy, as the continuity entry spells out. If your buyer, regulator, or insurer requires certifications, audits, and a compliance department, I’m structurally not that vendor. No amount of skill on my side changes it.

For calibration, the size I do fit: systems used by teams of roughly three to thirty, one careful deploy at a time. Replies from me come within 24 hours — not from a seat in your Slack, and not on a same-minute SLA. Most owner-run businesses need exactly that and get quoted for a standing army anyway. Needing more isn’t a failure of nerve. And pretending one person scales to it would be the exact overpromise this entry exists to rule out.

The same honesty cuts the other way: a rented platform is also “more than one person.” A SaaS product ships with an on-call rotation, a security team, and a roadmap you don’t pay for separately. Some systems lose real money for every minute of downtime, around the clock. For those, that standing army is worth renting even when the five-year math frowns at it. Owned software’s operational calm, described in §3 of the continuity entry, is real but it is calm, not coverage. Know which one your business actually needs before you pay for either.

§8What’s left when all six clear

Run the six as a checklist, in order, before you book anyone’s call — mine included:

• 01 · the deadline. Nothing has to go live this week. Fails? Rent now, keep the workaround file, reread §2 in six months.
• 02 · the process. No structural change in three months. Fails? Revisit one quarter after it settles.
• 03 · the tools. They almost fit, and the tally-mark audit from §4 came back thick. Fails? Keep them, gladly.
• 04 · the math. Relevant spend is $300+ a month and the budget clears $5,000. Fails? §5’s settings afternoon, unless the revenue exception applies.
• 05 · the proof. Strangers have paid through the manual version. Fails? Concierge MVP first.
• 06 · the team. One careful person covers the need. Fails? Hire the agency with open eyes.

Six passes is the profile where the 12–24 month payback stops being a brochure line and starts being arithmetic. It’s the same profile every case file on this site started from. And notice the checklist has no line about wanting better software. Everyone wants better software; wanting is free and the bills aren’t. The six tests are about conditions, because conditions, not desire, are what a five-figure build has to survive.

If you fail one test, you have your answer, and it cost you nothing: keep renting, revisit when the failing condition changes. Most businesses fail at least one. That’s why most businesses should keep their subscriptions, and why the software industry’s revenue model is safe from me. But if all six clear, your situation is the one this site prices: a stable process paying rent forever for tools that never quite fit. Run the five-year numbers on your own bill first. Then read what the scoping week produces. Its first real job, before any code, is to run these six checks again against your specifics, with the option to stop at zero cost. The rain-gauge salesman published his weather criteria. Hold him to them.