Jun 29, 2025How I Built MethodistCRM: Laravel, Trials & Triumphs
Why Churches Need CRMs Too
The problem: A 200-member congregation tracking donations in Excel, with event RSVPs via WhatsApp. No joke—we once missed a funeral announcement because someone sent the invite to the wrong group chat. I knew we needed structure. My solution stack:
Laravel 5.6
MySQL (with regret)
jQuery (this was 2017, forgive me)The goal was to centralize communication, donations, and event coordination into one system that felt familiar but functioned far better. The congregation was small, but the feature requests were mighty: SMS reminders, attendance tracking, printable reports, and yes—dark mode. Naturally, I said yes to everything.
Architecture Mistakes → Lessons
This was my first attempt at a full-fledged app with real users (and real consequences). Some of my architectural sins still keep me up at night:
| Mistake | Fix | Salesforce Parallel |
|---|---|---|
| Monolithic controllers | Services pattern | Now advocate for Lightning Web Components |
| No testing | PHPUnit + CI | Enforce 80% coverage at Salesforce |
| Hardcoded logic | Config files & environment variables | 12-factor app principles |
| Direct SQL queries in blade templates 😬 | Repository pattern | Platform events and Apex triggers |
"Production outages are the best teachers. Especially when the 'production' is a Sunday service livestream."
The Easter Incident
The app went live a week before Easter. Spirits were high, the choir was rehearsing, and I was on the church Wi-Fi praying my background jobs didn’t break. They broke. Half the congregation couldn’t check in. The donation tracker failed to sync. And the projector displayed a Laravel stack trace instead of the call to worship. A literal `Whoops, something went wrong.` moment—in front of 200 believers.
I spent the next three nights debugging in the sanctuary, occasionally interrupted by choir practice and the odd mosquito. But I fixed it. And I learned that deployment isn't just technical—it's emotional. When people depend on your software in moments that matter, “just reboot it” isn't always an option.
Unexpected Wins
Despite the chaos, something magical happened: people started using it. Pastors loved the insights. Treasurers stopped emailing spreadsheets at 1am. A few younger members even volunteered to help add features. One of them now works in tech. And I realized—this wasn’t just an app. It was a bridge. Between old-school church tradition and modern digital workflows.
I later repurposed parts of the system for other organizations—small nonprofits, a local school, even a food bank. Each time, the core idea remained: build with empathy, not assumptions.
What I’d Do Differently (And What I Wouldn’t)
- Wouldn’t hardcode anything. Ever. Even the church name was a find/replace away from disaster.
- Would use migrations and seeding. Manual SQL is a form of penance I no longer practice.
- Wouldn’t ignore feedback. The best UX advice came from someone who didn’t know how to double-click.
- Would absolutely do it again. Imperfect code in a real-world context taught me more than any tutorial ever could.
Where It Led Me
That project gave me more than a bullet point on my resume. It gave me language. When I eventually applied at Salesforce, I didn’t talk about abstract skills. I talked about systems built under pressure. I shared that postmortem. I described what it felt like to deploy to a church full of people in their Sunday best. That story resonated more than any HackerRank score ever could.
Even today, when I design something at scale, I think about that tiny print shop and the church CRM. I remember that software is about trust, not just tooling. It’s about anticipating needs, not just shipping features. And it’s about people—messy, wonderful, non-technical people who just want things to work.
Lessons & Reflections
- Your messy side project might be your clearest case study.
- Real users are the best QA team you’ll never pay for (and possibly the loudest).
- Shipping imperfect code into a real-world context will grow you faster than 10 fake projects ever could.
This post offered an unexpected lens into the topic of "How I Built MethodistCRM: Laravel, Trials & Triumphs"—something I initially underestimated. What began as a routine story evolved into a surprisingly personal audit of where I’ve grown, where I’ve slipped, and what continues to challenge me. I realized that my path hasn't been about linear progress; it’s been a series of weird detours, punchline errors, and the occasional small win that gave me just enough momentum to keep going.
If there's a takeaway, it’s this: context matters. The same challenge that might’ve broken me five years ago now feels like a teachable moment. And maybe that’s the definition of growth. Thanks for sticking with the post—I hope your own journey is full of equally ridiculous, humbling, and surprisingly meaningful moments.