DC Modular: From PHP to a Production React Telemetry Interface
Convinced a technical audience to adopt React by building a proof of concept against real PDU telemetry, then delivered the production interface across metro and remote off-grid modular data-centre sites.
V1 (the PDU and device interface) went into production. V2 (the drag-and-drop pod dashboard) was completed and working in the development environment only and was never deployed.
The Resistance
DC Two’s platform ran on PHP. Moving part of the front end to React needed sign-off from both the lead architect and the Managing Director. Their concern was practical: they could not yet see how React would integrate with the existing stack, the device-side telemetry work another developer was writing, or the data centre team’s security and networking setup.
This was not resistance to change for its own sake. It was a production-risk question, and it deserved a working answer.
The Proof
I did the legwork before pushing the idea. I advocated for and built a React proof of concept wired to real telemetry, not a mock-up. The interface gave the technical audience something they could click through and interrogate, showing how the new front end would sit alongside the PHP platform and the hardware telemetry already in play.
For a technical audience, a working system carried more weight than a slide deck. The proof of concept secured approval to build the interface properly.
The Production Interface
The V1 PDU and device interface went into production across both the metro data centre and remote off-grid modular sites. It gave users visibility into power usage and device deployment through the DC Portal, with per-rig telemetry and status surfaced for customers and power draw feeding an automated billing calculation consolidated into a single invoice per customer.
My direct ownership was the React interface, portal-side integration, telemetry readouts and billing calculation. The device-side IoT code was owned by another developer. The production claim is about the integrated customer-facing interface and portal workflow, not sole authorship of the underlying telemetry code.
What Followed
The production V1 interface gave the team confidence that React was the right direction for the platform. I then extended the work into V2: a drag-and-drop interface for the modular data-centre pods, with floor-plan views, responsive widgets and device-status states. V2 was proved with real telemetry in the development environment only and was never deployed.
That distinction matters. V1 was the production PDU and device interface. V2 was the development-only drag-and-drop pod dashboard.
Why This Matters
This was a small-team adoption decision with real operational consequences. I translated between product, architecture, infrastructure and customer needs, reduced uncertainty with a working proof, and carried the chosen direction through to production. It is a concise example of how I persuade technical audiences: understand the resistance, build the evidence, and let the system answer the argument.
Hard Skills
React, PHP, PostgreSQL, IoT telemetry integration, REST API / JSON, CSS, HTML5, Figma, customer portal development, automated billing
Soft Skills
Technical persuasion, proof-of-concept delivery, cross-functional translation, architecture collaboration, production rollout, systems thinking, stakeholder communication
