LeadNursingForward

Background

LeadNursingForward is a long-running collaboration led by Salisbury University School of Nursing and the University of Maryland School of Nursing, with development by the Eastern Shore Regional GIS Cooperative (ESRGC). Its goal is to help address Maryland's shortage of nurses and nurse educators by connecting people with career opportunities, organizations, events, and practical information about entering the field.

The project combines an informational website with a career portal. Visitors can explore resources, data visualizations, and interactive tools, while registered users can build profiles, discover jobs and events, and connect with other professionals and organizations. I have served as the project's primary developer, taking it from a small static website to a full-featured platform and guiding its technical direction as its needs have evolved.

How it evolved

When I joined ESRGC, LeadNursingForward was a basic static site with a handful of pages. My first major responsibility was designing and building the initial career portal: authentication, contributor and administrator roles, content creation, and search.

From that foundation, I expanded the portal with individual and organization profiles, on-site messaging and notifications, and a weekly email digest that recommends job postings based on each user's profile. These features turned the site from a collection of resources into a platform where members of Maryland's nursing community could actively find opportunities and connect with one another.

As the portal matured, the partner teams shifted their attention toward expanding the public-facing content. New resources and redesigned pages made the original static publishing workflow increasingly difficult to maintain. I introduced a content management system so the site could continue growing without requiring a developer for routine content changes.

Technical approach

The architecture has changed substantially over the project's eight-plus-year lifespan. The initial version used React, Node.js, Express, Handlebars, and MongoDB—an inherited foundation that allowed me to deliver the first portal while I was early in my career.

As the application became more interactive, I separated the monolith into a GraphQL API and a Create React App front end. That move improved the user experience and supported real-time messaging through GraphQL subscriptions. I later migrated the front end to Next.js, drawing on experience from other projects to improve the development workflow and give the application a stronger long-term foundation.

For content management, I selected PayloadCMS after evaluating it against platforms I had used previously, including Strapi and Hygraph. PayloadCMS offered the balance I needed: enough flexibility to model a growing, content-rich site without making common editorial tasks unnecessarily complex. Its code-first approach also fit naturally into the existing TypeScript ecosystem.

The project's most significant modernization was replacing GraphQL and Apollo, which had grown into a large maintenance burden. A direct rewrite would have been risky and difficult to fit around ongoing feature work, so I planned the migration in stages. I first converted the GraphQL resolvers into parallel REST endpoints, using Codex to accelerate repetitive translation work while I directed the architecture and verified behavior. I then moved the front end to TanStack Query and replaced GraphQL subscriptions with Socket.IO. This created a stable checkpoint where GraphQL could be removed without attempting the entire modernization at once.

With that dependency gone, I consolidated the application logic into the Next.js codebase and translated the REST layer to tRPC. I also introduced Auth.js and reduced the former back-end service to a focused Hono-based WebSocket server. The result is a simpler architecture with end-to-end type safety, fewer boundaries to maintain, and a much faster path from a product requirement to a reliable implementation.

Challenges and lessons

LeadNursingForward was my first professional software project, and its longevity makes it one of the clearest records of my growth as a developer. I built and maintained it as the sole application developer within a team of GIS professionals, without a senior developer providing day-to-day technical direction. That required me to learn quickly, communicate across disciplines, make pragmatic decisions, and take ownership of the platform from architecture through delivery and ongoing support.

It also taught me to distinguish between a technology that can solve a problem and one that fits the shape of the data and the team's long-term needs. MongoDB worked well for flexible CMS content, but the career portal's structured, relational data would have been better served by a relational database. Working within that constraint has made me more deliberate about data modeling, migrations, and the long-term cost of early architectural choices.

Most importantly, I learned how to modernize a production system without treating a rewrite as the only option. By breaking large changes into verifiable stages, preserving working behavior, and using automation where it provided leverage, I was able to reduce technical debt while the platform continued serving its users. LeadNursingForward reflects not just the technologies I have learned, but my ability to own a complex product, adapt it over time, and improve it responsibly.