PEx runs addiction-recovery programmes. There are facilitators, groups, a public directory people use to find help, a training academy, and paid subscriptions sitting behind all of it. For years that ran on a stack of no-code tools stitched together: Glide apps, a Webflow site, and a big web of Make.com automations. It worked until it didn't. Every new thing we needed meant another workaround, and nobody really owned the system.

The fix was a proper platform the team could actually own. The foundations, the stack and the architecture, were already in place by the time I joined, and a group of us built the apps on top of them. On the ones I owned I tended to work the same way: get the screens up first, then work backwards into everything that has to happen behind them.

What I worked on

This was a team build, so here's what was actually mine.

• Finder — the public "find help near me" directory, and the app I built most of. It's usually where someone looking for a recovery group starts, so it had to stay quick and calm to use, phone included.
• Register — member registration and check-in, handling dozens of new sign-ups a month. I built most of this too, swapping out a fragile third-party automation for something native and reliable and keeping the old links working through the move.
• Pulse — the internal CRM and task tool the team runs on. I built most of the rebuild that replaced an off-the-shelf app they'd outgrown.
• Bridge — the app facilitators are in every day, for their programmes, groups, attendance and training progress. This one was a bigger team effort that I contributed to, building screens and wiring up parts of what runs behind them.
• Payments — subscription billing through Paystack, moved out of third-party automation and into the platform itself. That part was mine.

Under the hood

For anyone who cares about the technical side, here's the shape of it:

• A Turborepo monorepo of Next.js apps on one shared Supabase / Postgres backend.
• Bridge pulls in Thinkific, DocuSeal and Shopify over webhooks. Every payload gets validated with Zod and checked by signature before it's trusted, and state changes like join requests and attendance run as atomic Postgres operations.
• A performance pass on Bridge, using React use cache, concurrent data fetching and server-rendered shells, to keep it quick under real load.
• Smaller things that matter in use: Finder keeps its map mounted across view switches so it never reloads mid-search, and Register maps legacy record IDs onto the new system so old links don't break.

What went wrong, and what I changed

The honest bit. Failed payments used to quietly flip a subscription into an "attention" state and create a retry entry, with no email to the customer and no alert to staff. The failure just sat there. I worked on the transactional-email pipeline that closes that gap, so now a failed payment actually tells someone instead of quietly costing a renewal.

Outcome

The apps are in production now, on infrastructure the team actually owns, in place of tools they were renting and outgrowing. The load on Make.com dropped by roughly 90% as the automations moved into the apps themselves. And maybe the biggest thing: when something breaks now, it's our code and we can just fix it, which wasn't really true of the no-code stack before it.