“Membership should be easy to understand and even easier to renew.”
The Caledonia Regional Chamber told its members that. We built the system that makes it true.
Walk us through your stack
The situation
Served businesses in Haldimand County since 1972. Simplified its fee structure in 2026 and told members joining and renewing should be simpler. The web presence could not yet deliver on that promise.
Template builder. Google Form for events. A 2024 directory. A calendar widget showing its own setup instructions.
None of this was negligence. The Chamber decided to stop adding tools and build the system instead.
Before and after
The public site, three surfaces
The old homepage showed a calendar widget's own setup instructions to visitors. The new one shows events.
The directory was a dated list. It is now the full membership, kept current by the members themselves.
Event submissions arrived by Google Form. They now happen on the events page itself.
Members serve themselves. Staff step in by exception.
The member portal. No before screenshot, because there was no portal.
A member's only touchpoint with the Chamber between renewals was an email or a phone call.
A listing change meant emailing staff and waiting for someone to edit the site.
No place for a member to offer a deal to other members.
One console runs the operation.
The staff CRM. Screenshots captured with seeded test records only.
Membership administration happened wherever staff could make it happen.
Membership pricing lived in documents; changing a fee meant changing them everywhere.
Event submissions sat in a form inbox with no overview of what was coming up.
A website enquiry was an email someone had to remember to answer.
Reporting meant building a spreadsheet from scratch.
Built for what the Chamber does next.
Most association platforms are built to work. This one was built to still work in five years, feeding systems that do not exist yet.
What the Chamber runs today is above this line. What the foundation is built to carry is here, labelled as such. We do not blur the two.
(append-only, typed)
How the data layer is built, for technical readers collapsed by default; opens on #architecture
Phase 1: Capture. Every membership action writes a typed event to an append-only Postgres ledger. Nothing is overwritten; state is derived, not stored.
Phase 2: Serve. The public site, member portal, and staff CRM all read from the same database through role-scoped views. One source of truth, three surfaces.
Phase 3: Report. A read-only reporting module builds worklists, CSV and PDF exports directly from the ledger. No copies of the data drift out of sync.
Phase 4: Sync. A CDC path is wired for Delta tables under Unity Catalog. Turning on Databricks reporting is configuration, not a rebuild.
The same discipline we use on legacy estates
Most of our Databricks work is the opposite of this build: Informatica PowerCenter, IBM DataStage, Netezza and Db2 estates moved onto the lakehouse, agent-assisted, with practitioners who spent years inside those tools. The Chamber got the same principle in reverse. Land the data in a shape Databricks can govern from day one, so there is never a migration to do later.
If your estate is already on one of those platforms, start with how we migrate Informatica PowerCenter and IBM DataStage to Databricks and the fixed-fee Migration Assessment.
The Chamber owns the Chamber's data
Role-based access for staff, directors, and members. Hardened authentication. PIPEDA-aligned privacy policy; analytics on GA4 consent.
Full export, any time, no request required. Point-in-time recovery. No hostage data, no exit fee, no leverage held over a renewal negotiation.
If the Chamber ever decides to work with someone else, it leaves with everything.
Results, when there are results
The platform went live in September 2026. We captured baseline numbers before cutover, and we will publish what changed once there is a full renewal cycle to measure. We would rather show you an honest build than a case study with numbers invented to fill the space. Check back in January.
Questions chambers and associations ask about this build
Is the Caledonia Chamber platform built on Databricks?
It is built for Databricks, not on it. The Chamber's daily operations run on a Postgres event ledger with a public site, member portal and staff CRM reading from it. A CDC path to Delta tables under Unity Catalog is wired and waiting; turning on Databricks reporting is configuration, not a rebuild. We say this plainly because a chamber does not need a lakehouse on day one, and we would rather show you an honest architecture than an inflated one.
Why an append-only event ledger instead of a normal membership database?
Because a ledger never loses history. Every join, renewal, listing change and event submission is written as a typed event and never overwritten, so current state is derived rather than stored. That gives the Chamber point-in-time recovery and full export today, and it is exactly the shape Delta tables and Unity Catalog govern best, so the same data can feed lapse-risk scoring or plain-language reporting later without a rebuild.
Can this platform be configured for another chamber or association?
Yes. The public site, member portal, staff CRM and reporting module are one codebase with the Chamber's fees, categories and branding held as configuration. The next chamber pays for configuration, not construction. We will walk your current stack with you first and tell you plainly whether a platform like this is worth it for an organization your size.
If your chamber is somewhere on this same path
We built this once. The next chamber pays for configuration, not construction.
Not a chamber? The same team runs our Databricks migration and modernization practice and Devin agent adoption programs for enterprise data and engineering teams.
We will walk your current setup with you and tell you plainly whether a platform like this is worth it for an organization your size. If it is not, we will say so.