I recently started a work-study position developing websites for a nonprofit. I have experience with web applications and some hands-on knowledge of Python, JavaScript, HTML, and CSS, while my coworker is also a student developer. We have been asked to rebuild the organization's website from scratch and move away from its current WordPress and Bluehost setup.
We plan to use GitHub for version control, and we are open to changing both the hosting provider and the technology stack. The site will need cloud hosting, and we are not planning to self-host infrastructure. Astro and Payload are two options we have been considering, but we are open to other recommendations.
The site will be mostly hand-coded, with no strict deadline. However, nontechnical staff must be able to manage content such as images, blog posts, and other recurring pages without editing source code. We want a solution that gives us strong control over the code, integrates cleanly with a CMS, avoids excessive vendor lock-in, and can be deployed to different hosting providers.
The finished website should look professional, communicate the nonprofit's story effectively, attract donors and investors, and serve the target community. The organization has said not to worry too much about subscription or platform costs, but we still want to understand the ongoing hosting, maintenance, and management requirements. What stack and CMS would you recommend, and what should we clarify before making the decision?
3 Answers
Design this for the organization after you leave, not just for the current development team. Find out who will own the site when the work-study placement ends, how comfortable they are with content management, and whether another developer or hosting provider may need to take over later. Favor widely documented tools, simple deployment, clear setup instructions, backups, monitoring, and an administrator account that the organization controls.
Also get actual figures for hosting, maintenance, paid services, backups, domains, forms, analytics, and donation integrations. A CMS can be technically flexible but still become difficult if nobody is available to maintain it.
Start by documenting exactly what the staff need to publish before choosing a framework. Ask them to walk you through their current workflow and identify the content types, page templates, approval steps, user roles, image handling, and publishing schedule they need. Once those requirements are clear, choosing between Astro, Payload, or another CMS becomes much more straightforward.
Keeping the build in-house makes sense if you and the other developer can support it, but avoid outsourcing the entire project before you understand the requirements. A headless CMS paired with a framework such as Astro can provide a fast, polished frontend while allowing staff to edit structured content. Payload may be a good fit if you want the CMS and application code under your control, but make sure you are comfortable operating its database, deployments, updates, authentication, backups, and media storage.
Before committing, map the donation and investor journeys, identify third-party integrations, define the content model, and build a small proof of concept. Test both the editor experience and the deployment process with someone who is not a developer. The best stack is the one the nonprofit can realistically operate and hand off, not necessarily the newest one.
Related Questions
How to Build a Custom GPT Journalist That Posts Directly to WordPress
Cloudflare Origin SSL Certificate Setup Guide
How To Effectively Monetize A Site With Ads