Student project: move a nonprofit off rented technology

We did this for ourselves in a day with an experienced engineer and an AI assistant. Done carefully by a student over a semester, with a real nonprofit as the client, it is one of the best portfolio projects we know: it touches cloud, DNS, identity, automation, accessibility, and writing, and it ends with a real organization spending less money. This brief is written for a student, a faculty sponsor, or a nonprofit that wants to host one.

The problem the student solves

A small nonprofit pays monthly for a website builder (and often for separate forms, storage, and email tools), cannot easily edit or export its own content, and would struggle to leave. The student replaces the website with plain files the nonprofit owns, hosted on a major cloud for cents per month, published automatically from a code repository, and documented so a non-technical staff member can make changes afterwards.

Who it is for

A student who has written some HTML and run commands in a terminal. No prior cloud experience is required; the project teaches it. It fits a capstone, an internship, an apprenticeship rotation, or a self-directed portfolio project. One student can do it; two is comfortable.

What the nonprofit provides

• Ownership of its domain name and a login to wherever its DNS is managed.
• A list of every current page and which ones matter.
• About two hours of a staff member’s time per month for decisions and review, plus one hour for the handover.
• A credit card for the cloud account (expect under five dollars a month; the first year is often free-tier).

Milestones

Weeks 1–2: Discover. Inventory every page and URL of the current site. Interview the staff about what they edit and how often. Record the current recurring costs. Deliver a one-page findings memo and a proposed page list.

Weeks 3–4: Build locally. Set up the repository from the kit. Write the pages as sources. Run the build and the checker until the site passes with zero problems. Deliver a preview the client can click through on a laptop and on a phone.

Weeks 5–6: Stand up the infrastructure. Create the cloud stack from the template on a staging hostname. Connect the repository’s publishing job. Prove that a one-line edit on the code host’s website is live in minutes. Deliver the staging URL and a short screen recording of a change going live.

Weeks 7–8: Redirects, accessibility, and content review. Build the old-URL redirect map. Run an accessibility check on every page and fix what it finds. The client reviews the copy. Deliver the redirect map and a checklist of accessibility fixes made.

Weeks 9–10: Cut over. Move the apex and www hostnames to the new site without touching mail records. Monitor old URLs for a week. Deliver a cutover log: what was changed, when, and how to reverse it.

Weeks 11–12: Hand over. Write the maintenance guide in the client’s words. Record two short screen recordings: editing a page, and adding a photo. Cancel the old platform with the client. Present the before-and-after cost and a lessons-learned write-up.

Deliverables

1. The repository, with a README and a maintenance guide a non-technical person can follow.
2. The live site on the nonprofit’s domain, passing the automated checks.
3. The redirect map covering every old URL.
4. Two screen recordings (editing a page; adding a photo), each under five minutes.
5. A written case study, de-identified if the client prefers, that another nonprofit could learn from. We will publish it here with the client’s consent.

Grading rubric (100 points)

• Working system (30). The site is live on the client’s domain, publishes from the repository automatically, and passes the checker with zero problems.
• Client ownership (20). The client can make a text change and add a photo without the student, demonstrated live at handover.
• Continuity (15). Every old URL redirects; mail kept working through cutover; the cutover log is complete enough to reverse.
• Accessibility and performance (15). Every image has alt text; the site is usable with a keyboard and a screen reader; pages load fast on a phone.
• Security hygiene (10). No long-lived cloud keys anywhere; the bucket is private; the publishing identity is scoped to one repository and one branch; the student can explain why each of those matters.
• Communication (10). The findings memo, the maintenance guide, and the case study are clear to a non-technical reader.

What the student learns, in the language of a résumé

Static-site architecture and build automation; object storage and content delivery networks; TLS certificates and DNS (including the difference between a website move and a mail move); short-lived federated identity instead of stored keys; infrastructure as code; continuous deployment with automated quality gates; web accessibility; technical writing for non-technical readers; and client management with a real organization and a real budget.

Rules we ask every student to follow

• The client makes every decision that touches money, identity, or DNS. The student prepares the change and explains it; the client clicks.
• Never store a cloud access key in the repository or on a laptop. The kit’s publishing job does not need one.
• Do not cancel the old platform until the new site has served the real domain for a week.
• Write the maintenance guide before the handover meeting, then test it by having the client follow it while you watch and say nothing.

How to start

Fork the kit from our repository, read the implementation plan in this section, and find a nonprofit. If you are a student who wants a client, or a nonprofit who wants a student, write to us at hello@hackingtheworkforce.org with the subject “Site kit” and we will try to match you.