I recently started a work-study position doing web development for a nonprofit. Another student developer and I have been asked to rebuild the organization's current WordPress site from scratch and move away from its existing Bluehost setup. We'll use GitHub for version control, and we're open to changing both the hosting provider and the technology stack. Astro and Payload are two options we've been considering.
We'll be doing most of the development ourselves, and there's no strict deadline. The important requirement is that nontechnical staff should be able to publish and manage images, blog posts, and other recurring content without editing source code. We want a professional, appealing site that communicates the organization's story and supports donations, investors, and the broader community.
We're looking for a solution with a user-friendly CMS, good integration options, granular control over the code, portable hosting, and minimal vendor lock-in. Cloud hosting is required, although we don't have much infrastructure experience yet. Cost is not currently a major constraint, and I'm comfortable learning as I go. My background includes Python, JavaScript, HTML, and some CSS, along with experience building web applications.
What requirements should we clarify first, and which stacks or CMS platforms would be sensible for a small student team to build and maintain after the project is finished?
3 Answers
Keeping the build in-house makes sense if you and the other developer want control, but define the site structure before writing much code. Create a list of reusable content types and components, such as articles, staff profiles, projects, events, donation calls to action, and landing pages. Decide which fields editors can change and which parts must stay consistent in code.
Astro with a suitable CMS could be a good fit for a fast content-focused site, while Payload gives you more control over the content model and can live alongside a custom frontend. Just remember that the stack also includes deployment, image handling, authentication, backups, monitoring, and editorial training. Choose the simplest setup that meets the requirements and can be maintained by someone who did not build it.
Plan for what happens after your work-study placement ends. A nonprofit may eventually rely on volunteers, temporary staff, or another developer, so the system should be familiar, documented, easy to host, and straightforward to hand over. WordPress is still worth considering because it is widely understood, has a large pool of maintainers, and can support a custom theme while allowing staff to manage content through the admin area. A headless CMS can also work, but only if the organization is prepared to maintain the frontend, hosting, deployments, backups, and CMS separately.
Get concrete numbers for ongoing hosting, maintenance, updates, backups, security, and third-party services as well. Also inventory integrations early, including donation processing, email marketing, analytics, event tools, forms, and any investor or volunteer workflows.
That handoff question is probably more important than the framework choice. Document deployment, content editing, backups, and recovery procedures while you build instead of treating them as an afterthought.
Before choosing Astro, Payload, or anything else, talk with the staff who will actually maintain the site. Have them walk you through what they publish today, what frustrates them, which page types they need, who approves content, and what permissions different users should have. Once you understand the content model and workflow, the technology decision becomes much easier.
That makes sense. We’ll prioritize interviewing the staff and documenting the content workflow before committing to the frontend or CMS.