Custom vs Off-the-Shelf Is the Wrong Question

The age-old question of build versus buy has been tormenting organisations since the dawn of software. Buying is attractive up front - low cost of adoption and a well-sold dream - while building is the longer-term investment, where the higher initial cost and the flexibility you get for it force a more thoughtful process. I'm going to go through how I weigh these options and where each one fits.

The Problem Never Arrives as a Clean Choice

Here's how it usually shapes up for us. A membership organisation comes to me with a SaaS membership platform that does about 80% of what they need - renewals, payments, contact records, all handled reasonably competently. It also comes with all the other features you'd want: a website, a member portal, plugins for everything. The issue with casting a net that wide is there are usually serious shortfalls somewhere. The website is rubbish, the member portal is clunky and terribly configured, or the plugins are completely lacking.

None of this was a mistake. These platforms get set up when "let's get things working" is the right call - and at the time, it was. But the organisation has since had room to evolve and work out what it really wants, and with technology moving incredibly fast, it's the perfect time to reinvestigate and take advantage of the changes.

This is where build versus buy walks back into the room, usually offering two answers: put up with the platform, or rip everything out and start again. Sometimes one of those is even right. But you can't know which until you've worked out which parts you should keep renting and which parts of your operation should be yours.

Three Tiers, Not Two

Build versus buy fails because it mashes three options into two:

• Buy - for the things where your requirements are identical to everyone else's. Payments, email delivery, authentication, CRM. Your organisation does not process card payments in a special way, and it shouldn't want to. These are solved problems with huge economies of scale behind them so let's not reinvent the wheel.
• Configure - for platforms built to be shaped rather than used as-is. This is where Drupal lives, and it's the tier most people don't know exists. Content models, editorial workflows, permissions, integrations - defined through configuration on a platform maintained by a community, not written from scratch. You get software fitted to your organisation without owning a bespoke codebase which is a huge plus.
• Build - for the small percentage that's genuinely novel to how your organisation works. These are things like large custom workflows that exist only in your org, or processes that come from your accreditation rules and your relationship with your members. It's a thin slice, but it's worth paying custom rates for.

Most of the bad outcomes I've seen come from mixing the tiers up. Organisations build what they should have bought and vice versa.

So Which One Is Actually Cheaper?

It depends on two things: how standard your needs are, and how long you plan to keep investing in this.

If your needs are standard, off-the-shelf is cheaper and it's not close. Paying custom rates to build what a vendor already runs at scale is money wasted. But flip the complexity and the sums flip with it. When what you need is specific to how you work, every gap becomes a cost: the workaround that becomes part of someone's job, the integration that was "on the roadmap", the per-seat pricing that grows in a way nobody modelled. None of it shows up in the comparison spreadsheet, and all of it is opportunity cost.

The second thing is your time horizon. If you want to set something up and leave it alone, a subscription is hard to beat. If you're planning to improve this thing year after year - new features, a better member experience, taking advantage of whatever comes next - ownership wins, because changes cost what the change costs rather than what a vendor's plan tier says.

The trap is that off-the-shelf costs are easy to see up front and hidden later, while custom is the reverse - a big obvious quote, then cheap to change. Comparison spreadsheets only capture the visible half, which is why the wrong option so often looks like the safe one.

Where Off-the-Shelf Genuinely Wins

I'll be blunt: as a digital agency, I'm more inclined to encourage custom builds - so when I say off-the-shelf wins somewhere, I mean it.

Off-the-shelf wins wherever the problem is generic and the vendor's scale does work you can't. A membership platform that has processed millions of renewals has already hit the failure modes your custom build would spend years discovering. Payments, receipting, tax edge cases, reminder sequences - that reliability is the product, and it's worth paying for.

The NZSAE portal is proof of this - and it's exactly the shape I described at the top. NZSAE runs on Wild Apricot, which handles their memberships, renewals, and payments reliably. The templated member portal was the weak spot. Replacing the whole platform was never on the table - rebuilding a working membership engine is expensive, risky, and produces something worse for years before it produces something comparable. Instead we built the member experience on Drupal and kept Wild Apricot underneath as the system of record, reading membership data through its API. Wild Apricot kept the job it's good at. NZSAE got a portal that's actually theirs.

The Signs You've Drawn the Line in the Wrong Place

Off-the-shelf doesn't fail loudly. It fails slowly, one workaround at a time, which is why organisations put up with it for years. The signs:

• You're paying for the product to not do things. Features get disabled, hidden with CSS or worked around in the induction manual, and the monthly invoice stays the same.
• The workaround has become the process. Export, tidy up in a spreadsheet, re-import. Once someone documents the workaround, it's no longer temporary.
• You can't get your own data out. At least not in a format you can actually do anything with. If you can't leave with your data, it isn't really yours.
• Compliance is stuck behind the vendor's roadmap. If accessibility fixes or security requirements are sitting in someone else's backlog, you've outsourced obligations that are still legally yours.
• Change is mental gymnastics. Even a small update means working out which settings it's buried under, how to trick the platform into it, and what might break. When simple changes take that much thinking, the tool is working against you.

One of these on its own doesn't mean rip it out. It usually means the line needs to move - often, like NZSAE, by building around the product rather than replacing it. But when several of them stack up at once, moving the line might not be enough.

Sometimes the Answer Is One Cohesive System

There's a point where patching around the platform stops making sense. If several of those signs show up together, each fix becomes another integration to build and maintain, and you end up with a stitched-together version of the cohesion you wanted in the first place.

That's when a proper rebuild is the right call: one platform, configured to how you work, covering the membership, content, events and portal in one place. One login, one data model, one system to maintain - and new features become ordinary work on something you own rather than another workaround. You still buy the standard pieces - payments and email delivery stay with the specialists - but everything above them is yours and designed to fit together from day one.

It's the biggest option on the table - the largest upfront cost, a real migration, and responsibility for things the vendor used to handle. It's the right move when you've outgrown the product in several directions at once, and the wrong one when it's driven by frustration with one bad corner.

So Where Does the Line Go?

There's no single answer, but there is a way to work it out. Go through what your organisation actually needs and be honest about which tier each piece sits in. The standard stuff - payments, email, authentication - buy it and move on, because yours doesn't need to be special. The way your organisation works - your content, your members, your events, your workflows - belongs on a platform you can shape, because that's the part no product will ever get quite right. And the few things that only exist in your organisation are worth building properly, because nothing off a shelf ever will.

Get the mix right and nobody notices. A member renewing at 9pm on a Tuesday doesn't care which parts are rented, configured or built - they log in once and it all just works. That's what built for humans means to us: the moving parts are our problem, not your members'.