Our Developer Died. I Rebuilt Our Nonprofit’s App with AI Coding in Six Months

Before the Crisis

My name is Chris Conlee. For nearly 30 years, I edited television — shows like The Flash and FBI for CBS. My wife Shashana was Head of Hair and Makeup on productions like Dancing With The Stars. We lived in the high-pressure, high-glamour world of Hollywood production.

We didn't plan to start a nonprofit.

During COVID, Shashana and I watched smaller charities — the ones without endowments or celebrity ambassadors — doing the heavy lifting in our East LA community and beyond. One evening she said to me:

"If only we had a dollar from everybody who cared, we could solve these problems."

That sentence became PIFster.

We call it "the LA math." There are roughly 10 million people in Los Angeles. If just one in ten gave a dollar, that's a million dollars a month to help people with. It hasn't happened yet, of course. But that's the dream — and it's the math that makes you believe it's worth trying.

The concept was simple: a pay-it-forward platform where subscribers — starting at $1/month — collectively vote each month on which charity receives the community's pooled donations. Not a GoFundMe. Not a foundation. A democratic giving community where every voice carries equal weight.

I designed the whole thing in my head and on Canva. Then we hired Roy Tuli and his team at Emobx in India to build it as a mobile app. Roy was talented, enthusiastic, and believed in the mission. Our early supporters were largely friends and family — lots of film industry people, because that's where Shash and I came from.

For a while, it worked.

The Triple Threat

Then everything collapsed at once.

The Hollywood strikes. The entertainment industry shut down for nearly a year. Both Shashana and I were out of work. Many of our early supporters — actors, crew members, production staff — were suddenly fighting to pay their own rent. Subscriptions dropped.

The Hollywood fires. Some of our supporters didn't just lose work. They lost their homes. The community we'd built shrank as people dealt with genuine survival emergencies.

Roy's death. After a period of radio silence — during which we were getting escalating bug reports and usability problems from our members — Roy's team contacted us. Roy had died suddenly and unexpectedly of appendicitis. He was gone, and we were essentially locked out of our own codebase.

No developer. No access to the code. No budget to hire a replacement. A subscriber base that was shrinking. A mobile app that was becoming less stable by the week.

The rational thing to do was shut it down.

The Bet

I'm a US Army veteran of the first Gulf War. Quitting wasn't an option.

Since I wasn't working anyway — the strikes had seen to that — I made a decision that my wife probably thought was insane: I was going to rebuild PIFster myself.

Some context on why that sounds absurd: I have a degree in Computer Systems Engineering from 1989. My formal coding education was FORTRAN and COBOL. I never worked professionally as a developer. The gap between "I took CS classes during the Reagan administration" and "I'm going to build a production web application that handles real money" is approximately the width of the Grand Canyon.

But I'd been reading about AI coding agents. Not the hype pieces — the actual developer experience reports. People were building real things with tools like Cursor and Windsurf, using large language models as pair programmers. The models weren't perfect, but they could write code, explain code, and catch errors at a level that seemed... maybe sufficient? If you knew what you wanted to build and had the discipline to verify what they produced?

I locked myself in a room. Fourteen hours a day, seven days a week, for six months.

The Stack Decision

First decision: not a mobile app. We'd been burned by the dependency on a single mobile developer and a proprietary codebase. The rebuild would be a web application — accessible from any device, controllable by me, deployable without app store approval cycles.

I chose WordPress. Not because it's fashionable (it isn't, in developer circles) but because it's the platform I could actually operate as a solo non-developer:

• Huge ecosystem of plugins for things I didn't want to build from scratch (payments via FluentCart, forms via ACF)
• Breakdance Builder for the presentation layer — visual enough that I could design pages, but with code block elements where I could drop custom functionality
• A hosting environment I could manage myself (an SSD Nodes VPS with CloudPanel at ~$43/month total)

For the actual application logic — voting, referrals, gift memberships, donation processing — I built a custom plugin (pifster-core) in PHP 8.3 with strict typing. Not because I knew PHP. Because the AI agents knew PHP, and WordPress runs on PHP, and that was the shortest path to production.

The Workflow: Three-Way Alignment

Here's the part that might actually be useful to someone else in a similar position.

I don't use AI the way most tutorials describe. I don't type "build me a voting system" and accept whatever comes back. The code that approach produces is fragile, inconsistent, and full of subtle bugs that you won't catch if you don't understand the architecture.

Instead, I triangulate between multiple AI models:

Windsurf (Cascade) — my primary coding partner. This is where the actual code gets written, in-IDE, with full context of the project. I use whichever underlying LLM is strongest at the time. Windsurf sees my file structure, my existing code, my type signatures. It's a pair programmer that never sleeps.

Google Gemini Pro — my architecture advisor and devil's advocate. I have access to Gemini through a heavily discounted Google Workspace account (Google offers significant nonprofit pricing). Gemini has a massive context window, which I use for a different purpose than line-by-line coding: I feed it large chunks of the codebase and ask it to critique the architecture, find inconsistencies, or evaluate a design decision before I commit to it.

The process:

1. I describe what I want to build — in plain English, with the business logic explained
2. I discuss the approach with both Windsurf and Gemini, separately
3. I look for where they agree — that's usually the right direction
4. I look for where they disagree — that's where I need to think harder
5. When I have a three-way alignment (both AIs and my own judgment), I execute in Windsurf
6. The code must pass PHPStan Level 8 before I consider it done

Learning What Good Looks Like

Before I wrote a single line of application code, I spent time asking the AI a different kind of question: What makes good software? What are the hallmarks of well-designed systems? What patterns do professional teams use, and why?

Immutability came up early. I didn't fully understand it at first — the idea that objects shouldn't change after creation felt strange coming from a world of FORTRAN variables. But I started asking that we enforce it to the fullest extent possible within the constraints of a WordPress ecosystem. DTOs became readonly. Entities controlled their own state transitions. Value objects replaced raw strings.

Then Domain-Driven Design. Then dependency injection. Then the repository pattern. Each concept started as something I'd read in an AI response, half-understood, and then insisted we implement. The AI would explain why a pattern existed; I would decide whether it applied to our situation; then we'd enforce it everywhere.

This is the part most "vibe coding" stories skip. They go straight from "I asked AI to build me a thing" to "look, it works!" But the gap between code that works and code that keeps working as you add features is enormous. The principles I absorbed early — immutability, composition over inheritance, contracts via interfaces, single responsibility — became the guardrails that kept 57,000 lines of code from collapsing into a ball of mud.

Logging was another early decision. As a single developer, I knew I'd need to keep an eye on the logs to know what was working and catch problems before users reported them. When Gemini suggested a BaseService class with consistent, structured logging built in, I started demanding that every service extend it. Now every significant operation — donations, votes, referrals, gift card redemptions — writes a structured log entry. When something breaks at 2 AM, the log tells me exactly what happened, in what order, with what data. That's not a luxury; for a solo operator, it's survival.

I didn't learn these concepts from a textbook. I learned them from arguing with two AI models about whether a class should be final, and then watching what happened when I followed their advice versus when I didn't.

PHPStan Level 8: The Quality Gate That Saved Me

PHPStan is a static analysis tool for PHP. Level 8 is its strictest setting. It catches type errors, null safety violations, unreachable code, incorrect function signatures — the kinds of bugs that would otherwise show up in production at 2 AM when a donor's payment fails.

I enforced Level 8 from the very first commit. Not after the code was working. Not as a "nice to have." From the start.

This was the single best decision I made, and it was counterintuitive. You'd think a non-developer working with AI would want less strictness, not more. But the opposite is true: AI-generated code needs more rigorous verification, not less. The models are fluent — they produce code that looks correct, that reads like it was written by someone who knows what they're doing. But fluency is not correctness. PHPStan catches the gap.

Every time Windsurf generated a function, PHPStan told me whether the types were actually consistent. Every time Gemini suggested a refactor, PHPStan told me whether the refactor broke any contracts. It was my automated code reviewer — one that couldn't be charmed by confident-sounding explanations.

Periodic Full-Codebase Audits

Every few weeks, I run what I call a "codebase audit." I take the entire pifster-core plugin — every PHP file, every service class, every handler — and feed it to a large-context-window model. Then I ask specific questions:

• "Where are the inconsistencies in how I handle error states?"
• "Which services have responsibilities that should be split?"
• "Are there any places where I'm violating the patterns I use everywhere else?"

The model doesn't always get it right. But it catches drift — the slow accumulation of inconsistencies that happens when you're building fast and focused on features. I then spend time wrangling the code into best practices based on what the audit surfaces.

This is the unsexy part. It's not building new features. It's going back through code that already works and making it consistent. But consistency is what separates a codebase that one person can maintain from a codebase that collapses under its own weight.

What Got Built

In six months, the platform went from "locked out of a broken mobile app" to a production web application handling real donations, real votes, and real charity distributions. Here's what's in the codebase — and I've written detailed technical posts about each of these, with actual code from the production system:

• Pay-what-you-want checkout — Ghost products in FluentCart that accept any donation amount from $1 up, with optional fee coverage
• Passwordless magic link authentication — No passwords, no friction. Email a link, click it, you're in.
• Gift memberships — 12-month vesting schedules with pessimistic locking and auto-referral attribution
• Gamified referral engine — Closure table pattern for the referral graph, monthly leaderboard, vote power multipliers
• Charity suggestion form — Typeahead search with popularity ranking, four-layer bot protection, fingerprint-based idempotency
• Democratic voting system — Monthly voting cycles, direct donations with bonus votes, runner-up carry-over

Each of those links goes to a post with real PHP, real SQL, real architectural decisions. They're not tutorials written from theory. They're explanations of code that's running in production right now.

By the Numbers

For the skeptics who want to know the actual scope — here's the pifster-core plugin as it stands today:

A few things jump out. 308 of 345 classes are final — that's composition over inheritance enforced almost everywhere, not by accident but because the AI agents and I agreed early on that sealed classes prevent the kind of fragile inheritance hierarchies that make codebases unmaintainable. The 45 interfaces represent real architectural contracts between layers, not ceremony. And every one of those ~57,700 lines passes PHPStan's strictest analysis.

This isn't a prototype. It's the production system that processes real donations.

What the AI Got Wrong

I'd be lying if I said this was smooth. AI coding agents are powerful, but they have failure modes that a non-developer needs to learn the hard way:

[PLACEHOLDER: Example 1 — biggest architectural mistake the AI led you toward]

[PLACEHOLDER: Example 2 — recurring code quality issue you learned to watch for]

[PLACEHOLDER: Example 3 — a domain-specific thing the AI consistently gets wrong]

The pattern I've learned: AI is excellent at implementing a well-defined solution. It's mediocre at choosing the right solution. That's the human's job — and it's the job that the three-way alignment process exists to support.

What It Costs

The total monthly cost to run PIFster in production:

Development tools:

There is no engineering team. There is no DevOps person. There is no QA department. There's me, two AI agents, and a static analysis tool that doesn't care about my feelings.

What This Means (Beyond PIFster)

There are thousands of small nonprofits running on a single contractor's custom code, one accident away from the same crisis we faced. There are thousands of founders with technical visions and no technical co-founder. There are thousands of "accidental CTOs" maintaining systems they didn't build and don't fully understand.

The barrier to building software has fundamentally changed. Not disappeared — I worked 14-hour days for six months, and I had enough engineering background to know what questions to ask even if I didn't know the answers. This isn't "no-code." It's "AI-augmented code by someone willing to learn."

But the change is real. A year ago, PIFster would have died with Roy. Today it's a production platform with strict type safety, real money flowing through it, and a codebase that one person can maintain and extend.

If you're a nonprofit operator staring at a legacy system you can't modify, or a founder who's been told you need $200K and a three-person dev team: the math has changed. It's not easy. It's not magic. But it's possible in a way it wasn't before.

And if you have a dollar and you care, we'd love to have you vote.

PIFster is a community-driven charitable giving platform where donors vote on which charity receives the community's pooled donations each month. Built by one non-developer with AI coding agents. Running on $43/month. Passing PHPStan Level 8.