NORDIQ / developers
Platform overview

The operating system for field-service crews

NORDIQ runs snow removal and landscaping companies end to end, from the forecast to the invoice. Here is how it works, in one page.

258API callables in NAS
8apps on one sign-in
36tenant-scoped repositories
793automated test files

One loop runs the business

Each domain hands work to the next. A snowfall forecast becomes quotes and contracts, then crews, equipment, routes in the field, and finally invoices. Each step is its own app, and they share one data model.

NORDIQ one data model, one sign-in Mission Control Pro watches the whole loop 1 · KLIMAPredicts the next snowfall 2 · VEROCustomers, quotes, contracts 3 · ROSTRCrews and availability 4 · GEARTractors and equipment 5 · SHOVLRuns and jobs in the field 6 · FLOWInvoices and payments
Two more apps sit beside the loop: CLUTCH books subcontractor partners, and START walks a new company through setup.

StormChasr

Storms, schedule, dispatch, routes and teams.

gated on run:read

VERO

Clients, locations, quotes, contracts, tasks.

gated on billing:read

GEAR

Fleet, maintenance and work orders.

gated on equipment:read

FLOW

Invoices, payments, collections.

gated on invoice:read

ROSTR

Workforce and crew availability.

office app

CLUTCH

Partner network, requests, bookings.

gated on partner:read

START

Guided setup for a new company.

gated on config:write

SHOVL

The crew tablet, built for 3 a.m. in a truck cab.

React Native / Expo

Four layers, one direction

Every app talks to one API layer. The API layer is the only code that writes data, and it writes only through the schema layer. Nothing skips a layer.

APPS Mission Control Pro 7 office apps SHOVL tablet NAS · API layer Cloud Functions callables. Each checks a capability and reads the organization from the token. NDS · schema layer, the source of truth Entity types, the schema contract, and repositories that write through a tenant context. Firestore · one isolated data tree per company NUX Design system: tokens, glyphs, components Identity Platform One tenant per company callable + ID token repositories tenant-scoped writes renders verifies reads the schema contract
The design system reads the schema contract directly, so a screen can only show fields that really exist.

What happens when a dispatcher clicks “Dispatch”

Every write follows this path. The browser never decides what is allowed and never writes data itself.

  1. Sign inIdentity Platform signs the user into their company's tenant and issues an ID token. The token says who you are, nothing more.
  2. Load the sessionThe app asks NAS for the session once. Roles and capabilities come back from the server and are cached; a screen without the right capability shows a permission state, never the content.
  3. Show only allowed actionsEach Run comes back with its available transitions, worked out on the server from the company's own workflow. The button exists because the server said so.
  4. Call NASThe click sends a callable request with the token. NAS checks the capability, takes the company from the verified token, and rejects stale writes.
  5. Write through NDSThe NDS repository writes inside that company's data tree. Another company's records are unreachable by construction.
  6. Refresh, don't guessThe app re-reads from the server after every write, success or failure. No optimistic updates, so the screen always shows what is stored.

By the numbers

Counted from the repositories in November 2026. Field operations and the commercial chain carry most of the API.

NAS callables by domain

258 callables in total; domains with fewer than 4 grouped as Other

Automated test files

793 files across the three main repos

The rules that keep it honest

These are enforced in code review and, where possible, by the build itself.

Never invent dataNo field, state or entity that the schema does not define. If a screen needs one, it is raised and decided first.
Tenancy is structuralThe company comes from the verified token, never from the request. Cross-company access is impossible by construction.
Fail closedMissing configuration or a missing permission means “not allowed”, never a default.
Actions come from the serverThe UI shows the transitions the server returns. It never computes them from a status.
Colour never works aloneEvery coloured meaning also has a glyph or a word. Screens must read in greyscale.
Simple firstMake it work, show it, then iterate. Speculative layers get cut.

Done means observed, not just built

Green CI is only the third rung. Work counts as done when someone has watched it behave correctly in the running app, on real data.

Rung 1WrittenCode and tests on a branch
Rung 2ReviewedChecked against the rules above
Rung 3BuiltCI green and deployed
📦 not done yet
Rung 4ObservedSeen working through the app, on live data
✅ done