What rebuilding a small nonprofit's website taught me about leading with AI
For years I've volunteered as the designer and maintainer of the website for The Jamin Fund, a small Colorado charity that supports education and leadership in memory of Jamin B. Wilson. Jamin was a close friend throughout high school and college. We shared a love of all things Apple, creative coding, and learning for its own sake.
Recently a volunteer reported a strange bug. One of the tiles on the home page, "School Building Projects," only worked if you clicked it very quickly. Wait a moment and the link went dead.
The fix turned out to be two lines of HTML. What I learned from fixing it took a lot longer to work through.
Small bugs expose big risks
Each tile on that page is two stacked images. A cover image fades out when you hover, revealing a second image underneath. On every other tile, both images were links. On this one, the hidden image had no link. A quick click landed on the cover; a slow click landed on a dead picture. While tracing it, I found a second error: on the mobile layout, the same tile showed another program's image.
Those were easy fixes. The trouble was where I had to make them. I built the site years ago in a Mac site builder that has since gone quiet, using third-party add-ons that no longer get updates. News posts ran through a CMS plugin I had come to treat as too fragile to touch. I couldn't trust the builder to regenerate the site, so I patched the published HTML by hand.
That's a familiar pattern for anyone who has managed technology in a legal organization. A small symptom points to a system that works only as long as nobody changes anything. The real question isn't how to fix the bug. It's whether the system can survive its maintainer moving on.
The first answer was good, not right
I worked through the rebuild with Claude, Anthropic's AI assistant, as a hands-on collaborator. It diagnosed the tile bug by inspecting the live page, then laid out the options for a more sustainable site: a static site with a web editor, a hosted platform like Squarespace, WordPress, or freezing the site as it was.
We settled on a static site. The first build was solid. Every page was regenerated, every news post was converted and checked word for word, and a free hosting platform handled publishing through a hosted, form-based editor. Technically, it was a good answer.
Then I asked two questions.
"Doesn't that platform eventually cost money?" When the AI checked, it found that the free plan has a hard usage cap that takes the site offline if it's exceeded. It acknowledged that it had underweighted that risk and suggested a different provider.
"Won't any outside service change on us?" This was the more important question. Every hosted service changes its terms, pricing, and features on its own schedule. The old site had real flaws, but one thing about it was right: everything lived on one host the Fund already paid for. My goal was simple. If I get hit by a bus, someone should be able to take this over without much thought.
That question reset the design.
Designing for the person who comes next
The final system runs entirely on the Fund's existing web host. There is no code repository, build service, or third-party platform. Visitors receive plain static HTML pages. When a volunteer saves a post, a small PHP program regenerates the affected pages, which takes about three hundredths of a second for the whole site.
Each choice traces back to a person rather than a technology:
- The volunteer who posts updates. Not a technologist, but someone who follows instructions well. That ruled out anything Git-based and led to plain-language screens, checkboxes instead of typed tags for choosing which program pages a post appears on, and one-click restore of earlier versions.
- The visitor. Because visitors get static pages, a future server upgrade can break the editor, but never the public site.
- My successor. The system is about 1,300 lines of plain PHP with no frameworks, libraries, or databases. Every post is a self-contained file any future platform can import. A README explains the system to whoever inherits it, and one button downloads a full backup.
- The board. The new site goes in beside the old one, and switching between them is a single hosting setting. Every old link still works. A change that's easy to reverse is easy to approve.
The new site is built and tested, and it goes live once the volunteer editor has walked through it.
What the AI did, and what I decided
The speed was remarkable. From the first bug report to a tested deliverable took about a day. In that time the AI:
- Migrated all 57 news posts and verified each one word for word against the original
- Moved 240 photos, shrinking them from about 120 MB to 34 MB for the web
- Generated 76 pages and set up redirects so old addresses still work
- Set up a copy of the hosting environment and ran 46 automated browser tests, which caught 2 real bugs before anyone else saw them
- Wrote the maintainer guide, the go-live checklist with a rollback plan, and a one-page guide for the editor
None of that decided what the system should be. The AI's first recommendation was reasonable and well built. It also optimized for the wrong thing. What made the result better was a human asking questions grounded in the organization's reality: its budget, its volunteers, and its tolerance for change.
I don't count that as a failure of the AI. That's the job description for anyone leading with it.
Lessons for legal technology leaders
This was a volunteer project, but the lessons are the same ones I apply to case management systems, AI rollouts, and integrations at work.
- Process before technology. Start with who will use the system, who will maintain it, and what happens when they leave. Then choose the tool.
- Treat the AI's first answer as a draft. It's often technically sound. Whether it's right depends on context the model doesn't have unless you supply it.
- Ask the boring questions. What does it cost when we outgrow the free tier? Who owns the vendor relationship? What happens when the terms change? Those questions changed this project more than any technical choice did.
- Optimize for the bus factor. Fewer vendors, plain data formats, and documentation written for a successor make a system durable. Clever architecture doesn't.
- Verify, don't trust. Word-for-word content checks and real browser tests caught problems that a quick review would have missed. In legal work, that discipline isn't optional.
- Make change reversible. A rollout that can be undone with one setting is much easier for leadership to approve.
Building is cheap now. Judgment isn't.
AI has made building fast and inexpensive. A volunteer with a capable assistant can now produce in a day what used to take weeks. That shifts the scarce skill from building to deciding: what's worth building, for whom, and how it holds up after you're gone.
The Jamin Fund exists to pass on the qualities Jamin lived by: consistency, integrity, enthusiasm, wisdom, and joy, while helping others. A website that keeps working after its builder steps away is a modest way of honoring that.
If you maintain a system for a nonprofit, a firm, or a legal aid organization, ask who takes it over when you can't. Then build for that person.
To learn more about The Jamin Fund or support its work, visit jaminfund.org.