Build vs buy union software: what building your own system actually costs
We're an eMembership publication and naturally know our own platform best. This guide is written to be useful to any union leader weighing a build against a purchase, including one who decides to keep building. It draws on public Department of Labor recordkeeping guidance, public security guidance, and what unions tell us about the systems they're running now.
- Most in-house builds top out as association management software. The roster, the contact record, committee and officer lists, and basic dues receipts get finished. The union-specific machinery doesn't: expected-versus-received remittance reconciliation employer by employer, grievance step clocks, dispatch and out-of-work lists, contract-driven rate tables, per-capita, and LM-2 and LM-3 reporting are the components that keep getting deferred.
- A build estimate covers construction. It doesn't cover the twenty years after it. Hosting, patching, backups, security review, retention, staff support, and the next feature request are permanent obligations that land on people who already have other jobs.
- Whatever does get built has a future that depends on one person. A build can fit a local's operations closely, and that fit is real. It's also usually undocumented and held in one head, which makes the system's continuity and the builder's employment the same fact.
- Hosting is the quietest decision in a build and it sets a ceiling. An inexpensive shared web host is easy to start on and it also determines what the system can never do. The migration to a more capable environment is usually the task that keeps getting deferred.
- Security is where the deferral gets expensive. When the person writing features is also the person responsible for protecting member data, gaps get identified faster than they get closed.
- Run the Build Exposure Test against the system you already have. Five questions. Exposure to any of the first three is structural, and won't resolve on its own.
Why are unions building their own membership software?
Because generic software keeps failing at the specific thing that matters most to a local's finances: knowing, quickly, that the money that arrived doesn't match the money the contract says should have arrived, and being able to act on that with the employer while it's still current.
That capability is in demand and it isn't evenly available. A specific type of local builds. Usually it's a larger, more sophisticated organization with a data director or an operations lead who can write code, or who is willing to learn. Sometimes the trigger is leaving a commercial platform that never ended up fitting their needs. Other times there was never a platform at all, and the spreadsheets outgrew themselves.
The interest from other locals is real. We have seen an in-house build presented to peers at an industry session, with several people in the room asking what database and stack it ran on and the presenter staying past the end of the session to keep answering the questions. That isn't idle curiosity. It's a room full of unions with the same unsolved problem.
We also hear the other end of the same story regularly. Unions come to us running a core membership system that was built in-house in the late 1990s, or as a Y2K project, still in daily use twenty-five years later, with the replacement conversation only now becoming urgent. Those systems were good decisions initially, but the people who made them are, in many cases, no longer there.
What does building actually get right?
Any argument that skips this part isn't worth reading, so here it is plainly.
A custom build fits. It models your dues structure, your classifications, your employer file formats, and your bylaws, without configuration compromises and without paying for capability you don't use. You control the priority list. When a business agent needs a report changed, nobody opens a ticket and waits, which matters more than it sounds when the alternative is waiting a month for a vendor to schedule a custom report request.
You also own the data model outright. There's no per-seat cost, no renewal negotiation, and no risk that a vendor sunsets the one feature your operation depends on.
Locals that build can end up with a closer fit than a commercial system that was never right for them, and that fit is a genuine result. It's a result about fit, though, not about coverage, and it's usually confined to the part of the operation the builder set out to solve. The costs that follow don't erase it. They sit alongside it.
What does it cost to build and run a custom union database?
There are two costs, and buyers almost always compare the wrong one.
The construction cost is the one everybody estimates: the hours to design, build, and launch. It's usually paid in staff time rather than cash, which is exactly why it feels cheap. Nobody sends the local an invoice.
The ownership cost is everything post-launch, and it never ends. A membership and dues system isn't a project that completes. It holds regulated financial records, it holds sensitive personal data, and it has to keep working through operating system updates, browser changes, staff turnover, contract changes, and whatever the Department of Labor asks for next.
A build isn't finished when it works. It's finished when someone other than the builder can change it.
Here's the ledger, laid out as a comparison. The lengths of the two columns aren't the interesting part. What matters is that in the left column, every line is carried by the same one or two people.
The union build cost ledger
| Cost category | Building in-house | Buying a managed union platform |
|---|---|---|
| Scope actually delivered | Roster, contact records, and dues receipts. The union-specific modules arrive later, if at all | Member records, employer management, remittance, grievances, dispatch, and reporting, configured during implementation |
| Initial construction | Staff hours, usually uncosted and usually underestimated | Implementation and data migration, quoted before you sign |
| Infrastructure | Your hosting plan, and the ceiling it imposes on what you can run | Part of the subscription, with no servers to own |
| Operating system, database, and framework patching | Yours, on top of everything else the builder does | Handled by the vendor as part of normal operations |
| Backups and tested recovery | Yours to configure, and yours to verify actually restores | Included, with recovery covered by the service relationship |
| Security program: scanning, testing, access control, incident response | Yours, typically owned by the same person writing features | A documented program the vendor maintains and can evidence |
| Evidence for an employer, an international, or an auditor asking about controls | You write it yourself, from scratch, each time | The vendor's existing security documentation and questionnaire responses |
| Changes when a rate, a contract, or a filing requirement moves | Goes into the same backlog as everything else | Ships in a release, with the obligation on the vendor |
| Support when something breaks during payroll week | Whoever built it, if they're reachable | A defined response commitment |
| Training new staff | Informal, dependent on the builder's availability | Structured onboarding and documentation |
| Continuity when the builder leaves | The exposure the whole build rests on | Continues without interruption |
| Getting your data back out | You already have it, which is a genuine advantage | Depends entirely on the vendor, so confirm export rights in writing |
Three lines in that table deserve more than a row.
Scope. The part of a build that gets finished is rarely the part a union most needs. Rosters, contact records, committee and officer lists, event sign-ups, and simple dues receipts are tractable, and they're also what ordinary association management software already does. What separates union management software from association management software is the hard half: reconciling expected against received remittance employer by employer when rates differ by classification and contract, grievance workflows with step clocks and automatic step-due notifications, dispatch and out-of-work lists with their referral rules, per-capita to the international, arbitration and contract tracking, and LM-2 and LM-3 reporting that has to reconcile to the books. Each of those encodes rules that change when a contract changes, which is why they're the components that stall. A build that hasn't reached them isn't an early version of union management software. It's a membership list with a payment log, and the distance between the two is where most of the work lives.
Hosting. In-house builds often land on inexpensive shared web hosting, because that's what's available and approved when the project starts. That decision quietly sets a ceiling. We have seen a build where the developer wrote a component in one programming language and then discovered the host wouldn't deploy it, and where security controls he wanted to change weren't his to change on that plan. Moving to a more capable cloud environment sits on the list as a two-week job that hasn't happened, because the two weeks never arrive.
Hosting is the quietest decision in a build, and it sets the ceiling on everything that comes after.
Security. A union membership database holds addresses, employment history, dues records, and in some contracts partial Social Security numbers. In a build, protecting all of it is a second job for the person whose first job is shipping features, and often a third job after their actual union role. Builders are usually clear-eyed about their own gaps. In one build we studied, the developer named his biggest exposure himself: sensitive member data moving through email threads. He was building an employer upload module to fix it. It wasn't done.
Gaps get identified faster than they get closed when the person finding them is also the person shipping features.
There's also a compliance floor here that applies no matter who built the system. Under the LMRDA, unions have to maintain the records that verify their filed reports for at least five years, and the Office of Labor-Management Standards publishes guidance listing the standards an electronic recordkeeping system should meet before a union stops keeping paper copies, including testing the system before any hard copy is destroyed. If your system is homegrown, meeting that bar, and being able to demonstrate it, is entirely your obligation. The same is true for basic access controls. The Cybersecurity and Infrastructure Security Agency urges organizations to implement multi-factor authentication on all devices, and in a build it exists only if somebody builds it. None of this is legal advice, so confirm any specific compliance question about your own union's situation with your own legal counsel.
The Build Exposure Test: five questions about the system you already have
Most build-versus-buy advice asks you to score vendors. This does the opposite. Answer these about the system running in your local today, whether that's a custom application, a desktop database, or a spreadsheet stack with scripts on top. Answer about what's true now, not what's planned.
1. Continuity: if the person who built it stopped working here on Friday, who changes it on Monday?
A clean answer names a specific person who has already made a change to the system without the builder in the room. You're exposed if the answer is that you would hire someone, that the documentation would need to be written first, or that nobody's ever touched it but the builder.
2. Hosting ceiling: what have you already decided not to build because the environment can't run it?
A clean answer is nothing, or a short list you rejected on merit rather than on platform limits. You're exposed if you can name a capability the hosting plan blocked, and more so if the migration to fix it has been deferred past one budget cycle.
3. Security ownership: who is accountable for member data protection, and is it the same person who writes the features?
A clean answer separates the two roles, or brings in outside review on a schedule. You're exposed if one person holds both, if sensitive member data routinely travels through email or shared drives outside the system, or if nobody's tested the backups by actually restoring one.
4. Maintenance capacity: is any of the builder's time protected, or does maintenance run on triage?
A clean answer sets aside real, scheduled hours for the system. You're exposed if new features, fixes, and patches all compete with the rest of the builder's union job and lose most weeks.
5. Obligation change: when a filing requirement, a dues rate, or a contract term changes, how fast can the system reflect it, and whose time does that come out of?
A clean answer is a number of days and a person who isn't already at capacity. You're exposed if the answer is the same person as questions one, three, and four.
How to read the result. Exposure on questions one, two, or three is structural. It doesn't improve with time, it usually worsens as the system grows, and it can't be fixed by working harder. Exposure only on four or five is a resourcing problem, and resourcing problems have solutions that don't require replacing anything.
Every union answers the continuity question eventually. The only variable is whether it answers on its own schedule or on the day somebody resigns.
What most unions get wrong about build versus buy
The most common mistake is comparing the wrong two numbers. Unions weigh an annual subscription against a build that appears to cost nothing, because the build is paid in salaried hours that the local is spending regardless. The honest comparison sets the subscription against the build's ownership cost together with everything the builder would otherwise have done with that time.
The real comparison isn't a build's cost against a subscription. It's the build's cost against the subscription, together with everything the builder would otherwise have done, plus every hour they'll spend on updates and new needs for as long as the system runs.
The second mistake is treating documentation as something to finish later. It never gets finished later. The most valuable artifact of any in-house build is the document that lets a stranger understand the schema, and it's the artifact that reliably doesn't exist, because writing it is never more urgent than the next fix. If your local is building and intends to keep building, protect the documentation time the way you would protect the code time. That single habit converts the largest exposure in the ledger into a manageable one.
The third mistake is treating the decision as permanent and total. Plenty of locals run an all-in-one commercial platform for member records, dues, employers, and grievances, then build something small and specific around the edges through an API. That's often the strongest outcome available, because it puts the regulated, sensitive, continuity-critical data on a maintained platform and keeps the union's own inventiveness pointed at the part that's genuinely unique.
Should our union build or buy?
Building is defensible when the need is narrow and genuinely unusual, when more than one person understands the system, when your hosting environment is already capable of what you'll eventually want, when the builder's time is protected rather than borrowed, and when you've written down what happens if that person leaves. If you can say yes to all of those, a build is a real option and this article isn't an argument against it.
Buying is the better call when the system holds member records, dues, and regulated financial history, when you can't name a successor for the person who maintains it, when your obligations change from outside the building and on someone else's schedule, and when employers, internationals, or auditors are going to ask you to demonstrate controls you would otherwise have to invent evidence for.
A practical way to run the decision:
- Score your current system against the Build Exposure Test before you look at any vendor. The result tells you whether you're choosing between two futures or trying to fix one problem.
- Price the build honestly. Put the builder's hours at a real rate and add the ownership lines from the ledger. Compare that to a quoted subscription, not to a guess.
- Ask any vendor for export rights in writing before you sign. Data portability is the one column where a build wins outright, and the only way to match it is contractually.
- Write your continuity plan either way. A local that buys still needs to know who owns the vendor relationship. A local that builds needs that plan far more.
How eMembership fits into the build versus buy decision
This section is about our own platform. Everything above applies regardless of what a union decides.
eMembership was built for labor unions and has been in continuous development since 2008. It runs entirely in a browser, with nothing installed locally, so staff in the office, reps on a job site, and officers traveling all work against the same live database. The areas a build usually starts with are already modeled: member records, employer management, employer payments and remittance processing, grievances, reports and queries, and dashboards. There are 18 configurable modules, and the Discovery Process determines which ones a given union actually needs. The member portal and mobile app are separate additions.
Measured against the ledger above, the lines that sit on one person in a build are handled here as part of the service. eMembership runs on infrastructure that Winmill owns and operates, inside a SOC 1 (SSAE 18) and SOC 2 audited, ISO 27001 certified facility, and Winmill maintains HIPAA Security Rule and PCI DSS compliance for the eMembership environment, supported by formal annual risk assessments. Data is encrypted in transit using TLS, and sensitive member data, including Social Security numbers, is encrypted at rest using disk-level encryption. Clustered firewalls sit at the perimeter, with managed detection and response across system logs, endpoint protection with host-based intrusion prevention, and anti-DDoS protection at the network edge. Winmill performs both dynamic and static code scanning, and its own cybersecurity practice runs penetration tests against the eMembership environment, probing it the way an attacker would, with findings triaged and remediated through a defined process. Multi-factor authentication is available to every union on the platform. Backups run nightly, encrypted, to an offsite vault. Server hardware is refreshed every three to four years at no charge, and all operating system, framework, and database patching is handled for you.
On the maintenance and continuity lines, releases are included in the subscription, and each one is staged to your test environment with a 30-day approval window before it reaches production. Every local is assigned a Project Manager and an Account Manager, so escalation has a named owner rather than depending on whoever happens to know the system. Response commitments are defined by severity, with service level credits when they're missed. Access is role-based down to the individual user, which matters for the same reason it matters in a build: a field rep and a treasurer shouldn't see the same screens.
The data stays yours. Full export is available at any time, which is the one advantage a build has by default and the one we think any vendor should be willing to match in writing.
Whether eMembership is the right answer depends on how unusual your requirements really are, whether your current system passes the Build Exposure Test, and how much you value having the ownership lines carried by someone whose full-time job is carrying them. A local that has proven it can build, and that would rather point that capability at organizing and representation than at patching and backups, is the kind of local we tend to fit well.
Three New York City police benefit fund organizations (the Lieutenants Benevolent Association, the Captains Endowment Association, and the Superior Officers Council) each arrived running their own separate systems and now share one platform, with three sets of maintenance obligations reduced to one. You can read the full story of how the three funds consolidated.
Frequently asked questions
Should our union build its own membership software?
Will a system we build in-house do everything union management software does?
What does it cost to build a custom union database?
Is a homegrown union database a compliance risk?
What happens if the person who built our system leaves?
Can we keep our custom system and buy software for part of it?
Is buying software just renting something we could own?
Is the reason you're considering a build about dues and employer remittance?
If the problem you're trying to solve is catching discrepancies and following up with employers while they're still current, that's the specific problem our dues compliance and employer remittance software was built for. Or start with a short intro call. We'll walk through what you're running now before recommending anything.
Book an Intro Call