What Norbital is and why we built it

Norbital is a platform for building and running custom operational software. A workspace can contain data models, web apps, approvals, automations, integrations, and agents. They use the same records and access policies.

We started Norbital in Singapore in 2024 because many operations teams face the same choice: force a workflow into generic software, or run it through spreadsheets, chat, and manual reports. Both options create repeated data entry and unclear ownership.

The product

Norbital has two parts.

1. Pod defines the workspace. Builders author collections, relationships, apps, hooks, automations, remote functions, and policies in TypeScript and Svelte.
2. Core runs the workspace. It provides authentication, organizations, per-tenant databases, Workspace Studio, versioned Checkpoints, and Agent.

Pod source is reviewable and testable. Core builds that source in a sandbox, applies database changes to preview, and promotes a successful checkpoint to production.

The problem we are solving

Operational software usually fails in four specific ways.

Data is copied between tools

A form writes to one system, a team tracks status in another, and a manager rebuilds the result in a spreadsheet. Each copy can become stale. Norbital keeps the record, workflow, and report in one workspace.

The software cannot represent the real rule

Generic tools can store a status, but they often cannot enforce the rule behind it. A construction assignment may require an active permit and current certifications. A payroll run may require approved, effective-dated source records. Norbital lets builders model those conditions directly.

Permissions differ by interface

Adding a portal, automation, or assistant should not create a new permission model. Norbital evaluates workspace policies when users, apps, and agents access records.

Changes reach production without a release process

Schema and workflow changes can affect live operations. Workspace Studio creates an immutable checkpoint for each successful build. Teams can test it in preview before promoting it to production.

Two concrete examples

The Construction template connects projects, workers, permits, jobs, defects, RFIs, and payment claims. A job assignment can check the worker and permit records before it is accepted. Field evidence stays linked to the project and location used by the commercial team.

The HR and Payroll template separates a person from employment, employment terms, pay profiles, statutory snapshots, and payroll runs. Approved source records feed a payroll run. Locked and paid outputs are not silently overwritten.

These templates are starting points. They demonstrate how the workspace model handles real records, rules, and releases. They are not claims that every company should use the same process.

How we work with a client

We start with one operational workflow. The client shows us its inputs, records, handoffs, approvals, and outputs. We then define:

• the collections and relationships;
• the forms, queues, dashboards, and portals;
• the policies and approval rules;
• the automations and external integrations;
• the agent actions, if an agent is useful;
• the preview, release, and rollout plan.

We measure whether the implementation reduces operating cost, supports revenue growth, strengthens compliance, or improves decisions. If it does not move a client outcome, it is not useful work.

Talk to us about a workflow or review the available templates.