Aug 12, 2026 · 19 min read

Build vs Buy: A Guide for Non-Technical Leaders

Someone has suggested building custom software. How to tell whether you actually need it, what the five year cost really looks like, and the cheaper options.

Somebody has told you that what you need is custom software.

Maybe a vendor, maybe a board member with a tech background, maybe your own operations lead who has spent two years fighting a system that doesn’t fit. And the reasoning sounded right in the room. We work differently from other organisations. The off-the-shelf products don’t do what we need. If we build it, it will fit us exactly.

That last sentence is the one to be careful with, and I will come back to it, because it’s true and it’s also the most expensive sentence in this whole decision.

Before any of that, though, there’s a smaller thing worth saying. Most organisations that end up in a build-versus-buy conversation are actually in a four-option conversation and only two of the options ever get named.

There are four options, not two

Change how you work. No software at all. Some of what gets quoted as a system is a handful of steps in the wrong order, a form that asks for things nobody uses, or a report with no reader. This option is free and available this month, and it rarely gets raised, for a reason that’s structural rather than sinister. You asked a software person a question, so you got a software answer. I would have done the same in their chair. It’s your job rather than theirs to put this option on the table.

Buy something. Pay for a product that thousands of organisations already use. You configure it, you live with the parts that don’t fit perfectly, and you get every improvement anybody else asks for, at no extra cost, for as long as you’re a customer. That is a real advantage and it comes with a catch I’ll come back to, which is that you don’t get to choose which improvements.

Assemble what you already pay for. You very likely own more capability than you use. Connecting two systems you already have, so that information stops being retyped, is usually a fraction of the cost of either building or buying, and it’s the option a vendor selling you software won’t raise.

Build something. Pay a firm to write software that exists only for you.

Those are in ascending order of cost, and it isn’t a close ordering. The gap between the third and the fourth is usually a factor of ten. So the honest question is never “should we build or buy.” It’s “how far down this list do we actually have to go.”

The cheapest thing you can do is also the first

If you have a fortnight and a committee meeting at the end of it, which is the realistic version of this, do this: spend the first week watching where staff time goes, spend one afternoon of the second week on the U and S exercise further down, and send the three vendor questions further down by email on the Monday in between, so the answers arrive while you work. The 2019 diagnosis takes an hour and can happen any time. Everything else in this article is reading.

So, the week. Watch where staff time actually goes. Not where you think it goes. Where somebody moves information from one place to another by hand, answers the same question for the fortieth time, or retypes something a person already typed into a form.

You need this before you can judge any proposal, because most of these conversations start from a symptom. Everyone agrees the current situation is painful, somebody proposes a system, and nobody checks whether the pain is where everybody assumes. It usually isn’t. The task that costs the most is rarely the one people complain about, because the expensive one takes ninety seconds and happens forty times a day and nobody notices it at all.

Some of what you find won’t need software. Some of it will need a small change rather than a system, and it’s worth being clear about that difference, because vendors use the words interchangeably. A system is something your staff log into and work inside, and it replaces how a job is done. A small change is a single step that happens by itself from now on, like a receipt going out when a donation lands, and it leaves everything else alone. The second kind costs a fraction of the first and is where a surprising amount of the relief actually is. I wrote about how to tell which of your repeated tasks are worth handling that way in how to find processes worth automating, and an older piece on what automation changes and what it doesn’t covers the part that’s about people rather than technology.

Why does custom software cost so much more over time?

Bought software has thousands of customers. Custom software has one.

That single difference is where nearly all the cost lives, and it doesn’t show up in either quote.

When you buy, everybody’s improvements arrive at your door. Another organisation asks for a better reminder system, the vendor builds it, you get it in March and you didn’t pay for it. Security patches, the new tax rules, the thing that broke when browsers changed, all handled by somebody whose entire business depends on handling it.

When you build, you’re the only customer it will ever have. Every improvement is a quote. Every change in the law is a quote. And every few years a piece of the machinery your system is built on stops being maintained by whoever made it. Software is assembled on top of other people’s software, several layers deep, and each of those layers is retired on a schedule set by somebody you’ve never met. When a layer goes, your system has to be moved onto a new one or it stops being safe to run. That’s a quote too, and nobody mentions it at the start. Your system doesn’t get better on its own. It gets slowly older, and the cost of that is real and arrives in years two through five, long after the person who championed the project has moved on.

Here’s what that looks like with numbers. Twelve staff logins, and products in your space at about a hundred and eighty dollars a month.

Option	Five year total	Made of
Buy	About 17,800	2,160 a year in licences, plus 3,000 setup and 4,000 to move your existing records
Build	About 155,200	85,000 to build, roughly 15,300 a year to maintain from year two, plus 1,800 a year to run it

Three assumptions are holding that table up, and you should check all of them against your own situation rather than take my numbers.

Twelve people, all staff. This is the one that moves the answer most, and it’s the one nobody flags. If four hundred volunteers each need their own login to record their own hours, ask every product on your list how they charge for that, because some charge per seat and some don’t charge at all for that kind of user. The gap between those two answers is larger than everything else in the table put together.

Eighteen percent a year for maintenance, with the first year under warranty. That’s the middle of what I see. Push it either way and the shape holds.

Licence prices that never rise. They do rise. I have held them flat to be generous to the build case, so treat the buy column as a floor.

And two things are missing from both columns, deliberately, because I can’t guess them for you. Neither includes a penny of your own staff’s time, which for a bought system is months of your operations lead and for a build is considerably more, and that is the scarcest thing you have. Neither includes the risk of the project being abandoned half-finished, which is the real worst case rather than “expensive”: a system that doesn’t work, a grant that’s been spent, and a conversation with the funder about what happened to it. Be clear with yourself about which part of that is the actual loss. It isn’t the 85,000. It’s that this funder gives you money every year, and the relationship is what a failed project really spends. That cost outlives the project by a decade and shows up in no budget line.

Building still comes out somewhere near nine times the cost of buying. That doesn’t make it wrong. It makes it a decision that has to be worth nine times as much.

The part that’s specific to how you’re funded

This is missing from every version of this conversation I have sat in.

The 85,000 can come from a restricted grant. The 15,300 a year can’t. Maintenance, hosting and support come out of unrestricted money, every year, forever, and unrestricted is the tightest dollar in the building. So a build quietly converts a one-time restricted gift into a permanent unrestricted obligation, and it does it at the moment when the money feels most available.

That’s precisely why 85,000 feels affordable and isn’t. It’s also the sentence to put in front of your finance committee, because it’s the one thing in this whole decision a board treasurer will understand faster than you can explain it. Say the word overhead while you’re there. Unrestricted is the tightest dollar because funders cap indirect, and that’s a fight your board has already been having for years, so the point lands in a line they’re protective of rather than in an abstraction.

Two things to do before any of that, and neither costs anything.

Read the grant agreement first. Restricted money has terms, not just a label. Some designated funds are operating-only and can’t buy a capital asset at all. Some funders won’t fund software at all. Some require it be capitalised and depreciated, which changes your audit and your finance officer’s year. Find this out before you build a case around a number the grant may not let you spend that way.

Then ask whether the maintenance can go into the grant. The split isn’t always immovable and almost nobody asks. Go back to your program officer before the finance committee and ask for a multi-year line or an operating component. Sometimes the answer is yes, the asking costs nothing, and it’s the highest-value phone call available to you in this whole process.

If you already bought once, and it failed

Most people arrive at a build conversation from a bought system that didn’t work. That isn’t an unusual route, it’s the normal one, and it changes what you should do next, because “just buy the sensible thing” is precisely what you did last time.

So before deciding anything, work out which of three things went wrong in 2019, because they point in completely different directions.

The product was wrong for you. It was built for organisations that work differently, and no amount of configuration was going to close the gap. If this is it, buying again is fine, and the U and S exercise below is how you avoid repeating it.

The product was fine and the setup wasn’t. Nobody was given the time to configure it properly, the fields were left as they came, training was an afternoon, and the person who understood it left in 2021. This is the most common answer by a distance, and it’s the one that feels exactly like the first from the inside. If it’s this, building a new system will reproduce the failure at nine times the price, because the same thing will happen to the new one.

The process underneath was never agreed. The system was asked to settle a disagreement about how the work should be done that nobody had actually settled. Software can’t do that, and a custom system can’t either. It just encodes the disagreement and makes it permanent.

If you land on the second one, which you probably will, the article you actually need is a shorter one, so here it is. You have three options and none of them is a new system. Re-implement what you already own: same product, configured properly this time, by somebody who does this for a living, with the fields and reports set up around how you actually work. Expect it to cost a fraction of a build and to feel like starting over, because it partly is. Buy the configuration rather than the software, which is a service most vendors sell and almost nobody buys, and insist that it includes training somebody internal to change things afterwards. Or accept the gap is real and go back to the U and S exercise below with clear eyes, because sometimes the second diagnosis and the first are both true at once.

What all three have in common is that they cost between a tenth and a third of a build, and none of them requires a grant.

The way to tell them apart costs nothing. Ask the three people who use it most, separately, for the specific thing it won’t do, and write down their answers. Separately matters, and so does who does the asking: whoever is championing the new build should not be the person collecting or collating these, however well-intentioned they are, because your heaviest user and your build champion are very often the same person. If they name the same two or three things and those things are genuinely about your organisation, it’s the first. If they describe fields that were never set up, workarounds nobody was trained out of, or reports that exist but nobody knows how to run, it’s the second. If they disagree with each other about what should happen, it’s the third.

One honest note on the promise I made above, that a bought product improves for free. That’s true of the product. It isn’t a promise that the improvements will be the ones you need, and if you bought something built for a different kind of organisation, you can watch five years of other people’s improvements arrive and none of them help. That’s a real experience and it’s worth naming, because “everyone in our sector uses it” is a much weaker reason than it sounds.

How do you know if your requirements are really unique?

Everybody believes their organisation works differently, and everybody is right, in a couple of places. The decision turns entirely on how many places, and on whether they’re the ones you think.

Here’s the exercise. It takes an afternoon with the two or three people who do the work.

List what the system has to do. Plain sentences, in the words your staff use. “Record that a volunteer turned up.” “Send a receipt with the right charity number on it.” Aim for thirty to fifty of these. If you have eight, you haven’t asked the people who actually do the job.
Mark each one U or S. U for universal, meaning every organisation like ours needs this. S for specific, meaning this one is genuinely ours. Be strict. If another organisation in your sector would recognise it, it’s a U.
Count the S list. In my experience it usually comes out very short, a handful at most. I am not going to pretend that’s a measured figure, and you should not put it in a board paper as one. What matters is your own number and how it looks under a second opinion. If yours comes out at twenty, either you’re genuinely unusual or step two was done generously, and somebody outside the room should check which.
For each S, ask what it would cost to just not have it. Not rhetorically. Actually answer. Could a person do this bit by hand in ten minutes a week? Could the process change so the need goes away? A surprising number of S items are the shape they are because of a decision somebody made in 2011 that nobody has revisited.
Take the survivors and go looking. Two or three products, and ask each vendor specifically about those items. Not a demo. Those items.
Now decide. If the S list survived step four and no product covers it, you have a real case. If it didn’t, you have a buying decision and a couple of process changes.

The answer that comes out of this most often is a boring one. Buy the product that covers nearly all of the U list, and handle the two or three genuine S items either by changing a process or by keeping a spreadsheet alongside, which is a perfectly respectable outcome that nobody ever writes in a proposal.

The second most common answer is the middle path, and it’s the one I recommend more than any other: buy the boring core and build only the thin piece that’s actually yours. Your donor records, your finance, your email, your scheduling all come from products. The one thing that’s genuinely specific to you gets built, small, on top. That way the piece written only for you stays small, and that piece is the whole of what you’ll be paying to maintain in five years.

When is custom software actually the right choice?

There are real cases, and I would rather list them honestly than pretend the answer is always buy.

The software is the thing you do. If what you’re building is a service you deliver to the people you exist to serve, rather than something that helps you run the office, that’s a different question entirely and the economics above don’t apply. You’re building a product, and it should be planned like one.

Nothing exists, and you’ve actually checked. Genuinely empty spaces do exist, usually in specialised sectors. But “we looked and didn’t find anything” often means two afternoons of searching and one demo. Before accepting this one, ask who did the looking and how long it took, especially if the person who did the looking would also be doing the building.

The real need is connection, not creation. Sometimes what an organisation calls a custom system is actually four products that already work fine and don’t talk to each other. That’s a much smaller project with a much smaller maintenance bill, and it deserves its own quote rather than being folded into a larger one.

Notice what isn’t on that list. “Off-the-shelf doesn’t fit us exactly” isn’t a reason on its own. It fits you exactly today, and today is the cheapest day this software will ever have.

What should you ask a vendor proposing a build?

If someone is recommending a build, three questions will tell you most of what you need, and you can send them by email.

Which products did you evaluate, and what specifically did each one fail to do? You want product names and specific gaps. A vague answer here means nobody looked properly, and it’s the single most common failure in this whole decision.

What does this cost us in year three? Maintenance, hosting, support, and what happens if something it depends on changes. Somebody who has built and maintained software can answer this in a paragraph. Somebody who has only ever built it will go quiet.

Who maintains this in eight months? A name, and a real arrangement, and what it costs. If the answer involves your one technical volunteer, or a staff member who is enthusiastic, you’re one resignation away from owning software nobody can change. That’s the worst position in this article, worse than either buying badly or building expensively, because there’s no next step from it that isn’t starting again.

If you get a proposal back and want the fuller version of what a good one has to define, I wrote that separately in how to evaluate a software development proposal when you aren’t technical.

What to put in front of your board

Everything above is aimed at a vendor. Your actual next obstacle is a committee, so here’s the short version to take to it. Five lines, and you can fill in four of them this week.

The year three number, in writing, from the vendor. If you don’t have it yet, that alone is your recommendation: we aren’t ready to decide.
Which fund pays the annual cost. Say the word unrestricted out loud. Your treasurer will do the rest of the work for you.
A name against maintenance, and what happens if that person leaves.
How many of our requirements are genuinely ours, with the number and who checked it.
What we would do instead, because a recommendation to wait is much easier to accept when it comes with a cheaper alternative attached.

A committee that turns down a project is taking a risk. A committee handed those five lines is making a decision, and those are different meetings.

So: four options rather than two. Count how many of your requirements are genuinely yours and be strict about it. Get the year three number in writing, get a name against maintenance, and know which fund the annual cost comes out of.

If you do all that and the answer is still that you need something built, then you need something built, and you should go and do it with confidence rather than anxiety.

And if you would rather have somebody technical run that afternoon with you and tell you plainly whether your S list is real, that’s what a technology assessment is for. A fair amount of the time the answer I come back with is that you don’t need the project.