Skip to content
How we work

Product team discipline, operator's patience.

A portfolio this size is not the result of moving fast and breaking things. It is the result of building one thing properly and then reusing it, over and over, for industries that had been ignored.

  1. 01

    We go and stand in the workflow

    Before a line of code, we sit at the fee counter, the nurses' station, the weighbridge and the collection round. The software that comes out of that is shaped by the job, not by a feature list.

  2. 02

    We build on what already works

    Tenancy, permissions, statutory tax, mobile sync, audit logging and reporting are solved once and inherited by every product. New products start at the interesting part.

  3. 03

    We go live in days, not quarters

    Bulk imports, guided setup and sensible defaults mean a first payroll run, a first invoice or a first bus route on the same week you sign — not after a six-month rollout.

  4. 04

    We stay after launch

    The team that wrote it runs it: monitoring, releases, support and the next version. Every product in market is still being improved.

What a rollout actually looks like

Most customers are transacting inside two weeks. Nothing here requires a consultant, a change-management programme or a server in your office.

Week 0

Scoping call

Thirty minutes on how you work today — branches, roles, volumes, the reports you actually read and the three things that break every month.

Week 0

Demo on your data

We load a sample of your real masters into a sandbox tenant. You judge the product on your own item codes, not a demo catalogue.

Week 1

Tenant and imports

Your organisation is provisioned, branding applied, and masters bulk-imported — employees, items, students, vehicles, patients, whatever the product runs on.

Week 1–2

First real transaction

A first payroll run, a first GST invoice, a first admission or a first dispatched trip. Live use, not a pilot that runs in parallel forever.

Ongoing

Operate and improve

Monitoring, releases, support and roadmap from the same team. Requests that make the product better for everyone tend to ship fast.

Rules we hold ourselves to

These are the decisions that keep a growing portfolio maintainable by one team.

We say no to forks

Customisation lives in configuration, not a private branch. A customer on a fork stops receiving improvements, and we would rather build the setting properly.

Adoption is the metric

A system nobody at the counter uses is a failed rollout regardless of the feature list. We design for the person with the least patience for new software.

Boring where it counts

Money, tax, stock and attendance get conservative, auditable implementations. We keep the ambition for the parts where being clever actually helps.

One team, end to end

The people who scoped it wrote it, and the people who wrote it answer the support email. Nothing is handed over to someone who wasn't there.

Curious whether this fits how you run? One call usually settles it.

Tell us the process that breaks most often. We'll tell you honestly whether one of our products already covers it.