Association platform or custom member portal: a worksheet

Two different questions, asked as one

When "our platform can't do this" comes up, it is worth separating two questions that usually get asked as one: whether the platform itself is missing something, and whether the one member action causing the trouble is worth building separately. They have different answers and different costs. Conflating them is how associations end up buying more of a platform they did not need, or building a whole new system to fix one exception path that a configuration change would have solved.

This worksheet will not tell you which one is true for your association. It gives you the questions that decide it, and a dated look at what the common platforms cost, so you can have the conversation with your board or your team before you talk to anyone about a project, with us or with anyone else.

What the platforms already cover

Most associations run one of a small set of platforms: Higher Logic, Fonteva on the Salesforce platform, or a smaller option such as WildApricot, MemberClicks or Glue Up. Each one covers membership records, renewals, a member directory and some form of community space, and each one is actively developed.

Capabilities change, sometimes quickly. A limitation you read about a year ago may not hold today, and a feature comparison someone did for a different association may be out of date by the time you read it. Check the current state of the specific feature you need, on the platform's own site, before you assume it is missing.

What tends to vary more than raw feature count is fit: how closely the platform's model of "a member" matches your levels, chapters and renewal rules, and how much of your process fits it directly, without a workaround.

A pricing snapshot, dated

Platform pricing changes and varies by member count, chapter structure and plan. These are the vendors' own published starting prices as we read them on 16 September 2026. Follow each link for the current figure.

Configure: what it assumes

Configuring the platform you already run is the right call more often than a vendor conversation makes it sound. It tends to work when:

• The action you need fits the platform's existing object model, even if it takes custom fields or a workflow to get there
• Your staff are already trained on the platform, and you want to avoid a second system to learn
• The cost of the platform's next tier is smaller than the cost of building and maintaining something new
• You do not have engineers on staff, and you are not planning to hire any

Build: what it assumes

Building one member action outside the platform, and connecting it back, tends to make sense when the platform stays in place and only the missing action gets built:

• The action touches more than one system, and no single platform owns all of them
• The exception happens often enough that staff time on it adds up to a real, ongoing cost
• The logic is specific to how your association actually runs, not something a configuration screen can express
• You have, or are willing to fund, someone to maintain it after it ships

Questions to answer before you decide

Answer these before you talk to a vendor, or to us. They take an afternoon, and they make every later conversation shorter.

• Which member actions happen every week, and which happen rarely but cost the most staff time when they do?
• Does your platform show a member's full entitlement history in one place, or does staff assemble it from more than one screen?
• When a request does not fit the standard flow today, who owns it, and how long does it usually take to close?
• If you needed to add one new exception type this year, could your own team configure it, or does it require a vendor ticket?
• What would a new or connected system need to read from your platform, and what would it need to write back to it?
• Who would maintain a new or connected system, day to day and when something breaks?

A simple entitlement matrix

Before either path, write down what each member level can see, request and approve without staff involved, and what always needs a person. A short version might read:

• Standard member: sees their own record and directory listing; requests a renewal or a standard level change without staff involved.
• Chapter or committee member: sees a shared roster in addition to their own record; requests anything involving another member's record through staff.
• Lifetime or legacy member: sees their own record; almost every change routes to staff because the entitlement rules are older and less standard.

Most of the disagreement between "the platform can do this" and "the platform can't do this" traces back to a matrix like this never being written down.

Common mistakes

• Treating a missing feature as permanent. Platforms update. Check the current version before you plan around a gap.
• Building a new system to fix one exception path. If the rest of the platform works for you, treat that as a configuration problem and solve it there.
• Skipping the entitlement questions and hoping the logic reveals itself during the build. It rarely does, and it is expensive to discover mid-project.
• Assuming a redesigned member area also fixed the staff side. The two often move on different timelines, and a member-facing refresh can leave the staff queue exactly as it was.
• No named owner for the decision. Someone should be accountable for "configure" or "build," in writing, before either one starts.

Using this with us, or without us

This worksheet is useful whatever you decide, including staying with the platform you already run. If you want help working through it, we do that with you as the second step of our process, after a discovery call, and you keep the result.

Discuss a member portal project