Buy the software, unless configuring it costs more than building it.

Almost every build-versus-buy argument should end in buy, and the reasons aren't close. Someone else has already handled the edge cases you haven't thought of yet — the timezone bug, the tax rule, the date picker that breaks in one browser. Someone else carries the pager at 2am. And a wrong decision is cancellable: a bad subscription costs a month's notice; a bad internal tool costs every engineer-week it took to build, plus every one it takes to keep alive.

That's worth saying plainly coming from us, because building custom software is what clients pay us for, and buy is still the advice we give most often. What follows is where that default stops holding — and one client where it didn't.

The comparison most teams get wrong

The comparison usually runs as a price against an estimate: a monthly fee versus the six weeks an engineer thinks it'll take. Both numbers are wrong in the same direction, because neither contains what costs the most.

On the buy side, the license fee is the smallest part. The rest is time the tool takes from people forever: onboarding, configuration, the person who quietly becomes its unofficial admin, the quarterly re-tidy when pipeline stages drift from how you sell. On the build side, the estimate is the smallest part too: the rest is hosting, patches, dependency upgrades, and someone still being here in two years who understands it. Neither column appears on an invoice, which is why teams argue about the two numbers that do.

Four questions that flip the default

The default is buy, and moving off it takes real evidence. These four questions are deliberately answerable: you can either name the thing or you can't.

• Are you paying for the shape of a company you aren't? Not extra features — the wrong ones. Enterprise tools assume approvals, handoffs and reporting lines a small team doesn't have.
• Is the configuration cost recurring rather than one-off? Setup you do once is a purchase; setup that comes back every quarter is rent, charged in hours instead of dollars.
• Does what you need fit in one sentence, and still fit a month later? Write it down, then check it after real use rather than on the day the tool annoys you.
• Are you already maintaining the glue that keeps the bought tool usable? A spreadsheet beside it, a scheduled export, someone reconciling two systems — an unbudgeted internal product.

One yes is noise. Three or four, sustained over months rather than one bad week, is the case for building something.

What that looked like for one client

A four-person creative agency came to us paying $360 a month for HubSpot. The number wasn't the problem — $360 is fair for a working sales system. The problem was everything arranged around it.

Run the questions. Were they paying for the shape of a company they weren't? Yes: HubSpot is built for sales organizations with handoffs and reporting upward; there were four of them. Was the configuration cost recurring? Yes — weeks of onboarding, then complex configuration and constant training, and with a 30-to-90-day sales cycle nobody's hands stayed warm on the tool. Did what they needed fit in one sentence? Yes, and you can read it off what they built: track the contacts, see where the deals are, don't lose the follow-up.

The fourth question — whether they were already maintaining glue — we're leaving unscored; we don't have an honest answer to it. Three is enough. They were paying for automation, reporting and integration complexity they never used, and paying twice over: on the invoice, and in the hours it took to keep a tool that size configured for a team that small.

So their answer was build. Not in-house: nobody at a four-person creative agency was going to become a part-time software maintainer. They hired us; we built them Nrtur, and they own it. A CRM sized to the sentence — contact management, a pipeline that matches how they sell, automatic email sync, a visual workflow builder for follow-ups. That was the whole scope; setup took five minutes against weeks for the thing it replaced.

Their CRM spend fell 74%, saving about $3,180 a year — the easiest number to quote and the least interesting one. The team estimates three to four hours a week recovered from CRM admin, and for a four-person shop that's the figure that mattered. The saving was never really the license.

The sentence is the hard part

All of this rests on the sentence, and the sentence is where these projects fail. Not during the build — three months later, when the thing that was supposed to do one job gets asked to do a second one that is obviously, reasonably related.

Nobody proposes complexity. It arrives as the obvious next commit, from someone being helpful.

It's always defensible in the moment: if we're tracking deals we may as well track invoices. Each step is small, each has a good argument, and six in a row is how you arrive at a worse version of the product you left, with the maintenance bill now yours. The test isn't whether a feature would be useful — almost anything would be. The test is whether it was in the sentence.

What this framework doesn't say

It doesn't say HubSpot is bad software. It's very good software for the company it was designed for: one with a sales team, a marketing function, handoffs between the two, and enough deal volume that reporting is a real question. A tool being wrong for you isn't the same as a tool being wrong. The agency wasn't overcharged; they were mis-sized, and they'd sized themselves.

Run the same four questions at 200 people and every answer reverses: you are that company now, configuration is somebody's actual job, and the sentence stopped being one sentence long ago. At that size a small custom CRM is what slows you down, and moving to something like HubSpot is the boring, correct next decision.

And it doesn't say building is cheap because someone else writes the code. Commissioned software is a standing obligation: a hosting bill, a day when a dependency needs updating, and an owner, who is you. The agency didn't get zero maintenance; they got maintenance proportional to what they use rather than to what they were sold. Let it grow and you've bought back the complexity you were escaping, with the patching now yours.

Running it against your own stack

This is an afternoon, not a project, and it's worth doing whether or not you ever hire anyone: most of what it produces is a decision to leave things alone with better reasons than before.

• List every recurring tool and what it costs a month. That column you already have.
• Beside each, estimate the hours: onboarding, configuration, admin, training, and the reconciliation nobody counts as work.
• Write the sentence for each tool. If you can't get it down to one, the answer is buy. Stop there.
• Check the sentence again a month later. If it grew, the answer is buy.

Most of your stack will pass, and that's the correct result. The value is in the one line item where the numbers don't work.

If one doesn't pass, what's in front of you is smaller than it sounds. It isn't becoming a software company. It's writing one sentence, paying for exactly that sentence, and defending it for as long as you own the result. The agency's problem was never the price of a CRM; it was the price of a CRM built for somebody else.