Updating a Full-Stack PHP Application to ReactJS

Engagement Details
  • 2 Months
  • 2 Developers

About Set and Service Resources

Set and Service Resources (SASR), founded in 2003, is a staffing company that provides temporary associates for their clients—mainly large retail stores—to work on projects across the US. Associates are able to apply to jobs and work a schedule that fits their needs, whether it's a part-time flex job or a team lead position traveling the country.

SASR was looking to update a 15-year-old full-stack PHP associate portal for a more modern end-user experience and technology stack. They already had a new mobile-first design in hand and they needed it implemented. They also wanted a partner who could understand and choose the right technology for their business as they scaled for the future.

What We Did

SASR had backend engineers on staff who were managing a 15-year-old legacy application that had recently been migrated to Laravel PHP. Like many small companies, they were having a difficult time hiring PHP engineers to expand their team to keep up with business innovation demand. Furthermore, with the new design, they wanted a polished app-like experience that reflected the mobility of the users they were assisting. Based on these factors and with the idea of looking to scale their operations going forward, we recommended creating an API from the existing PHP application and building the frontend in React as a separate application. We have extensive experience in API design and development and would be able to assist them with this piece as well. We were ready to get started.

Open and Applied Jobs

The first step in the process was designing and documenting the API. It would be critical to have a single source of truth for the API going forward, as this was the link between backend and frontend development. We suggested using a tool like Swaggerhub or Apiary for this. Not only do these tools provide cloud-based documentation for API’s, but they can also serve as an API server that we could develop against. Therefore we would not have to wait on specific features to be developed in the backend before testing API calls in the frontend.

Communication is always an essential piece of a successful project and this was no exception. In addition to the backend / frontend split, as mentioned above, we were working with a 15 year-old application that had lots of legacy features and code. We needed to understand the existing features in the context of SASR’s business in order to make suggestions on aspects of the API design and frontend implementation. To address this, our team worked on-site with the SASR team several times a week throughout the project. This was critical in getting the project done right and on time.

Rather than do a hard cutover to the new app, we decided to release it to a select group of SASR associates first in order to get even more feedback and work out any kinks. Based on ongoing acceptance in our staging environment, we were confident in the state and performance of the new app. However, there is no substitute for getting data from actual users in a production environment. We therefore decided to release the new app to a select group of SASR associates for a few weeks before launching officially.

Open and Applied Jobs


The response was overwhelmingly positive. Not only was there great qualitative feedback about the new design and ease of use, but important metrics like the percentage of jobs filled had improved. Furthermore, because of the success of this platform and our good working relationship with the SASR team, we went on to many additional projects—including improving the onboarding experience and working to create an entire ecosystem of applications for different roles instead of a single monolith app.