Most enterprise and government teams aren’t short on systems of record. They’re drowning in them. The ERP works. The ITSM tool works. The HR system works. What doesn’t work is the experience stitched across all of them: the manual handoffs, the spreadsheet trackers, the email-chain approvals, and the brittle one-off screens nobody wants to touch. The data lives in solid backends. The pain lives in the front end.
That’s the problem Kinetic was built to solve. Kinetic is an enterprise workflow orchestration platform that acts as a modernization layer — software that sits on top of the systems you already run, orchestrates work across them, and gives users a single, coherent experience without forcing you to rip out and replace the backend. For IT, operations, and digital-transformation leaders, that distinction is the whole point: you get a modern experience and automated cross-system workflows without a multi-year migration project.
To deliver that experience layer, the platform’s user interfaces are built on React. This post explains why we made that choice, and why it still matters for the teams modernizing on Kinetic today.
The status quo we were modernizing away from
For years, the platform rendered its interfaces server-side using JavaServer Pages (JSP). JSP was flexible, but it carried real costs. Changing a screen meant server access. Tailoring a workflow’s UI meant Java development knowledge. The people closest to the business problem — the ones who actually knew what the form should ask and how the process should behave — couldn’t safely touch the thing without a developer and a deployment.
That’s the same trap we see in most organizations we work with today: the experience is locked inside the backend, every change is expensive, and modernization stalls because touching the UI means touching production.
A few years before this shift, we rebuilt the platform to be API-first. Every capability — forms, workflow, data, identity — became an addressable service. That architectural decision is what makes Kinetic a modernization layer rather than another system of record: the engine doesn’t care how the UI is rendered, so the experience can evolve independently of the systems underneath it. But it also raised the obvious next question. If the UI is fully decoupled, what should we build it with?
What we needed from a front-end framework
We weren’t choosing a framework for a single product. We were choosing the foundation for an experience layer that thousands of organizations would extend in ways we couldn’t predict. The requirements reflected that:
- No server access required to change a UI
- Mature tooling with a deep community and abundant documentation
- Local development against real production or test data
- Proven at enterprise scale
- Heavy component reuse across solutions
- Easy reuse of existing libraries
- Testable components
Underneath all of it was one question that still drives the platform: how do we make the last mile of customization safe for the people closest to the work, instead of reserving it for backend specialists?
The short list: Angular vs. React
Two frameworks met the bar: Angular and React. Both were credible. For us, one pulled ahead quickly.
Angular
We had real Angular experience — a couple of apps and admin consoles were built on it. It was capable, but the learning curve was steep, and it asked you to adopt the Angular way wholesale. You don’t introduce Angular gradually; you architect around it. For a platform whose strength is incremental adoption, that was a poor fit.
React
React is a JavaScript library, not an all-or-nothing framework. You can adopt it incrementally, which mirrors how our customers modernize: a screen at a time, not a big-bang rewrite. Getting to a working component took minutes, not weeks. And the componentization we’d been chasing for years in the JSP world — build a widget once, reuse it everywhere — was the thing React was best at.
Why React won
The deciding factor wasn’t novelty. It was the shortest path to value for the people who actually build on Kinetic.
The best technology choice is the one that lets the people closest to the problem solve it themselves.
It’s just JavaScript. React produces UI using a language our customers and partners already know. Adopting it wasn’t learning a new paradigm; it was using familiar skills in a more powerful way. That matters enormously when your goal is to let business and IT teams tailor their own experiences instead of queuing behind a backend developer.
The ecosystem is enormous. A deep library of community components meant we rarely had to reinvent anything, and getting-started material was everywhere. A platform vendor’s job is to give customers a fast on-ramp, and React’s ecosystem made that on-ramp short.
Rendering is fast. Client-side rendering with smart caching and in-memory transitions makes the experience feel like modern software rather than a page-reload-era web app. When you’re the experience layer a user touches every day, speed isn’t a nice-to-have.
It’s flexible without being chaotic. Developers and configurers can run a UI locally against production or test data, set breakpoints, change logic, and experiment — all without affecting anyone else. React’s natural componentization keeps that flexibility from turning into a mess. Reusable components mean every solution shares a familiar composition, so a team can drop into another project and add value quickly.
What changed once we adopted it
Rebuilding our core solutions on React took our own teams a couple of months to internalize, and a bit longer to spread to the consultants who do the last-mile tailoring on customer projects. Once the packaging, naming standards, and build process settled, the shift stuck. Teams now think component-first.
The operational payoff is the part that matters to buyers:
- Safer changes. UI work happens locally, visible only to the person making it, before anything reaches a shared environment. The change cycle for the experience layer got dramatically faster and less risky.
- Reuse instead of rebuild. Because solutions share components, teams move between projects without relearning the structure each time.
- Adoption without disruption. We expected resistance from customers when the front end changed. We got the opposite — the speed, the simpler administration, and the lower risk of UI changes outweighed any reluctance, and many customers had already adopted React themselves.
Where this fits in the bigger picture
React is one deliberate engineering choice inside a larger architecture. The platform stays API-first and deterministic by design: workflows execute the same way every time, with a full audit trail, because the work that orchestration does — provisioning access, routing approvals, updating systems of record — has to be repeatable and governed, especially in the regulated and defense environments Kinetic serves.
That’s also where AI fits, and where it doesn’t. Build with AI. Run with Kinetic. AI accelerates how you design workflows and participates inside them as steps that classify, extract, recommend, and summarize. But AI advises; humans decide; workflows execute. The React experience layer is where people see and act on that work; the deterministic engine is what makes the execution reliable and auditable.
For teams modernizing on top of existing systems, the combination is the value: a fast, familiar, component-based front end on top of an API-first engine, sitting above your systems of record rather than replacing them.
If you’re weighing how to modernize the experience across fragmented tools without a rip-and-replace project, that’s exactly what the Kinetic Platform is built for. See how teams put it to work, or read more about modernizing IT service delivery. The systems you already trust can stay. The experience on top of them doesn’t have to.
Share this article