Ready-made membership solution or your own platform? What you are actually buying

What is a vertical base solution?

A vertical base solution is a finished domain solution built on Dynamics 365 for one industry. For membership organisations that means the vendor has already modelled memberships, dues, local branches, roles, events and self-service, and delivers this as one product that is configured per customer. In the Norwegian market, Mysoft Dynamics 365 is the clearest example of this model, and several consultancies offer packaged member solutions of their own.

Years of industry experience sit in the vendor's design choices, getting started is faster because most decisions are already made, and the product is maintained centrally so upgrades come to everyone. For an organisation whose processes fit the standard, this is efficient and predictable. It is a finished domain solution, built by people who know the domain well.

In return, the data model, the customisation boundaries and the roadmap are governed by the vendor's product organisation. You influence them as one customer among many.

What does it mean to build on your own platform?

The platform approach uses the same Microsoft foundation, but the member model lives in your own environment: Dynamics 365 applications on Dataverse, Microsoft's shared data service, with Power Platform for applications and automation, and Power BI and Microsoft Fabric for insight. The data model is designed around how your organisation works, and you can control the model and the pace of change, provided rights, documentation and maintenance responsibility are settled in the agreement.

What separates an accelerator from a base solution?

In practice, few organisations start from a blank sheet. Many partners, including us, bring an accelerator: a reference model for the membership domain with ready-made building blocks for memberships, dues structures and consents. It provides a head start at the outset, but it is not a finished product you subscribe to.

The difference shows itself after the start. A base solution remains the vendor's product, with the vendor's roadmap. An accelerator is taken over by the organisation: the model is developed further in your own environment, at your own pace, and continued assistance from the partner, including operations and maintenance, is a choice you make, not a dependency that comes with the purchase. Still, settle rights to reuse in writing in the agreement; that applies to any partner. We describe the approach in more depth in the article on member data as a platform.

Be sober about the cost side: control means responsibility, and the maintenance responsibility is a real platform cost. But the responsibility can be split. The operational maintenance, meaning operations, monitoring and change handling, can sit with the partner through an operations and maintenance agreement, while the organisation keeps the decision rights over the model, the priorities and the roadmap. Your own platform therefore does not require an in-house IT department, not even for smaller organisations, but the cost of the maintenance belongs in the calculation wherever it sits.

Five architecture questions that separate the models

Feature lists converge over time; architecture does not. When you compare offers, put the feature comparison aside for an hour and ask these five questions instead.

The difference rarely lies in who legally owns the raw data. It lies in who controls the data model, the pace of change, the integration surfaces and the terms for taking the solution further. We have written before about why the CRM is not a master register and about the difference between owning data and owning the system. The same distinction decides how expensive it is to change your mind later.

Who decides the roadmap when the vendor changes owners?

The roadmap question has become more relevant because the Nordic market is consolidating, and the point applies to every product vendor, including us when we deliver packaged components. A concrete example: Mysoft, one of the most established Norwegian vendors of a member base solution on Dynamics 365, was acquired by Swedish Multisoft in 2025, and in March 2026 SEB Private Equity acquired the majority of Multisoft Group. Two ownership changes in under a year is not criticism of the companies; it is a normal feature of a consolidating market, and new owners often bring investment capacity.

But it illustrates the architecture point. In a base solution, the roadmap is a product decision made by the vendor, whose priorities are set by its owners. When the ownership chain changes, your influence over the roadmap does not grow.

On your own platform the exposure is structured differently. The foundation follows Microsoft's roadmap, with continuous roadmap publishing but no guarantee for individual features, and with licensing requirements and dependencies that change over time. The member model, the integrations and the applications are yours. The vendor risk does not disappear, but it moves from the product layer to the partner layer: changing partner leaves the model and the integrations standing, while changing product takes them with it.

When is a ready-made base solution the right choice?

For many organisations the base solution is the right answer. The pattern we see: the organisation's processes are close to the industry standard, the membership is the dominant relationship, dues run in well-known models, and there is little internal capacity or appetite for owning a platform. In that situation, a finished domain solution delivers faster and at lower risk than a platform project, and the vendor's ongoing product maintenance is a service you would otherwise have to organise yourself.

If you choose this route, do it with open eyes: get the data model documented, get the export format demonstrated, and get the terms for custom integrations into the agreement. A good base solution vendor will answer all three without hesitation.

When is your own platform the right choice?

The platform route earns its cost when the organisation's reality no longer fits one product's domain model. Typical signals: several revenue streams beyond dues, relationships that go beyond the membership itself, courses, certifications or political advocacy work with their own processes, integration needs against your own finance and line-of-business systems, and an ambition to use insight and AI on your own data. This is the situation we described from the other side in the article on outgrowing the membership system.

Pattern: a recurring situation in projects we have taken part in: an organisation with tens of thousands of members runs a base solution that covers the member register well. Then the needs arrive that the product was not built for: a certification scheme, a new revenue stream, deeper reporting to the board. Each deviation becomes a change request priced and prioritised by the vendor. None of them are unreasonable; the sum of them is what triggers the architecture assessment.

Note that this is not an argument for replacing everything at once. The transition patterns we recommend are gradual: coexistence, where the current solution remains authoritative for parts of the domain while the platform takes over others. As a general rule, avoid ripping out and replacing everything at once.

How to run the assessment in practice

Four steps give you a defensible decision. First, map the processes that deviate from the industry standard; they decide how much a base solution must be bent. Second, ask every bidder to show the data model and the documented integration points, not the demo. Third, price the exit into the total cost: what would it cost to leave this solution in year five? Fourth, put the roadmap question in writing: which commitments does the vendor make on the functionality you depend on?

On the cost side, the same discipline applies as in any Dynamics 365 project: services normally exceed licences, and the honest comparison is made over five years, not over the first invoice. We have covered the mechanics in the article on Dynamics 365 implementation cost.