JSM Makassar — Membership & Commitment Tracking Platform

Role: Solo Developer & Product Partner Timeline: 3–4 months | 2025–2026 Stack: Vue 3 · Supabase · TailwindCSS · PWA Type: Nonprofit Internal Platform

The Problem

JSM Makassar is a Catholic community organization in Makassar with a layered structure: members belong to small groups called cells, cells roll up into groups, and each members operate across service teams with their own coordinators. Tracking membership, organizational assignments, and weekly spiritual commitment reporting across all of that? Spreadsheets and WhatsApp.

This wasn’t the first attempt to fix it either.

Two previous systems had already failed. The first, back in 2013–2014, collapsed under low digital literacy — most members simply couldn’t use it. The second was lifted directly from a similar organization and slowly died because it never fit JSM’s specific structure. By the time this project kicked off, there was a real trust deficit to overcome, not just a technical gap to close.

When I was asked to take this on, I understood what was actually at stake. Shipping something functional wasn’t enough — it had to be something people would trust, adopt, and keep using.

The Approach

Before writing a line of code, I mapped the organizational reality: how cells form into groups, how coordinators are structured at each level, and what “weekly commitment” actually means in this context (logging spiritual practices — daily prayer, attending mass, and similar commitments). Getting the data model right was the foundation everything else depended on.

A few deliberate decisions shaped the build:

Role-based access, built around real org structure. The platform has five distinct roles, each with scoped permissions that mirror how the organization actually operates. This wasn’t just a permissions matrix — it was a translation of organizational culture into access logic, enforced at the database level via Supabase RLS.

Frictionless onboarding via magic links. Admins pre-register members, who receive a magic link invitation, land on a setup page to set their password and complete their profile, and are immediately activated. No manual back-and-forth, no IT support required. And Google login is available for users who would like to use it.

PWA over native. Installing the app had to be zero-friction — no App Store, no updates to manage. A Progressive Web App lets members install directly from their browser onto their phones, which matters a lot when your user base spans a wide range of technical comfort levels.

Period-based reporting structure. The platform runs on defined time periods, with commitment reporting windows across monthly, quarterly, and 6-month views. Leadership can track engagement trends over time, not just snapshot activity.

Designed for solo maintainability. Modular Vue 3 components, clean Supabase RLS policies scoped to each org node, and production-safe change discipline — because after I ship this, I’m still the one maintaining it.

The Results

• 200+ active members onboarded across the platform
• 20+ cells organized across 4 distinct groups and multiple service teams
• 50–60% regular usage rate — a meaningful baseline for a community that had no prior digital infrastructure
• Leadership tracks engagement trends through analytics dashboards, replacing WhatsApp-based guesswork
• The organization went from two abandoned systems to one they actively use — which, given the history, is the real win

What I Learned

Building for a community you belong to is a different kind of pressure. You have context no external contractor would — but the accountability is personal, not just professional. That pushed me to prioritize adoption from day one, not just delivery.

The technical choices here were almost secondary to the product ones. The harder work was earning back confidence in digital tooling after two failed attempts — and building something simple enough that it didn’t need a manual, robust enough that it wouldn’t quietly die like the ones before it.