CASE STUDY · ENTERPRISE SOFTWARE · OPERATIONS PORTAL

Business operations portal case study: the Lotus Unified Portal

A national services operation runs on the answer to one question: what is happening with every job, right now? This is the portal I engineered at the core of business operations for Lotus Commercial (Australia's leading commercial-kitchen services company) to make that answer one screen instead of many.

The operational problem

Lotus Commercial runs on the order of 80,000 service jobs a year for thousands of clients, with a roughly 70-person national operation behind them. At that volume, the software problem is the shape of the whole picture rather than any single job. Jobs arrive from more than one place: some originate in internal systems, others come in through external sources. Each source has its own data model, its own lifecycle, its own idea of what "done" means.

When every source has its own screen, the operational picture is fragmented by construction. Answering a routine question (where does this job stand, what's queued for this week, what's been completed and what still needs invoicing) means stitching systems together in someone's head, tens of thousands of times a year. That's not a training problem or a process problem. It's an architecture problem: the systems were never given a single surface to converge on.

So I've built, at the core of business operations for Lotus Commercial, exactly that surface: the Lotus Unified Portal (portal.lotuscommercial.com.au), the same class of enterprise software I build as Exybit, a custom software solutions practice in Cebu, Philippines.

The answer: a single pane of glass

The portal's founding decision is that job management is unified across internal and external job sources. It doesn't matter where a job originated. Once it exists, it appears in one operational view, alongside every other job in the business, under one set of workflows. One pane of glass instead of a bookmarks folder of systems.

"Unified" is a stronger claim than "aggregated." An aggregator shows you a read-only digest and sends you back to the source system to act. The portal is where the operation actually works: the job list people plan from, the record they update, the view that invoicing and reporting hang off. Unification only pays for itself when the unified view is the primary one. Otherwise you've just added an (n+1)th screen to the fragmentation you set out to fix.

Integration architecture: many systems, one truth

Under the unified view sits the hard part: the portal houses integrations to multiple internal and external systems, with realtime processing. Each integration is a boundary with a system Exybit doesn't control: different schemas, different vocabularies for status and identity, different notions of when a job changes state.

The engineering discipline is normalization: every source's representation of a job is translated into the portal's own model at the boundary, so that everything inside the portal (lists, filters, invoicing, dashboards) operates on one consistent shape. The integrations absorb the mess so the operational view doesn't have to.

Realtime processing is what makes the single pane of glass trustworthy. A unified view that lags its sources is worse than no unified view, because people quietly stop believing it and drift back to checking the source systems directly, which resurrects the exact fragmentation the portal exists to kill. Changes flow through as they happen, so the portal's picture is the current one, and the habit of "let me double-check in the other system" has nothing to feed on.

Invoicing and dashboards in the same surface

Because every job, whatever its source, lives in one model, the money and the management can share it. Invoicing lives in the same portal: the path from completed work to issued invoice runs over the unified job data rather than being reconstructed from per-source exports. At tens of thousands of jobs a year, keeping billing attached to the operational record instead of downstream of it is the difference between invoicing being a workflow and invoicing being an investigation.

Operational dashboards live there too, built on the same realtime, normalized data. That's the quiet payoff of unification: reporting isn't a separate project with its own pipeline and its own version of the truth. The dashboards are simply another projection of the model the whole operation already works in. They're the view for running today and the view for seeing the whole, on one surface.

Frontend engineering for a dense operational UI

The portal's front end is React with TypeScript, built on Vite, styled with Tailwind CSS, with Radix UI primitives underneath the interactive components. Each choice is about the specific problem of dense operational software:

• TypeScript end to end in the UI. A portal that unifies multiple systems is, above all, a lot of data shapes. Strict typing turns "which fields does a job from this source actually have" from a runtime surprise into a compile-time answer, which matters most exactly where integrations meet the interface.
• Component architecture over page architecture. An operations portal is the same vocabulary repeated everywhere: job rows, status indicators, filters, tables, detail panels. Building that vocabulary once as a component system means the job view, the invoicing view, and the dashboards stay visually and behaviorally consistent instead of drifting into three apps that happen to share a login.
• Radix UI for the unglamorous correctness. Dialogs, menus, popovers, and selects that get focus management, keyboard behavior, and accessibility right. They're headless, so they take the portal's design rather than imposing a library's. Software people use all day, every day, earns or loses trust on exactly these details.
• Tailwind for a constrained visual system, where utility classes keep a large, dense UI on one spacing and color vocabulary, and Vite for the build and iteration speed a long-lived, heavily-worked-on frontend needs.

None of this is exotic, deliberately. An operations portal needs a UI that renders a lot of data clearly, behaves predictably under daily-driver use, and can keep absorbing new views as the business adds them. Clever gets in the way of all three.

What this proves

The Lotus Unified Portal is Exybit's core competency in one artifact: taking a real operation (national scale, tens of thousands of jobs, thousands of clients, multiple systems that were never designed to agree) and engineering the software that makes it legible. There's no greenfield freedom here. It's integration-heavy enterprise software at the core of how a business actually runs: unify the sources, process changes in realtime, put the work and the money on the same surface, and build a frontend disciplined enough to carry all of it.

That's the pattern behind most businesses' hardest software problem. The systems exist; the single picture doesn't. Building that picture, and making it the place where the operation genuinely works, is what this portal does for Lotus Commercial every day.