ESRGC Website

Background

By 2018, the Eastern Shore Regional GIS Cooperative (ESRGC) needed a new website that better represented the organization and made its work easier to discover. The existing site was dated and no longer provided a strong foundation for communicating who we were, what we offered, or the range of projects and data we produced.

The replacement serves several roles: it is ESRGC's primary marketing site, project portfolio, event calendar, data library, and blog. Visitors can learn about our services and staff, explore project partnerships and outcomes, find maps and datasets created by the organization, and see where our team will be presenting or participating in regional events.

How it evolved

A student intern began the first version from an approved design. I guided her technical decisions and implementation, then took ownership of the codebase and completed the production site. That initial release included organizational and service information, staff biographies, outreach content, an event calendar, and a portfolio describing each project's partners, solutions, and final product. It also made ESRGC-created resources—such as sea-level-change, flooding, legislative-district, and broadband maps—available through a central site. Our blog remained on Wix at the time, so I integrated its posts through an RSS feed.

The first version was entirely hard-coded. That worked for launching the site, but it made routine updates dependent on me. Colleagues had to request even small content changes, interrupting other project work and slowing down publication. When our schedule allowed, I introduced Strapi so staff throughout ESRGC could maintain the site's content themselves.

Strapi improved the editorial workflow, but its rigid content structures still required developer involvement whenever the team needed a new optional field or a different page arrangement. After gaining experience with PayloadCMS, I migrated the site again and redesigned its content model around reusable, site-builder-style components. I also moved the Wix blog into Payload, bringing the website and publishing workflow under one system. Colleagues have found this version substantially easier to use than its predecessors.

Technical approach

Every version of the site has used Next.js, beginning around version 9. The original interface combined Bootstrap and Semantic UI, reflecting the tools ESRGC was using at the time. Because most of the site was static, its only meaningful server-side feature was a form for joining the mailing lists of regional GIS committees facilitated by ESRGC. I implemented that workflow with a Next.js API route that emails the organization so the request can be added to our internal list.

When I introduced Strapi, I also replaced the mixed styling approach with Tailwind CSS, giving the site a more consistent system that was easier to maintain. The later move to PayloadCMS addressed the larger architectural issue: the editorial model needed to support changing page layouts without requiring a new hard-coded field or developer intervention for every variation.

I modeled the current site as flexible content blocks that editors can arrange into pages while preserving intentional design constraints. Payload provides the code-first control I need as a developer and a clearer editing experience for my colleagues. I selected MongoDB because its document model fits the variable, nested structure of page-builder content, while media assets are stored separately in DigitalOcean Spaces. I also incorporated shadcn/ui components and subtle Motion animations to improve consistency and polish without overwhelming the site's content.

A practical constraint shaped each phase: client and partner work takes priority over ESRGC's own website. Rather than attempting a disruptive rebuild, I modernized the site in stages whenever capacity became available. That approach allowed the public site to remain useful while its publishing workflow, design system, and architecture steadily improved.

Challenges and lessons

This project is a useful record of how my approach to application development has matured. Early in my career, I followed the static-site patterns established by my predecessor and did not initially consider a CMS necessary. Maintaining the site showed me that architecture affects more than code: when only one developer can update content, an otherwise straightforward website creates an organizational bottleneck.

The two CMS migrations helped me learn how to evaluate a tool against the actual editorial workflow rather than only its feature list. Strapi solved the immediate access problem, but Payload better matched the flexibility the organization needed. Instead of discarding the project and starting over, I carried out focused refactors that preserved working functionality while improving the content model and maintainability.

The initial build also gave me an early opportunity to mentor another developer. Guiding a student intern through stack choices and implementation reinforced skills I had begun developing as a Supplemental Instructor at Salisbury University. I enjoy helping developers grow, and explaining decisions to someone else consistently sharpens my own thinking. Together, the technical evolution and mentorship involved in this project reflect an important part of my work at ESRGC: improving both the software we maintain and the way people contribute to it.