Norbital

Most companies do not fail at operations because they lack tools. They fail because the system of record for work never kept up with the company that formed around it.

This is our launch note: what Norbital is, where the idea came from, what we are trying to fix, and how that shows up in the companies we spend the most time with.

What Norbital is

Norbital is the platform where operations teams run custom operational apps, governed workflows, automations, and AI agents from one shared workspace.

Two layers matter:

Pod — the workspace itself. Collections, relationships, apps, hooks, automations, remotes, and policies live as filesystem-first TypeScript / Svelte source. The business process is defined in code you can review, test, and version.
Core — the host. Auth, organizations, per-tenant databases, Workspace Studio for branch-based editing, Checkpoints as immutable release builds (preview, then merge to live), and an Agent that acts under the same access policies as the web UI.

The product bet is simple: function-specific software should not require a new vendor, a new database, and a new permission model every time the business invents a workflow. Staff get purpose-built screens. Builders get a real authoring model. Agents get guardrails that are not bolted on after the fact.

We ship starter workspaces — including HR & Payroll and Construction — plus industry patterns you adapt rather than buy as vertical SKUs. Templates are starting points. The platform is the product.

Why we built it

Norbital started in 2024 in Singapore.

Singapore is a dense operating environment: multi-entity employers, construction with heavy compliance, field teams that report over chat, and people/finance ops that must stay statutory-correct across borders. The tools on offer tend to fall into two traps:

Generic SaaS that forces the process into someone else’s objects (“ticket”, “deal”, “project”), then asks you to duct-tape the real workflow on top.
Spreadsheets + chat that absorb every exception until the spreadsheet is the company — and nobody can say what is true without a heroic reconciliation.

We did not want another admin-panel builder. We wanted a place where the domain model is first-class — permits that expire, employment terms that are effective-dated, payment claims with readiness states — and where releasing a change to that model is as serious as releasing product software: sandbox build, preview database, go live, rollback.

The work is still early — pilot and design-partner programs, not a wall of logos. The analysis below is about how these businesses grow, not invented case-study percentages.

What we are trying to solve

When a company grows, four pressures hit internal systems at once. Most stacks only address one of them.

1. The coordination tax

Every new site, entity, or product line multiplies handoffs. If those handoffs live in chat and shared drives, cycle time does not grow linearly — it grows with the number of people who must remember the informal process. Software that only captures “status” without owning the records those statuses refer to makes the tax worse, because people keep parallel truths.

2. Ungoverned mutation

Growth means more people can change money, compliance, or safety-critical facts. Without policies and approval history on the same rows the apps use, audit becomes forensics after the fact. Status columns are not an audit trail. Screenshots of chat are not an audit trail.

3. The second system of record

ERP and accounting systems are often correct for the ledger and wrong for the work. Ops invents a second system — usually Excel — that actually runs the week. Growth then means reconciling two worlds forever. The goal is not to replace the ledger overnight; it is to stop inventing a shadow ops database that nobody intended to maintain.

4. AI without a permission boundary

An assistant that can summarize PDFs but cannot safely update a permit or lock a payroll run is a demo. An assistant that can act without the same access rules as the UI is a liability. We treat agents as another interface onto the same governed workspace — web, WhatsApp, Telegram included — not a bypass.

What teams should measure (directional, not vanity): cycle time on a governed workflow, share of mutations with policy-backed history, days to ship a new ops app, and re-keying of the same facts across tools. If those do not move, the platform is decoration.

How companies actually grow — two close looks

Named logos would be dishonest at this stage. What follows is more useful: archetypes grounded in real operational mechanics. If you run one of these businesses, you should recognize the failure modes. If you do not, you should still learn how growth breaks “good enough” tools.

1. The mid-market construction contractor

How growth looks. Year one: two sites, a trustworthy supervisor, permits in a folder, claims assembled in Excel before month-end. Year three: eight sites, subcontractors rotating weekly, RFIs that never close, defects that reappear at handover, and a commercial team arguing about which progress claim is “real.” Revenue can be up while margin and risk quietly deteriorate — because the company is still coordinating as if it were small.

Where the system usually breaks

Permits to work are treated as documents, not as time-bounded entitlements. A worker is “on site” in a roster but not covered by an active, in-validity permit for the certifications the job requires. Spreadsheets cannot enforce that join; they can only hope someone checks.
Payment claims depend on readiness signals that live in someone’s head. Without a single claim record that knows those dependencies, finance compresses the month into a fire drill.
Cost and baseline data sit in a separate file from jobs and defects. Estimation and site reality diverge until the next commercial dispute.

What helping them grow means. Not “more dashboards.” Making the constraint graph explicit:

Workers, certifications, permits, jobs, and site locations linked so an assignment can be rejected when coverage is incomplete.
Defects, RFIs, and claims as first-class records with states — not rows that lose meaning when copied into email.
One project workspace where site and commercial staff see the same objects, with approvals on the mutations that matter.

That is why our Construction starter models permits, defects, RFIs, payment claims, and a BIM reference matrix together — and why job-assignment hooks care about active permits. The company grows when unsafe or commercially premature work becomes hard to do by accident.

Lesson: if scaling requires hiring “process police,” your software is missing constraints. Encode the constraints; free supervisors to supervise.

2. The multi-entity employer (HR & payroll)

How growth looks. Headcount is not the only axis. Legal entities multiply — Singapore and Malaysia first, then another jurisdiction for a remote team. Each entity brings statutory rules, pay schedules, and overtime logic. The HRIS that worked for one country becomes a museum of exceptions. Payroll consultants become the real product.

Where the system usually breaks

Person, employment, and pay are collapsed into one employee row. The moment someone has two concurrent arrangements, a mid-period transfer, or a loan that outlives a contract, the model lies.
Statutory change is handled by editing cells. There is no immutable “this was the rule that applied on that date,” so corrections become mythology.
Payroll runs are recalculated by overwriting history. You cannot explain a payslip six months later without replaying tribal knowledge.

What helping them grow means. Multi-country growth needs effective-dated facts and immutable outputs:

Identity, employment, terms, and pay profiles as separate concerns.
Statutory profiles with validated snapshots — only approved source rows and valid snapshots participate in a run.
A payroll lifecycle that freezes money (DRAFT → LOCKED → EXPORTED → PAID) and settles reversals as deltas in the next eligible period instead of rewriting the past.
Approvals on source mutations owned by the platform — not a second approval table that drifts from reality.

That is the spine of our HR & Payroll workspace. The insight for readers outside HR: payroll is a time-travel problem. If your system cannot answer “what was true on date D?” it cannot grow past a single jurisdiction without heroic people.

Lesson: when the business crosses a border, status columns fail first. Effective dating and immutability are how you keep paying people correctly while the org chart keeps changing.

The pattern underneath both

Strip the industry labels and you get the same diagram:

Objects with real constraints (permits, statutory snapshots, employment terms) — not free-text status.
Mutations with policy — who can write, who must approve, what history remains.
Interfaces that share those objects — web apps for desks, channels for the field, agents that cannot outrank either.
Releases that respect production — preview the schema and the app before you merge to live.

Generic tools skip step 1 and over-invest in step 3 (another pretty UI on soft data). Custom one-offs nail step 1 once, then freeze, because there is no release model. Norbital keeps all four in one system as the company gets harder to run.

What we are not claiming

We are not claiming we replace your ERP or bank file overnight.
We are not publishing customer logos or “40% faster” claims we cannot show.
Industry guides on our site are patterns you adapt, except where we explicitly ship a workspace template.

If you recognize your company in one of the archetypes above, pick one workflow with clear inputs, handoffs, approvals, and outputs — a permit cycle or a payroll period — and map it onto records and screens. That is how we work with design partners. Talk to us, or start from a template.

The companies that grow cleanly are not the ones with the most software. They are the ones whose system of record for work stayed honest as headcount, sites, and entities multiplied. That is the bar we set for Norbital.