Legacy Code to React: A Feature-Led Approach
How we introduced React into a legacy PHP/JS stack by delivering a fully integrated, high-engagement social feature, laying the groundwork for future modernization without disrupting the existing platform.
A live product built around Blade, PHP, and existing JavaScript.
Curawork was already a live product. The app served active users in healthcare across web and mobile, with the day-to-day frontend built around Blade templates, PHP, and existing JavaScript.
The next phase needed something the existing layer was not the best fit for: a community feature with rich, real-time behavior, with a roadmap of richer content surfaces behind it. A full rewrite would have meant pausing delivery on a live product. Stretching the existing frontend further would slow every future feature. The real choice was where to introduce a different approach without breaking what was already running.
- 01Live users on web and mobile, no maintenance window
- 02Blade templates render the page shell
- 03PHP serves requests and renders Blade
- 04JavaScript adds interactivity per page
The first step was a real community feature.
Moments was a meaningful community feature for caregivers, not a technical sandbox. It carried real product value the moment it shipped: posting, a live feed, likes and voting, comments, reporting, and notifications.
Danubio introduced React here because this surface needed richer interaction than the existing Blade and JavaScript stack was a good fit for, without justifying a full rewrite of the app. Because Moments lived inside the running product, the new React surface had to integrate with the Blade and PHP environment around it, not replace it.
Shipping Moments meant solving the integration problem and the product problem at the same time.
Auth and session
The new surface had to share the same session and identity model as the existing app, not run as a separate product.
Server-rendered shell
Pages still went through the existing Blade and PHP layer. The modern frontend had to mount cleanly inside that shell.
Navigation continuity
Users moved between modernized and existing surfaces inside one product. Navigation had to feel like one app, not two.
Operational boundaries
Deploy, error reporting, and observability had to fit the existing infrastructure, not require a parallel pipeline.
Curawork could keep evolving the product without a rewrite.
Moments shipped as a complete community feature for caregivers. It gave Curawork a path to keep adding richer, more interactive surfaces on the same auth and navigation as the rest of the app, without pausing delivery or running a parallel release pipeline.
The modernization moved into knowledge and community surfaces.
After Moments, the same approach carried the next surfaces of the product: a knowledge area for documents, videos, and podcasts, and the broader Groups community experience. Each one mounted on the same auth, the same navigation, and the same release pipeline as Moments.
Documents, videos, and podcasts.
Internal knowledge with admin tooling for folders, files, and roll-out.
The community surface around Moments.
Group profiles, members, and discussion feeds.
Strong user engagement on the new feature after launch, reported by Curawork’s CTO.
Danubio was highly professional and responsive. The code quality was excellent. The new feature not only met our expectations visually, but also delivered strong user engagement. Their work laid the foundation for future improvements, and we are excited to continue working with them.
Frequently asked questions
How do you introduce React into a legacy PHP stack?
You introduce React into a legacy PHP stack feature by feature, inside the running product, rather than starting a parallel application. At Curawork, a healthcare platform, Danubio brought React in through Moments, a community feature, mounting the new React surface inside the existing Blade and PHP shell so it shared the same authentication, navigation, and release pipeline as everything else. That approach means the new and old code coexist in one product: a user moving between a legacy PHP page and a new React feature experiences one continuous app, and the team keeps shipping from a single pipeline. It avoids the trap of a long-running rewrite branch that drifts away from the live product. Each new React surface is added where it delivers real value, and the modern stack grows from there.
Why start with a single feature instead of a full rewrite?
Starting with a single feature avoids pausing delivery on a live product, which a full rewrite would have forced on Curawork, a healthcare platform that had to keep running for its users. Rewriting everything before shipping anything means months with no new value delivered and a large, risky cutover at the end. Instead, Danubio shipped one real, high-engagement feature, Moments, on React inside the existing PHP product. That proved the approach worked in production, gave users something valuable immediately, and laid the groundwork for further modernization, all without disrupting what was already live. The feature-led path turns a modernization from a single high-stakes bet into a series of small, validated steps, each of which ships and earns its place before the next one begins.
What did the approach lead to?
After Moments proved the feature-led approach at Curawork, the same method carried further modernization: the knowledge area, covering documents, videos, and podcasts, and then the broader Groups community surface, each built in React and mounted on the same auth, navigation, and release pipeline as the existing product. So a path that began with one community feature became the way successive parts of the product were modernized, without a disruptive rewrite at any point. Curawork reported strong user engagement on the new feature, which is the validation that matters: the modernization delivered real product value alongside a cleaner codebase. Each new surface added more of the product to the modern React stack while the live healthcare platform kept serving its users throughout.
Evolving a live product without a full rewrite?
If your product still runs on an older stack but the roadmap keeps demanding richer surfaces, the useful conversation is about where to start. Bring what is on the roadmap, what is hardest to ship on the current stack, and where a rewrite is genuinely off the table. We will be honest about what fits.
A different shape of modernization: a full rebuild migrated tenant by tenant under the running product.
What ongoing partnership looks like years in, with the same engineering team carrying the product.