Build or buy
Build, buy or configure association and member software
Separate the workflows that are genuinely yours from the ones every association shares, then decide each one on evidence.
Most boards ask this as a yes or no question: should we buy an association management system, or build something ourselves? Asked that way it usually resolves into whichever option the loudest person in the room already preferred.
It is a more useful question when you stop asking it about the organization and start asking it about each workflow. Very few associations need a custom membership renewal. Many have one or two workflows that no product models well, because those workflows are the reason the organization exists.
There are four options, not two
Treating this as build versus buy hides the two choices that most often turn out to be right.
Buy a product and adapt your process to it. Lowest effort, lowest control. Appropriate for work where your current process has no particular value and exists only because someone designed it years ago.
Configure a platform. You accept the product’s data model but shape fields, roles, templates and workflows. Cheaper than building, and the configuration is still work that must be documented, tested and maintained by someone.
Integrate several tools. Each tool does one job well and the connections between them carry your process. This often looks cheapest on a spreadsheet and is routinely underestimated, because the integrations are software that you now own without having planned to.
Build. Full control of the data model and workflow, full responsibility for maintenance, hosting, security updates and the eventual rewrite.
A real decision usually arrives at a mixture: a product for membership and finance, a configured platform for communications, and one custom piece where the organization’s actual work lives.
Separate commodity workflows from distinctive ones
A workflow is a commodity when other organizations solve it the same way and nobody joins or leaves because of how you do it. Membership renewal, receipting, event registration and mailing lists are usually commodities, however much internal debate they attract.
A workflow is distinctive when it encodes something specific to your mandate, your sector or your regulatory position, and when doing it well is visible to the people you serve.
| Workflow | Usually the right move | Why |
|---|---|---|
| Membership renewal and dues | Buy | Well-modelled by products; your variations are rarely worth the cost |
| Receipting and finance integration | Buy or integrate | Compliance work you do not want to own or re-certify |
| Event registration and payment | Buy or configure | Mature products; edge cases are usually process, not software |
| General email and newsletters | Buy | A solved problem with deliverability built in |
| Member directory and search | Configure, sometimes build | Depends entirely on how specific your access rules are |
| Sector-specific assessment, accreditation or matching | Build or heavily configure | This is often the organization’s actual product |
| Multi-organization or federated data sharing | Build or integrate | Rarely modelled well by single-tenant products |
The exercise is only useful if you are willing to be told your favourite workflow is a commodity. Most organizations have fewer distinctive workflows than they expect, which is good news for the budget.
What a product demonstration will not show you
A demonstration is built to succeed. Ask instead for the same end-to-end journeys you wrote down during requirements, performed with representative sample data and the permissions a real staff member would have.
Watch for the second step rather than the first. Creating an event is always easy. Changing its time after 40 people have registered, when the original organizer has left the organization, is where products differ from each other.
Three questions tend to be decisive, and none of them are about features:
- When a record is wrong, who can correct it and what happens to everything downstream?
- What happens at the boundary of the product’s data model — the member who is also a chapter, the organization that holds a seat rather than a person?
- What does the product do that your staff will have to work around every week?
Record which requirements work out of the box, which need configuration, which need an integration and which cannot be met. That table, not an impression of the demonstration, is the comparison.
Count the cost on both sides honestly
Build decisions are usually compared against the first-year licence cost of a product, which flatters the build and is not the number that matters.
A bought product costs its licence, implementation, migration, the staff time to administer it, the annual increase, and the price changes that follow when the vendor is acquired. Per-member pricing deserves particular attention, because it is a cost that grows with the success you are hoping for.
A built system costs its development, hosting, dependency and security updates, the support arrangement, and a rewrite or substantial modernization somewhere between year five and year eight. A build with no maintenance budget is not cheaper; it is a cost deferred onto whoever is here later.
Compare both over the same period, which should be at least five years. Compare them on the same scope, including exception paths, permissions and migration.
Exit cost is the part people forget
The question that separates a reversible decision from a trap is what happens when you want to leave.
Ask for an export before you sign, not in the contract language but as an actual file. Find out whether it includes historical records, attachments, audit history and the relationships between records, or only the current state of the main tables. A product that exports a flat list of members and nothing else has effectively made your history non-portable.
Establish who holds the domain, the DNS, the application accounts and, for custom work, the source repository. These should be in your organization’s name from the first day, whoever is doing the work.
Ask what the product costs to leave: export assistance, parallel running, the final data extract. Some vendors charge for all three.
Write down the decision, not just the outcome
The most common failure is not choosing wrongly. It is choosing reasonably and then losing the reasoning, so that two years later nobody can say why the organization is paying for something nobody likes, and the discussion restarts from zero.
For each workflow, record the option chosen, the evidence, the assumptions that would change the decision and the person accountable. Date it. Revisit it when an assumption visibly breaks, not on a calendar schedule.
Download the build, buy or configure decision record (.txt). Work through it one workflow at a time rather than for the organization as a whole.
If a custom piece turns out to be justified, our member portal requirements guide covers what to agree before building it, and the budget guide covers comparing proposals on the same scope. Discuss your options with RapidIteration if you would like the comparison reviewed by someone with no stake in the outcome.