The clients saw the site and loved it. That was the payoff of several sessions of work together — and honestly, the part I’m most glad we didn’t skip happened before I opened a code editor.

I was helping Center X Equine Therapy, a 501(c)(3) nonprofit offering physical and occupational therapy through horses, build a website that felt polished, warm, and trustworthy. They pointed to The Shea Center as a reference — a well-regarded therapeutic riding program in Orange County — and asked for something in that spirit.

You can see where we landed at center-x-equine-therapy-site.pages.dev/programs. The build story is mostly research, planning, and small decisions that are easy to rush past when you’re eager to ship something visible.

The simple stuff that’s easy to overlook

When I started, I didn’t open a wireframe tool first. I looked at what already works for organizations like theirs.

I gathered reference sites from San Diego and Orange County — Ride Above Disability, Shea Center, Tara’s Chance, SD Therapeutic Horsemanship — and wrote down the patterns that kept showing up:

PatternWhy it matters
Emotional hero + one mission lineFamilies and donors understand the purpose quickly
Three CTAs: Donate, Volunteer, Get startedMatches how nonprofits actually convert
Parent quotes with namesNamed stories feel more trustworthy than generic “we help kids” copy
PATH Intl (or equivalent) badgeA familiar trust signal in therapeutic riding
”What is equine therapy?” explainerMany visitors are new to the concept
Meet the horses + sponsorshipEmotional connection and a path to recurring support

None of this is glamorous work. It’s the kind of thing that shows up again and again on sites that actually help people take a next step.

I kept this research in a dedicated project folder — separate from my general design knowledge base — so the equine-specific context stays useful without mixing into every future site.

Discovery before build

Before the first HTML file, we ran a structured client meeting with a discovery agenda: programs, bios, fundraising setup, social channels, waitlist needs, and how the site might eventually go live.

That conversation surfaced real constraints rather than assumptions:

  • Two therapist bios and two horse bios — actual content, not placeholder text
  • Shea Center as the design north star — large hero imagery, with room for video later
  • A domain already registered at GoDaddy (centerxequinetherapy.org), currently showing a “Launching Soon” page
  • PayPal for donations today, with platform options still open
  • Instagram as a priority; YouTube maybe
  • Waitlist tooling still to be decided — Google Sheets, Airtable, or embedded forms

The waitlist piece mattered more than I first expected. Families landing on that page need to understand who the service is for, who they’ll work with, what joining the waitlist means, and when they might hear back. Without that trust content near the form, even a well-designed page doesn’t do its job.

Planning so we wouldn’t overbuild

After the client meeting, I spent a planning day trying to separate concerns that often get tangled together on healthcare-adjacent projects:

Design direction — Shea-inspired polish, with stronger fundraising UX and accessibility built in from the start.

HIPAA boundary — The public website is a marketing and fundraising site. It shouldn’t collect protected health information. The waitlist form is designed as a modular piece that could swap to a HIPAA-capable vendor later without rebuilding the whole site.

CRM readiness — Even before choosing Airtable or Sheets, we structured form categories, source tags, and follow-up statuses so a future integration wouldn’t mean starting over.

Repo ownership — Client code lives under a ProgramEdgeLLC GitHub organization rather than my personal account, which makes handoff cleaner.

The idea that stayed with me: for a small healthcare-adjacent nonprofit, the right starting point is often a strong public marketing site plus a clear handoff to secure intake — not a custom HIPAA-heavy portal on day one.

What we actually shipped

The site itself is static HTML, CSS, and vanilla JavaScript — mobile-first, checked for accessibility, with real client photos in the hero carousel, therapist bios with credential sections styled for easy scanning, and a high-fidelity donation mockup ready for Givebutter once the client’s EIN is confirmed.

We polished iteratively — I reviewed on my iPhone between pushes, and we reworked the mobile menu from a cramped brown dropdown into a full-screen green vignette with backdrop blur. Hero images moved from soft web downloads to sharper client originals: volunteers with the palomino, a toddler in session with a therapist.

The clients loved it. GoDaddy access came through the same week. The site later became the live embedded demo on program-edge.com — client work and studio portfolio supporting each other in a way I hadn’t planned but was happy to see.

What I’d do differently

I’d write the reusable client-site intake checklist earlier. The discovery agenda worked well; having it as a template from the first project would have saved a bit of formatting time.

I’d also talk through the mailto: question before any footer shipped — primary CTAs are more reliable as real URLs, with email as copy-able text and an optional mailto fallback.


Next in this series: the nonprofit full-stack nobody sees — forms, donations, CRM, and the HIPAA line.