Almost every page about custom software was written by a company that would like to build it for you. So was this one. What we'd like is that you leave with a decision you reached yourself, because the projects that go badly are the ones where nobody examined the decision. This page is for people who haven't made it — you've outgrown something, a board member asked whether you should be building, or you've spent a year adding workarounds to a tool that nearly fits.
Definitions
Most explainers offer a straight choice between buying and building. There are really three, and the middle one is where a lot of organizations land without ever naming it. Much of the confusion here comes from two people using the words custom software to mean different things.
Off-the-shelf, configured, and custom software
A finished product you rent. Someone else decided what it does, by averaging across thousands of customers. You get maturity, a support line and a published price — in exchange for accepting the shape of somebody else's thinking about your work.
An off-the-shelf platform bent toward your process. Salesforce Nonprofit Cloud is the clearest example: you aren't writing the application, but you are designing objects, fields, permissions and reports, and that can take months and cost more than the license.
Code written for your organization, running on infrastructure you control, with a data model that matches how you actually operate. You own it, which means you can change it whenever you like and you're responsible for it forever. Both halves of that sentence are the point.
The test
Take these if you take nothing else. We ask some version of all four on a first call, and between them they settle most cases inside half an hour.
One. Is the workflow genuinely yours, or just familiar? There's a real difference between a process nobody else could run and one you've simply run this way for eleven years. Both feel identical from the inside. The test is whether you can explain to an outsider why the difference matters to the people you serve — not to the people who work there.
Two. Is it central to the mission, or adjacent to it? Software that delivers your programs is a different proposition from software that administers them. If the thing you're describing is how your beneficiaries actually receive what you do, custom software is a much easier argument. If it's bookkeeping, scheduling or email, it's a much harder one.
Three. Can you name what breaks if you don't? Not "it would be better" — what specifically fails, and when. A grant report you can't produce. A waiting list you can't see. A compliance requirement you meet by hand now and won't at twice the volume. If nothing on that list is concrete, custom software isn't this year's purchase.
Four. Who owns it in year three? Someone inside your organization has to hold the product after we've gone — deciding what gets built next, arbitrating between departments, saying no. They needn't be technical, but they must exist and have the authority. If you can't name them, fix that first.
Buy instead
Every firm says off-the-shelf is sometimes right; very few finish the sentence. If your process is common and your data model standard, a mature product beats custom software on cost, time and risk. Here are the cases we see most.
| If you need | Look at | Where it stops working |
|---|---|---|
| Donor management | Bloomerang; Little Green Light and DonorPerfect at a smaller scale; Blackbaud's Raiser's Edge NXT for finance teams | Implementation and cleaning the data — that's where these projects succeed or fail |
| To teach at a distance | Canvas and Moodle; Thinkific and Teachable for course sales | A distinctive pedagogy the platform can't carry — not, by itself, a reason to build one |
| Work that's invisible | Asana, Monday.com, Airtable | Permissions and reporting, when four funders each want a different cut |
| A spreadsheet three people understand | A Google Sheet | When that number drops to one, or errors cost more than the tool would |
Purpose-built products get missed because their marketing budgets are small. In program and case management, Apricot by Bonterra and Casebook are worth a demo before you conclude nothing exists — take real funder reporting requirements into it, not a general walkthrough.
Build instead
The cases that justify custom software have a family resemblance. The software is the thing your organization does, rather than the thing that keeps track of it. Or the requirement is specific enough that the products which nearly fit all fail at the same point, and you've been paying for that gap in staff hours without ever putting a number on it.
The Autism Helper is the first shape. They sell a curriculum platform to school districts, so the software isn't back-office — it's the product, and it had to meet district security and accessibility requirements the old setup was never built for. We finished that build and we still run it. The Alliance for Decision Education is the second: four separate engagements, including Decision Studio, a tool for teachers built with OpenAI agents inside a product we designed. Earlier, we built 4MyCiTy a mobile check-in app for food-rescue volunteers working nowhere near a desk.
What those share isn't size or budget. It's that somebody could answer question three above in one sentence, without hedging.
Year two
The comparison people run is a subscription against a build, and it's wrong in three ways. Naming them doesn't settle the decision, but it stops the arithmetic being quietly wrong.
Custom software has an annual operating cost. Dependencies need updating, security advisories arrive on somebody else's schedule, and the platforms underneath change in ways that break things nobody touched. It's a real, recurring, budgetable number and it belongs in the case you present, not in a surprise the following year. There's a rule-of-thumb figure for it on the page about what a custom build actually costs.
Your team's time is the largest hidden line on either side. A build needs decisions, content, testing and access on agreed dates; so does a platform implementation. The organizations that struggle are the ones that budgeted money and forgot to budget attention.
Staying still costs money too. Fifteen hours a week reconciling records is a real annual figure, and it's the one nobody calculates before deciding they can't afford to change anything.
What next
Three routes out of this page, and only one involves talking to us.
The Build vs. Buy Assessment is twenty-one questions about your organization and what you're trying to solve, and it takes about five minutes. What comes back is a written recommendation that names actual products, sets out what each realistic path involves, and says plainly where your budget doesn't stretch. It arrives as a link you can forward to a board member, needs an email address and nothing else, and it sometimes tells people not to hire us.
21 questions · ~5 minutes · emailed report
If you know you're building custom software and the open question is what exactly, that's a different problem with a paid answer: a two-week Roadmap Workshop at $7,000, ending in a prioritized roadmap and a scope you own regardless of who builds it.
$7,000 · two weeks
If the decision is made, the useful page is how a build actually runs — the sprints, the team, what we'd need from you.
Common questions
Not on its own. Outgrowing a tool means the tool stopped fitting; it doesn't say whether the next thing is a better product, the same product configured properly, or custom software. The most common answer we give is the second, because a lot of platforms get abandoned before anyone spent real money configuring them.
Ask whether the difference shows up for the people you serve or only for the people who work there. Distinctive processes produce something a beneficiary would notice; entrenched ones produce something only staff notice, and those are cheaper to change than to encode in software.
Yes, and you generally should. The smallest version somebody can do real work in teaches you more in six weeks than six months of planning, and it phases the spend across budget years. It also protects you from the most expensive outcome, which isn't building the wrong thing — it's building all of the wrong thing.
We'll say so. It usually sounds like: your process is standard enough that a product does this well, here's the one we'd look at first, spend the difference on implementation. Occasionally the real answer is that the problem isn't software — two teams disagree about a process, and nothing you build settles that.
The assessment is free, needs no login, and will tell you to buy something if buying is the right answer. If you'd rather talk custom software through with a person, that's an hour with no proposal at the end — and if you want our reasons for turning work down first, whether we're the right fit has a page of its own.