Work

The studio practice, how we engage, and the industries we know.
Our own work

The Studio

We run a game studio inside a software company, on purpose.

Games are where engineering gets audited by reality. A frame budget does not negotiate. A save file written wrong today is a support burden for years. A simulation that drifts by one floating-point operation is a bug report you cannot reproduce. There is nowhere to hide, and the habits that come out of it — deterministic simulation, golden-file testing, tooling built for the people who use it daily, data models designed before the features pile on — are exactly the habits that make client work go well.

So the studio is not a side project we tolerate. It is the practice that keeps the shop sharp, and everything we learn there goes back into the work we do for other people.

Our title in development is Farholm — a space-mercenary roguelite about a small crew you come to love, and the risk of losing them.

How we engage

Four ways to start.

Different problems want different shapes. These are the four we keep returning to — and we will say plainly which one your problem actually needs.

Discovery sprint

A short, fixed-scope engagement that turns a vague ambition into a scoped plan: architecture, risks, effort, and the parts that are harder than they look. You own the output whether or not we build it.

Build partnership

We take a defined product or module from design to shipped, working in short cycles with running software at the end of each one. Best when you know what you want and need it built well.

Embedded team

We work inside your process, your repository, and your standups as part of your team. Best for sustained capacity on a roadmap you already own.

Advisory retainer

Ongoing access for architecture review, second opinions, and the expensive-to-reverse decisions. Best for teams who have the hands but want another pair of eyes.

Where we have worked

Domains that do not forgive.

Regulated, measured, and unforgiving of hand-waving. These are the sectors our people have delivered in — where correctness is not a preference and "it works on my machine" ends a conversation early.

Finance

Systems where a rounding error is an incident and an audit trail is not optional.

Genomics

Large-scale data and computation, where the pipeline is the product and reproducibility is the whole point.

Government

Long procurement, longer lifespans, and software that has to be maintainable by whoever comes next.

Healthcare

Privacy boundaries, interoperability, and the discipline that handling real patient data demands.

Insurance

Rules engines, actuarial data, and legacy systems that cannot simply be switched off.

Robotics

Real-time constraints and embedded targets, where the software meets physics and physics wins.

Bring us the part that worries you.

The interesting conversations start with the piece nobody on the team wants to own.