Cathonect: Secure Assisted Member Onboarding

Helping Catholic churches securely digitize members and connect them to their existing parish records.

Comment

Inspiration

Cathonect grew from a problem I have seen directly in Catholic church leadership.

Many parishes and outstations still rely on paper forms, spreadsheets, WhatsApp groups, personal phones, and the memory of current leaders. When leadership changes, records become scattered, processes are repeated, and valuable institutional knowledge can disappear.

My larger vision is for Cathonect to become an institutional operating system for the Catholic Church, beginning with parishes and outstations in Ghana and eventually supporting deaneries and dioceses. It is not only about digitizing forms. It is about preserving institutional memory, improving continuity, and helping church leaders coordinate people and ministries using reliable information.

For that vision to work, member onboarding must be safe and practical. A parish record may be created by a church officer before the member has an online account. The member must later be able to claim that record without the officer controlling their account, exposing private information, or creating duplicates.

During Build Week, I used GPT-5.6 through Codex to strengthen this foundation.

What it does

Cathonect already had Members and Leaders PWAs, assisted registration, member records, account claiming, attendance, groups, approvals, and role-based access.

My Build Week work focused on making assisted member onboarding more secure, reliable, and recoverable.

I added a controlled photo workflow that allows an authorized church operator to add the first profile photo to an unclaimed member record. The operator can take a photo or choose one from the device, crop it, upload it, and follow clear progress and error states.

The browser never receives the permanent private storage path. Photos pass through temporary private storage, server-side validation, normalization, controlled finalization, and authorized short-lived display links.

I also improved member enrollment so incomplete or stale form values no longer cause silent failure. The form now shows the exact problem and focuses the first invalid field.

The largest extension was a server-owned OTP transaction lifecycle for signup, member claiming, phone correction, and password recovery. It supports:

  • Recovery after a page reload
  • Resuming without automatically sending another SMS
  • Correcting a wrong phone number without losing entered details
  • Protection against old-code reuse
  • Idempotent retries after interrupted responses
  • Duplicate-account protection
  • Durable account-completion and session milestones
  • Request limits, expiry, replay protection, and safe cleanup
  • Network-only handling for authentication APIs inside the PWA

How we built it

Cathonect is built with React, TypeScript, Vite, Supabase, PostgreSQL, Supabase Auth, Storage, Edge Functions, Deno, Vercel, and Progressive Web App technology.

I used GPT-5.6 in Codex to investigate the existing system across the frontend, database, authentication, storage, Edge Functions, and SMS-provider boundary.

Codex helped me trace failures, compare recovery designs, identify race conditions, implement database migrations and frontend changes, expand tests, and repeatedly review the security model.

I made the main product and safety decisions, including:

  • Auth accounts must not be created before OTP verification succeeds
  • Church officers must not control members' personal accounts
  • Private storage paths must not be exposed to the browser
  • Lost responses must be recoverable without duplicating irreversible actions
  • Production must not be used as a testing environment
  • Unreviewed provider evidence must remain behind a release gate

The implementation uses Row-Level Security, fixed database search paths, narrowly authorized server functions, explicit grants and revokes, private storage, signed URLs, transaction locks, replay protection, idempotency, and environment separation.

Challenges we ran into

The greatest challenge was that OTP verification is not a single action.

It crosses the browser, PWA, SMS provider, Supabase Auth, Edge Functions, PostgreSQL, account creation, database completion, sign-in, and unreliable mobile networks.

A timeout does not always mean an operation failed. The SMS may have been accepted, an account may have been created, or the database may have completed even though the response never reached the user.

The solution was to stop treating onboarding as a temporary sequence of frontend screens and instead model it as a durable server-owned transaction with revisions, milestones, authorization checks, and safe recovery.

The photo flow had a similar challenge. The experience had to remain simple for a church officer while still preventing unauthorized access, duplicate finalization, unsafe image content, and exposure of private storage details.

Accomplishments that we're proud of

During Build Week, I completed:

  • A secure assisted-photo backend and mobile-first interface
  • Private temporary uploads and server-side image processing
  • Authorized signed-photo retrieval
  • Safe handling of competing operator uploads
  • Accessible enrollment validation with first-invalid focus
  • A durable OTP transaction model
  • Wrong-phone correction
  • Reload-safe recovery
  • Response-loss-safe retries
  • Duplicate-account and claim-ownership protection
  • PWA protection against cached authentication responses
  • Extensive database, Deno, browser, migration, security, type, and build validation

The assisted-photo workflow was successfully rehearsed in staging using synthetic records and storage objects.

The OTP transaction v2 branch passed extensive local database, concurrency, Edge Function, browser, security, typecheck, and build validation. It was not applied to staging or production during Build Week, so this submission does not claim that its provider-backed end-to-end journey is currently available through the deployed application. The remaining staging migration, configuration, provider evidence, and physical-device verification must be completed before release.

What we learned

I learned that secure onboarding is not simply about checking a six-digit code.

The system must prove that the correct person, phone number, member record, transaction revision, verification challenge, and requested action all belong together.

I also learned that retries must be designed from the beginning. Mobile networks and external providers can return uncertain results, so a reliable system must determine what already succeeded before trying again.

Finally, I learned that accessibility improves safety. Clear errors, focused fields, explicit progress states, and predictable recovery reduce confusion and prevent repeated unsafe actions.

What's next for Cathonect: Secure Assisted Member Onboarding

The next steps are to complete the remaining staging provider review, run physical-device camera and onboarding checks, and merge the work through the existing release process.

After that, I plan to build Cathonect's internal church onboarding dashboard so that new parishes, outstations, leaders, and members can be configured without depending on manual SQL.

The larger goal remains to help Catholic institutions preserve their records, maintain continuity through leadership changes, and build a reliable institutional memory.

Built With

Share this project:

Updates