Enterprise document automation

Conexiom

Conexiom helps manufacturers and distributors turn the business documents they receive into validated, ERP-ready data. Customers who want their documents processed use its partner portal to bring them in, check what was extracted, and review anything that needs attention.

My work

I worked on the frontend of the partner portal, where several teams' micro-frontends come together. I built micro-frontends for it with React and Module Federation, made its Material UI modules compatible with a shared shadcn/ui library, designed and carried out the move from Azure DevOps to GitHub, and wrote the shared packages that connect the React modules to the C# backend.

How the product works

Conexiom's portal showing an orders list with documents under review
Business documentsReceived by customers
Partner portalIntake · Validation · Review
ERP-ready dataValidated output

Technology stack

Pick a technology to see what I used it for.

What I worked on

Most of my work was on the frontend platform: how micro-frontends come together in the portal, how they look, and where the code lives. The shared packages connected that work to the backend.

Micro-frontends in the partner portal

The partner portal brings micro-frontends from different teams into one shared place, using Module Federation. Our team owned the identity-provider workflows. I built them as React and Vite micro-frontends that render inside the host app and get their data from it.

They run inside the existing portal without clashing with its Material UI styles.

How I kept them isolated

The portal shell uses Material UI, and global styles can leak between the shell and a new module. I rendered the micro-frontends inside Shadow DOM, so each side keeps its own styles.

Module Federation let each module ship on its own release path while customers still see one portal.

Moving from Material UI to shadcn/ui

The portal's React modules were built with Material UI, and the platform was moving to a shared UI library based on shadcn/ui. I created the abstraction that converts those modules to the new library.

Modules could adopt the shared library and stay compatible with the existing portal.

What I had to keep working

The parent portal kept using Material UI during the change. I extended the micro-frontend model to support the shared library, so converted modules still fit inside it.

Moving delivery from Azure DevOps to GitHub

The platform's repositories and delivery workflows lived in Azure DevOps. I designed the migration to GitHub on my own and carried it out, keeping the existing micro-frontend model.

Existing users kept working without noticing the change, on a more stable platform.

What I documented along the way

I set up a repository with the project rules, business rules and guidance for moving the platform between environments. People and AI-assisted tools could work from the same written rules.

Connecting the modules to the backend

The React micro-frontends depended on backend services written in C#. I wrote reusable npm and NuGet packages for API fetching and shared platform behavior.

Where C# comes in

The npm packages gave the React modules a stable way to fetch from the API. The NuGet packages kept the matching contracts aligned on the C# side.

My main work was on the frontend; the NuGet side kept the C# services in step with it.