Nexora

Business context

A company with four branches was running each one on different tools: staff on spreadsheets, stock in a separate app, expenses in a third, and nothing joined up. Management could not answer which branch was most profitable this month without someone spending a day collecting numbers by hand.

The problem

The real cost was not the missing report. It was that every branch could tell a different version of the same month, and nobody could prove which was right. Decisions were being made on whichever spreadsheet arrived first.

The challenge

A system like this fails in two ways. It either buries people in modules nobody opens, or it lets one action update part of the business and quietly skip the rest — a purchase received in the warehouse that never reaches the books. The second failure is worse, because it looks like it is working.

The solution

Every state change goes through a single operations layer instead of the screens. Approving a purchase request as finance closes the request, issues the purchase order, and records who decided it — one operation, so it cannot be done halfway. Receiving that order then moves stock, logs a movement per line, books the expense, notifies finance, and writes the audit entry together.

Design approach

This is a tool people sit in all day, so it is built for scanning rather than for impression: one 5px corner radius everywhere, a mono face for codes and rupiah columns so figures line up vertically, and colour reserved for status. The chrome is a narrow icon rail plus a section panel, which keeps seven modules reachable without a menu that grows.

Technical approach

Next.js and TypeScript, with the business rules isolated in one module so they can move to a server unchanged. The demo stores its data in the browser: it opens instantly, needs no keys, and cannot rot — but every screen says so, and the audit page is explicit that a real build writes its log to append-only storage that an administrator cannot edit.

Key features

• Five roles that each see a different product, generated from a permission matrix rather than hard-coded per screen
• Two separate checks on every action: may this person do it, and may they do it in this branch
• Multi-tenant, with a second company in the data specifically so the isolation can be tested rather than claimed
• Two-stage approval flow — branch manager, then finance — that issues a purchase order on final approval
• Automatic low-stock alerts that fire the moment a sale drops a product below its minimum
• Audit log that cannot have gaps, because nothing can be written without it
• Dashboard and financial reports recomputed from the underlying rows, never stored as summaries