Navigating Technology Choices: Insights from an Internal Tool Rewrite

In February 2026, a team set out to rebuild their internal tool using React, fully aware that this choice would require more time—approximately twice as long as a simpler implementation in R. However, this decision was about acquiring skills rather than merely launching an application, marking a significant point in the project’s trajectory.

By June, six months into the rework with two key milestones completed, the team faced a decisive moment: they opted to terminate the React initiative and revert back to R. This pivot wasn’t just a spontaneous decision; it stemmed from a critical evaluation of their experience and the unexpected consequences of their choices.

StaffPuzzle, their internal staffing tool, initially functioned as a read-only Shiny application comprised of about 1,200 lines of code. The plan for version 2 included notable enhancements, such as integration with Google Calendar and new features for data analysis. However, after reevaluating their progress, the team realized the supposed learning curve they had anticipated with React was actually absent.

Initial Decision: Why React?

When selecting a technology stack, the team considered three possibilities: an all-JavaScript approach with React, an all-R method involving HTMX, or a hybrid solution. They explicitly laid out criteria to guide their decision-making process. Notably, they anticipated that while React would incur higher costs—requiring approximately 19 to 24 half-days to complete—they considered the investment worthwhile for the team’s future capabilities.

Despite knowing that working in React was a riskier avenue for their seasoned R developers with limited exposure to modern web stacks, they opted for this path in hopes of boosting their skills. The Architecture Decision Record (ADR) at that time documented this choice, marking it as a deliberate investment.

Architecture Decision Record: A critical document that outlines significant software architecture decisions and the reasoning behind them.

Constraints and Options

Interestingly, the team didn’t consider sticking with Shiny as an option. Earlier in the project brief, they had clearly established the need to move away from Shiny, which shaped their options. This choice highlighted a decision made against maintaining their existing tool, focusing instead on a more modern architecture.

A clause under the technical constraints labeled “exit Shiny” was set as a non-negotiable. Since no external pressures dictated this shift, it was a narrative that colored their options. They needed a fresh approach due to a desired upgrade in capabilities that Shiny could still technically provide.

Reevaluation: The Shift Back to R

Fast forward to June, and the evolving situation warranted a reassessment. Though they had set their sights on the React solution, the context had changed. Two new R packages, {htmxr} and {alpiner}, emerged in the interim, providing the necessary tools for a more effective approach than what they had initially considered.

Moreover, their previous assumptions regarding rich interactivity in React proved unfounded upon further analysis. Instead of the anticipated drag-and-drop capabilities, the React implementation didn’t deliver on interactivity as expected. Upon examining the code generated, they realized the offered solution lacked compelling features.

Learning Goals Unmet

By June, it became painfully clear that the fundamental promise of skill development was unmet. The anticipated learning process surrounding React was stifled by the rapid code production facilitated by AI. Developers found themselves racing against the clock and couldn’t fully engage with the language and concepts they had intended to master.

ADR-003, 3 June 2026: Learning React, the central motivation for February’s decision, is not happening in practice: the developer does not have time to read the code generated by the AI.

This realization passed a heavy judgment on the core rationale for their strategic choice in February. The significant expense incurred didn’t translate into the intended educational investment; the project’s progress overshadowed their goal of skill enhancement, leading to a corrective course of action.

Cost of the U-Turn

Shifting strategies in the midst of a project isn’t without consequences. The internal communication required to explain this pivot to stakeholders became an additional concern. Internally, the team reframed how they approached user expectations and worked on stabilizing the new R packages for production readiness.

Despite these drawbacks, the arithmetic appeared more favorable: the time needed to transition everything back to R (six to eight half-days) was less than what it would take to finish the React implementation (eight to ten half-days). The promise of rapid application performance was realized when a proof of concept developed in R demonstrated impressive response times.

Reflecting on the Journey

After a few months of pivoting back to R, the revised application has gone live, successfully integrating calendar functionalities and expanding its historical data capabilities. Not only did they achieve operational objectives, but testing also improved significantly, with the tests-to-code ratio rising from 0.26 to 0.77. This shift meant moving towards a more consistent analysis approach across the project.

Remarkably, they had inadvertently built the first real production case for their internal packages, showcasing their utility beyond a demo setting.

Key Takeaways

One critical lesson emerged from this experience: documenting decisions isn't merely a bureaucratic formality. It allows teams to revisit and reassess the rationale driving their choices without descending into subjective debates. By formally writing down the February ADR, the team could objectively identify which criteria had become outdated during their journey.

It’s essential to distinguish between learning opportunities that failed to materialize and simple errors in judgment. Only one of their three reasons for returning to R was fundamentally flawed, while the others either stemmed from new technological developments or misassumptions about the team’s learning capacity.

A final reflection circles back to the importance of setting verification points for decisions based on non-technical benefits. The project’s focus on learning necessitated specific timelines for checks, a box left unchecked during the initial decision-making process.

Looking ahead: If faced with the same considerations, the team maintains that choosing React would still be preferable in February 2026, suggesting a deeper understanding of decision impacts through proper documentation.