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.
Different problems want different shapes. These are the four we keep returning to — and we will say plainly which one your problem actually needs.
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.
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.
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.
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.
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.
Systems where a rounding error is an incident and an audit trail is not optional.
Large-scale data and computation, where the pipeline is the product and reproducibility is the whole point.
Long procurement, longer lifespans, and software that has to be maintainable by whoever comes next.
Privacy boundaries, interoperability, and the discipline that handling real patient data demands.
Rules engines, actuarial data, and legacy systems that cannot simply be switched off.
Real-time constraints and embedded targets, where the software meets physics and physics wins.
The interesting conversations start with the piece nobody on the team wants to own.