Choosing a Tech Stack for Non-Profit Projects

The most common mistake I see developers make when building for non-profits is choosing the stack they'd enjoy most rather than the stack the organization can maintain.

You won't always be there. The client will need to update content, fix broken links, and maybe add a new page someday. The question isn't "what's the best tool?" — it's "what's the best tool for this team?"

The questions I ask first

Before recommending anything, I try to answer:

1. Who will maintain this after launch? A technical volunteer? A non-technical program director? An outsourced IT firm?
2. How often does content change? Daily? Monthly? Rarely?
3. What's the budget for hosting and ongoing costs?
4. Will this need custom integrations (Salesforce, donation platforms, email marketing)?

The answers usually point pretty clearly at the right approach.

The three tiers I use

Static site with a headless CMS

For organizations that need a public-facing website with regularly updated content — event listings, news, staff pages — this is my default.

• Framework: Next.js
• CMS: Sanity or Contentful (both have free tiers)
• Hosting: Vercel (free tier covers most non-profit traffic)

A non-technical staff member can update content in a clean editor UI. A developer (or volunteer) can push code changes when needed. Total monthly cost: often $0.

Full-stack web app

For tools like volunteer portals, donor dashboards, or internal management systems:

• Framework: Next.js (API routes handle the backend)
• Database: PostgreSQL via Supabase or Neon (both have generous free tiers)
• Auth: NextAuth or Clerk

This is more expensive to build but gives you full control. Good when off-the-shelf tools don't fit the workflow.

Buy before build

Sometimes the right answer is to not build anything. Salesforce has a non-profit edition. Many volunteer management and donor tools have non-profit pricing.

I always explore this option before proposing custom software. Custom software has a maintenance cost — buying software transfers that cost to the vendor.

What I've stopped recommending

• WordPress: Unless the client has existing WordPress expertise, the security surface and plugin ecosystem are more trouble than they're worth.
• Overly complex CI/CD: If the deployment process requires a developer to push changes, content editors are blocked. Vercel's GitHub integration is as simple as it gets.
• Self-hosted databases on VMs: Without a dedicated DevOps person, these become liabilities. Managed databases (Supabase, Neon, PlanetScale) are the right default.

The meta-principle

Build for the person who comes after you. The best tech stack for a non-profit is the one that keeps working when you're not around to fix it.