As VP of Engineering at TrackFive, I’ve spent close to 20 years working in HR-Tech and Staffing, largely at the intersection of product, technology, and engineering. I’ve participated in countless product rebrands, redesigns, re-architectures, and organizational transformations. Normally, those efforts involve one or two significant transformational shifts.
The project we just undertook across the candidate experiences for TravelNurseSource, AlliedTravelCareers, and LocumJobsOnline was different. It involved simultaneous changes across our organization, processes, product design, technology, and engineering practices.
Interestingly, none of these changes were revolutionary. We weren’t introducing a groundbreaking architecture or inventing a new way to build software. We made a large number of deliberate, pragmatic changes. Individually, each was incremental. Together, they fundamentally changed how we build products at TrackFive.
And I couldn’t be more proud of the team. They didn’t simply adapt to the changes—they embraced them, challenged assumptions, and continually pushed for improvement.
The Platform Wasn’t Broken
The existing TrackFive platform was solid. It had evolved over many years and accumulated a tremendous amount of business logic, domain knowledge, and customer-specific functionality. It had also accumulated technical debt.
That’s a familiar problem for any long-running product. The business still needs new features, customers still have requests, and there is rarely enough time to stop and rebuild the foundation.
Our last significant front-end redesign was in 2015. While much of our development effort had focused on backend functionality, the user experience had gradually become dated and increasingly difficult to evolve.
The platform wasn’t broken. But it was becoming increasingly difficult to build the future on top of it.
Creating Space for Transformation
The first and most critical transformation was business alignment.
A project of this scale can’t be something Engineering works on in the margins between feature requests. We needed the business to recognize that investing in the foundation was itself a business priority.
We continued supporting customers, fixing bugs, and delivering important enhancements, but we were given the space to prioritize the new foundation rather than continuously adding to the old one.
That decision was critical. A business willing to temporarily trade some feature velocity for a stronger platform is investing in future velocity.
Changing the Team Before Changing the Technology
We quickly realized that we couldn’t accomplish everything we wanted with our existing team structure.
Historically, we operated as a single team where everyone was essentially a utility player. That flexibility served us well, but it also created knowledge silos and dependencies around our most tenured employees.
Adding more people to the same structure wouldn’t solve that problem. So we reorganized into two teams with clear Product Owner and Tech Lead responsibilities and real ownership over their respective areas.
We expanded the engineering organization by more than four people, added a dedicated designer, and intentionally balanced Engineering and QA within the teams.
We also moved away from strict Scrum toward a Kanban-style flow. With highly interconnected work and a large amount of change happening simultaneously, continuous flow and delivery estimates proved more useful than rigid sprint boundaries.
Changing the team structure before changing the technology turned out to be one of our most important decisions. It gave us the organizational foundation to execute the transformation—and to continue scaling afterward.
Rebuilding How We Build
Modernizing the product without modernizing the development experience would only get us so far.
We invested heavily in infrastructure as code, ephemeral environments, and automated deployments. We moved from EC2 to ECS and created isolated environments for feature branches, making it much easier for Engineering and QA to work independently.
We rebuilt our CI/CD pipelines around GitHub Actions and introduced tooling that improved build speed and reduced infrastructure costs. We established a proper staging environment and introduced Nginx to give us much greater flexibility around routing and production rollouts.
We also adopted a monorepo with Nx, giving us a better foundation for sharing code, components, and services across brands while maintaining clear boundaries.
None of these decisions were particularly exotic. Together, however, they fundamentally changed the developer experience.
That’s important because developer experience isn’t simply a quality-of-life concern. It directly affects how quickly, safely, and confidently an organization can change a system.
Designing a New Experience
The redesign itself went well beyond changing colors and moving buttons.
We developed new visual identities, layouts, and interaction patterns while establishing a reusable design system in Figma. Rather than treating every page as a separate design problem, we created a common language of reusable components that could be shared across the brands while preserving their individual identities.
We also shortened the feedback loop dramatically.
We used lightweight AI-generated prototypes to explore ideas quickly and held multiple design reviews each week with both the team and business stakeholders. Instead of spending months designing in isolation and discovering problems at the end, we continuously reviewed, challenged, and refined the work while changes were still inexpensive.
When development began, we paired the design system with a common UI component library and Storybook. The team worked together to establish the core components—the LEGO blocks we could then use to build the experience.
Beyond making the sites look newer the hope was to establish a foundation for how we design products going forward.
A New Platform, Not Just a New Website
Architecturally, we took the opportunity to rethink how our multi-brand platform should work.
We separated our Healthcare and Trucking applications into clearer boundaries while continuing to share common libraries and platform capabilities where appropriate. On the front end, we rebuilt the platform using React and Next.js.
The goal was to create a shared platform of capabilities that could support multiple products while giving each brand the flexibility to maintain its own identity, experiences, and business needs.
A shared capability should be built once, improved centrally, and benefit multiple brands—while each brand retains the flexibility to evolve independently.
We applied the same philosophy to content. Historically, many content changes required engineering releases. We introduced a dedicated CMS, reusable content components, and a Content API that allows us to control how content is delivered, cached, and optimized.
The result is a much more flexible relationship between Content, Product, and Engineering.
Performance and Quality as Foundations
We treated performance as a requirement from the beginning rather than something to optimize after launch.
The new platform uses multiple caching strategies, Incremental Static Regeneration, and a new OpenSearch-based search architecture. We performed load testing early, using our staging environment to identify bottlenecks before production traffic exposed them.
We also incorporated SEO and accessibility into the architecture rather than treating them as launch checklists. Core Web Vitals, crawlability, accessibility, and emerging AI-driven discovery were all considerations during development.
QA evolved alongside the platform. We expanded our automation significantly, focusing on the repetitive and predictable work so QA could spend more time where human judgment provides the most value.
Good automation doesn’t slow an engineering organization down. It provides the confidence to move faster.
AI Changed How We Build
AI-assisted development was already emerging when we started the project, but its capabilities changed dramatically during the effort.
Initially, engineers experimented with agentic coding in very different ways. We encouraged that experimentation rather than mandating a particular approach.
The results quickly became difficult to ignore. Ideas that might previously have taken days or weeks to explore could become working prototypes overnight.
That changed the conversation from “Can we build this?” to “Should we build this?”
But greenfield prototypes were only the beginning. The harder question was whether agents could safely work within a large production codebase containing years of business logic and institutional knowledge.
Over time, we developed practices to make that possible. We strengthened coding standards and linting, created an AGENTS.md file with repository-specific context and conventions, and began experimenting with agentic code reviews while maintaining human review.
Our philosophy became trust, but verify.
The biggest impact of AI has been changing the economics of engineering work. By making code faster to write and large-scale refactoring more practical, AI has made investments that were once difficult to justify more achievable. This gives engineers more time to focus on architecture, product decisions, problem-solving, and review.
AI is now a core part of our development lifecycle rather than an experiment.
More Than a Launch
It’s tempting to measure a project like this by launch day.
Did the new sites go live? Were there major incidents? Do users like the design? Did the metrics improve?
Those things matter, but they aren’t the entire story.
The bigger win is that we changed the trajectory of the platform.
We went from a collection of aging applications that had accumulated years of successful feature development to a modern platform with shared architecture, design systems, improved infrastructure, automated testing, better observability, stronger search, a more flexible content architecture, and a much stronger foundation for data and business intelligence.
More importantly, we changed how the engineering organization works.
Nothing Revolutionary—and That’s the Point
There is a tendency in technology to focus on novelty: the newest framework, architecture, AI model, or revolutionary way of working.
Very little of what we implemented falls into that category.
The transformation came from combining a lot of good, practical decisions:
- A business willing to invest in the foundation.
- Teams with clear ownership and accountability.
- A modern developer experience.
- A dedicated design function and reusable design system.
- A multi-brand architecture built around shared capabilities.
- Better infrastructure, testing, and observability.
- A stronger approach to content, search, SEO, and data.
- And increasingly, better ways of using AI to amplify the team.
None of those things alone changes an organization.
Together, they can.
What I’d Do Again
If I had to distill the experience down to a few lessons, they would be:
Create business alignment first. A technical plan doesn’t matter if the organization isn’t willing to create the space required to execute it.
Transformation is rarely one big technical decision. It’s usually a series of smaller decisions that reinforce one another.
Change the environment in which people work, not just the code they write. A modern architecture built on a painful development process will eventually become painful again.
Give teams ownership. Clear accountability allows teams to make better decisions and move faster.
Use technology where it creates leverage, not because it’s new. AI has been incredibly useful for us, but only because we incorporated it into a broader engineering system with standards, context, review, testing, and human judgment.
The Next Chapter
The most satisfying part of this effort isn’t the new homepage, logo, or CI/CD pipeline.
It’s that we’ve created a platform and an engineering organization better positioned for whatever comes next.
The old platform was successful because talented people continuously evolved it to meet the needs of the business. We owe that platform a lot.
Now we’ve built a foundation capable of carrying the business forward for the next decade.
We are still early in the rollout, and I fully expect we’ll find things we would do differently. That’s part of iterative software development.
But I’m confident in the foundation we’ve built—and, perhaps more importantly, in the team we’ve built to continue evolving it.
We have transformed ourselves as much as we have transformed the product.
Leave a Reply