Allen Padilla

Manitoba Métis Federation • Shipped 2026

Member Management & Events Platform

The system of record for one of the organization's departments. Over 2,000 members, their regional locals, and every event they run. Staff sign in with their existing work accounts. Custom WordPress plugins connect the public site to the platform, so staff stop re-typing and members can update their own information.

Role
Sole developer
Timeline
Shipped 2026, ongoing support
Team
Solo, with the department's director and frontline staff as stakeholders
Stack
Laravel 13, Inertia, React 19, PostgreSQL, Azure AD SSO, OAuth2, WordPress

Context

One of the departments at the Manitoba Métis Federation had over 2,000 members, their regional locals, and the events they run, and all of it lived in different tools and spreadsheets. The public website kept its own copy of the member data too, so someone was always typing the same thing twice.

I sat with the people who'd be using it every day and worked from there.

Dashboard with the next event, member totals, and new-member counts by month, quarter, and fiscal year
The dashboard. The next event, member totals, and new members by month, quarter, and fiscal year, each one a link into the members list pre-filtered to that period.

Problem

I needed three things to be true at once.

  • Member records needed a real history. Staff had to see what changed and when, and get a heads-up on the changes that mattered.
  • Access had to follow the work accounts people already had. A separate list of users in the app would be out of date within a month.
  • The website needed live member data without anyone re-typing it.

Approach

  • Laravel 13
  • Inertia
  • React 19
  • PostgreSQL
  • Azure AD
  • OAuth2

It's Laravel 13 with Inertia and React 19 on the front, and PostgreSQL underneath.

Sign-in. Azure AD handles login. Directory groups map straight to roles in the app, so when someone changes teams, their access changes with them. Nobody has to remember to update a list.

Members and events. Member records track changes and raise alerts. Regional locals are their own thing, not just a text field. An event has registrations, guests, and a scan-in at the door, so the person at the door sees the same record the office does.

Members list with filters for citizenship, verification, and pending updates, names blurred
The members list. Filters for citizenship, verification, and pending updates sit right above the table.

Re-registrations. When a member re-registers on the website with different details, the record doesn't just update. Each changed field gets queued as an alert with the new value beside the current one, and staff accept or dismiss them one at a time. A verified member drops to pending review while alerts are open and goes back to verified once they're cleared.

Member detail panel showing a re-registration alert with the submitted value beside the current one
A re-registration with a new email. The submitted value sits beside the current one, with accept and dismiss per field.
Event page with attendance counts, an on-site tally, and the registration list, names blurred
An event on the day. Interested, attended, and an on-site count that resets each morning on local time, so a multi-day event starts every day at zero.
Events list with upcoming and completed counts and a quick scan button for the next event
The events list. Quick scan and directions for the next event are one tap away, which matters on a phone at the door.

The website. Custom WordPress plugins connect the public site to the platform's OAuth2 API. Member and event data flows out so staff stop re-typing, and member updates flow back in so people can keep their own information current.

Decisions

  • Azure AD groups map straight to roles instead of a user list inside the app, so access changes when someone changes teams and nothing goes stale.
  • A re-registration never overwrites the record. Each changed field becomes an alert with the new value beside the current one, and the member sits in pending review until staff clear them.
  • Regional locals are their own records, not a text field on the member.
  • Custom WordPress plugins connect the public site to the platform's OAuth2 API, so member and event data stays in sync both ways—staff stop re-typing and members can update their own information.
  • The on-site count resets each morning on local time, so a multi-day event starts every day at zero.

Outcome

This is the department's system of record now. Over 2,000 member records and every event since it launched. Staff sign in with their work accounts instead of a separate user list, and the website stays in sync on its own. I still deploy and support it on our self-hosted setup.

The code stays private, so I built Meridian to show the same stack and the same problems in public, with a fantasy guild as the vocabulary. Laravel, Inertia, React, and TypeScript, with Pest tests and CI.