Services

Engineering you can hand a problem to.

Start with what we have already delivered for clients, then the services behind it — building software, keeping it running, and advising the teams who own it.

Built for clients

Platforms we have delivered.

Software we designed, built and run for the companies that own it. These are compliance platforms: the figures they produce are filed with a tax authority, so being nearly correct is the same as being wrong.

Line Platform Status
01
EasyFile720 — Excise tax filing platform
Federal tax

Guides the filer through the return, computes the tax from the rates in force for the period being filed, and submits it. In service today.

Live
02
EasyFile2290 — Heavy vehicle use tax filing platform
Federal tax

The same approach applied to the highway use tax owed on heavy vehicles, built for operators filing across a fleet rather than one vehicle at a time. In service today.

Live

We do not name clients or show their data. What we can describe is the shape of the work and the standard it was held to.

What we offer

Engineering, end to end.

Each engagement is one of three things: we build it, we run it, or we advise the team who does. The label on the left of each service says which.

Build

Software designed and built from the ground up — data model, backend, interface, deployment pipeline. We take responsibility for the whole thing, including the decisions that are usually left to someone else: what happens on a bad input, what the audit trail records, what the system does at ten times the volume.

You own the source. Nothing we build depends on us staying.

Build

Language models put to work inside real products, not demonstrations. Reading documents and pulling structured data out of them, guiding a user through a form they do not understand, drafting a reply for a support agent to approve, checking a submission for the mistakes people actually make.

We are explicit about the boundary. Where an answer must be defensible, the model assists the person and the system computes the figure.

Build

The discipline that decides whether an AI feature is dependable or merely impressive. We write the instructions, build the evaluation set of real cases, measure changes against it, and version prompts the way we version code.

Typical engagement: an existing feature that works in the demo and fails on the long tail. We find where it fails, harden it, and leave you the test set that proves it.

Build & Run

Hosting, databases and object storage sized to what the workload actually does. Encrypted backups kept with a different provider and in a different region from the live system, restored on a schedule so we know the restore works.

For regulated data we set retention to the period the law requires and keep records in the form they were submitted.

Build

Connecting your system to the ones it depends on: government electronic-filing channels, payment processors, accounting platforms, telematics and carrier feeds. We handle schema validation, retries, and reconciliation, so the two sides agree on what was sent.

Run

Keeping software alive after launch: releases, monitoring, patching, incident response and the support queue. We plan capacity around your busiest day — a filing deadline, a quarter end, a peak season — not the monthly average.

This covers systems we built and systems we inherit from someone else.

Advise

Short, scoped engagements for teams facing a decision they will live with for years.

  • Architecture and code review before a rebuild is committed to
  • Mapping a regulation onto a system that has to implement it
  • Where AI belongs in your product, and where it does not
  • Cloud cost and data retention strategy

You get a written recommendation with the reasoning attached, not a deck.

How an engagement starts

A conversation, then something written down.

We begin with the problem, not a proposal. One call to understand what is breaking and what it costs you. Then a short written scope: what we would do, in what order, what it takes, and what we would need from your side.

If the answer is that you do not need us, we will say that too. It is a cheaper outcome for both of us than the alternative.

Good first questions

  • What is the deadline this has to survive?
  • What happens today when the data is wrong?
  • Who has to be able to explain the output, and to whom?
  • What would you stop doing if this worked?

Start with the problem.

Describe what is not working. We will tell you whether it is a build, a run, or an advise — and be honest if it is none of them.