Legacy takeover · Member platform
One platform, many associations.
A small association cannot fund a system of its own. Hunters Portal is the system they share: stabilised first, then rebuilt when the audit said it was time.
The situation
Hunters Portal is a multi tenant association platform, serving hunting and shooting associations. The multi tenancy is not an implementation detail, it is the reason the product exists. A small association managing a few hundred members has the same needs as a large one and none of the budget to build for them: member records, an activity log book, renewals, invoices. One platform carrying many associations is how those needs get met at a price the small ones can pay.
It reached us the way these systems usually do. Working, depended on, and built by people no longer around to change it. The previous developer had run the work through a rotating set of freelancers, and the code showed it: you could read the codebase and count the hands that had passed through, each with their own conventions, none of them written down. The member data was intact. The system holding it had run out of road.
What we did
We did not start with a rebuild. We started by making what was there work. The first job was getting the inherited codebase into a state where it ran predictably and could be changed without something else breaking. Only then did it get what the product actually needed, which was multi tenancy, and only then did we start onboarding the other associations onto it.
The audit had already named what was coming. The platform was built on a version of Angular that was years out of date, and upgrading the framework in place would have broken the system faster than it repaired it. So we said so, and then spent a year extending a system we had already recommended replacing. Rebuilding it that day would have cost the client more than it saved them, and the associations waiting to be onboarded could not wait for a new platform to exist.
The rebuild started a year later, on Azure with .NET Core and React. One developer, four months. Multi tenancy is the constraint that shapes every decision in a build like this: every query, every permission, and every invoice belongs to exactly one association and must never reach another one. On the inherited system that separation had to be retrofitted. In the rebuild it went into the foundations first, and everything else was built on top of it.
What sits above is the working life of an association: members and their records, the activity log book, endorsements, dedicated status applications, and the renewal and invoicing cycle that keeps the organisation funded. All of it shipped into the client's own repositories and cloud subscription.
Where it landed
Hosting costs came down 85%. Most of that is architecture rather than negotiation: a system designed for the cloud it runs on costs a different amount to keep alive than one lifted onto it. The platform runs as a Partner plan at $5,000 a month, which covers the hosting, the monitoring, the patching, and a backlog that keeps moving.
The rest of it is the part that does not show up on an invoice. What had been a codebase carrying the habits of every freelancer who passed through it is now one codebase on one workflow, built to a standard the next engineer will recognise on sight. The associations onboarded during the first year came across to the new platform without losing a year of waiting for it.
Your system could be the next one.
Hunters Portal was working, depended on, and unmaintainable. That is the ordinary starting point, and it starts with the audit.
Book the audit