Buy, configure, or build

Start by assuming you should buy

If your requirement is a website, a newsletter, an events calendar, a donation page or a shop, something already exists that does it better than a bespoke build will, for less than you would spend maintaining one. That is not a failure of ambition. It is the correct use of a limited budget.

The reason to consider anything else is not that off-the-shelf tools are bad. It is that some organisations do something genuinely unusual, and the unusual part is the part no product has a field for.

Configuration covers more than people expect

Between buying and building sits a large, underrated middle: an existing platform bent into shape with its own settings, custom fields and integrations. It is unglamorous and frequently correct.

It fails in one specific way. When the configuration becomes so elaborate that only one person understands it, you have built custom software without any of the things that make custom software maintainable — no tests, no version history, no way to try a change safely. That is the worst of both, and it usually arrives gradually enough that nobody notices.

The signs you genuinely need custom

First: your core process has no equivalent in any product, because your organisation invented it. A genetic genealogy nonprofit matching DNA evidence to family trees across thousands of open cases is not doing a variation on CRM. There is no CRM for it.

Second: the compliance requirement is the product. When certification has to survive an audit, the rules are the feature, and a general tool that gets you eighty per cent of the way leaves the twenty per cent that carries all the risk.

Third: you are paying per seat for volunteers. Products priced for companies price by user; organisations with two hundred volunteers and four staff hit that wall hard, and the arithmetic starts favouring a build much sooner than it would for a business.

The cost of buying badly

Buying is only cheaper if you actually use what you bought. The common failure is a capable platform adopted at speed, configured by whoever had time, abandoned by the team who found it slower than the spreadsheet, and paid for annually thereafter.

Before buying, find out who will own it after the enthusiasm wears off. That single question predicts more outcomes than any feature comparison.

What we tell people who should not build

That they should not build. It happens often enough to be unremarkable: someone describes a problem, and the problem is a reporting gap in a tool they already own, or a process that three people disagree about, or a spreadsheet that works fine and simply needs a backup.

A build proposed for any of those will be delivered, will work, and will not fix anything, because the constraint was never software. It is a bad outcome that looks like a successful project, which is what makes it worth naming out loud.

A test you can apply this week

Take your most important process and write it as a sequence of steps, naming the person who does each one. Then try to find a product whose demo you could follow using those words. If you can, buy it. If every demo requires you to rename what you do in order to fit, that mismatch is the thing custom software is for.

And if you are unsure, ask someone who builds it — then judge them by whether they try to talk you out of it.