Menu

Engineering

Anyone can ship. Staying is the harder part.

We build systems we expect to outlive their first release, and we are the people who keep them running.

Capability

What the team builds.

  • Backend & distributed systems
  • Real-time & streaming
  • Infrastructure & edge
  • AI systems & agents
  • Security engineering
  • Mobile & client

Security engineering is one of these, and a historical strength. It is not the category the company sits in.

Practice

How the systems are engineered.

Each of these is a decision taken in a system you can read about, not a principle we admire. Every one names the system it came from.

  1. Failure boundaries before features

    The first architectural question is what is allowed to fail without taking something else with it. In Vestry that produced an isolated protocol layer holding session state alone, so a hostile stateful protocol cannot become a product outage. The boundary is the design, and everything else is arranged around it.

  2. State and events that agree

    A state change written to a database and an event published separately is a system that can tell a story its own data does not support. Lexora commits both in one transaction through an outbox, and publication becomes a retryable step that can fail without producing a lie.

  3. One contract over several implementations

    Four speech decoder architectures behave differently enough that the usual answer is four services. RustSTT is one, because a decoder abstraction holds a single frame shape across all of them. Choosing which model serves a stream stops being an integration concern for anyone downstream.

  4. Keeping the evidence, not just the conclusion

    A finding is a summary of some data, and a summary you cannot open is a claim. Cortex stores every probe exchange by content address and has claims reference the hash, so a wrong answer is diagnosable instead of mysterious. The same instinct governs how we log and how we report.

  5. Running where the network is not

    Sentinel Solar is an always-on backend on a small computer at the installation, talking directly to the inverter and holding telemetry on site. Systems that assume connectivity as a precondition fail in the field. Treating the network as an optional enhancement is a different architecture, not a configuration flag.

  6. Assistants with hard limits

    Every AI layer we ship has an explicit boundary on what it may claim. NutriSense shows resolved numbers before anything is written to a diary. Vestry answers from a group’s own history and cites the message it stood on. An assistant that guesses confidently is worse than one that declines.

The systems these came from

Engagement

How working with us runs.

  1. It starts with the constraint, not the spec

    The first conversation is with an engineer and is about what the system is up against: the load, the protocol, the data that arrives malformed, the thing that already broke once. A specification written before that conversation usually encodes a solution rather than the problem.

  2. Built by the people who scoped it

    There is no handover from a team that sold the work to a team that does it, because there is no team that sells the work. The engineers in the first conversation are the ones writing the code, which is also why the number of concurrent engagements is small.

  3. We are still there after release

    Commissioned systems keep an ongoing support role rather than ending at handover. Production engineering is a mode of work here, not an upsell: the systems in this portfolio that shipped are systems we still operate or still support.

Tell us what you are building