Work

Five products (four you can click through, plus our own agent-driven sprint platform shown in screenshots), three projects from the Project Nexus Code lab, and prior client engagements across healthcare, aviation, and manufacturing. Each piece is framed by what changed for the business, not just what got built.

Live demos

Complete products running on synthetic data; the engineering is real. Four are deployed and open to explore. The first, our own agent platform, runs as a local operator tool and is shown here in screenshots.

• 

  Agile Cards

  Agent orchestration

  The studio's own agent-driven sprint platform, and the workflow it ships client work on. Work is filed as contract cards (a scope, the files a card may touch, its dependencies, and a machine-checked definition of done), and a re-entrant runner claims them, holds each to a per-card token budget, verifies them at two levels, and merges them with a human on the button where the tier calls for one. The runner treats a card store as the source of truth, so a crash reclaims in-flight cards to the backlog instead of losing them. It has shipped its own features through itself.

  Local operator tool, shown in screenshots. No public instance.

  Read the case study
• 

  AxlePoint Industrial

  Industrial Operations

  Asset health and maintenance operations for heavy industry. A 100-asset fleet of engines, generators, compressors, and pumps streams six months of synthetic sensor telemetry into a rolling anomaly detector; every asset carries an explainable 0-100 failure risk score that drafts preventive work orders on demand. Work orders, PM scheduling, parts inventory, and reporting round out the platform.

  View the live demo Read the case study
• 

  Slatewell

  Booking and Scheduling

  Multi-staff scheduling for service businesses. A five-step mobile-first booking wizard sits on top of a pure slot engine that knows about service durations, per-staff buffers, capability matching, and the lunch splits in a working calendar. Bookings re-validate the slot inside a SQLite transaction on insert, so a race to the same minute returns a 409 instead of a double-booking. Admin surfaces (services, staff, availability, customers, communications, reports) round out the platform.

  View the live demo Read the case study
• 

  Lumen Analytics

  B2B SaaS Analytics

  Revenue and behavior analytics for a B2B SaaS, with first-class anomaly detection at the center of the product. A rolling-median STL-style decomposition with MAD sigma scoring flags 27 episodes across 32 metrics, every one with per-slice cause attribution (plan tier, geography, industry) and a triage workflow built on top. Metrics explorer, 500-customer list, d3-sankey acquisition funnel, signup-cohort heatmap, segments, demo auth, and a marketing landing round out the product. Sign in with one click on the landing.

  View the live demo Read the case study
• 

  Harbor Bistro

  Hospitality / Restaurant

  A coastal-American restaurant brand with a full mobile-first menu and ordering surface. Sixty menu items statically generated per slug with per-item customization (radios, checkboxes, upcharges priced live into the unit and total), a sticky filter chip rail tuned for allergy avoidance, and a session-persisted cart that merges identical configurations under a canonical line key. The database is baked into the image at build time behind a db:verify integrity gate that fails the build on bad seed data. Checkout (chunk 3.7) is parked on Stripe test keys.

  View the live demo Read the case study

From the lab

• Project Nexus

  Distributed AI architecture across a mesh of heterogeneous compute.

  The problem

  Modern AI workloads don't fit one machine, and they shouldn't pay for one machine when they don't fit. A research desk, a workstation, and a handful of consumer GPUs are different shapes of compute with different lifetimes, and a serious AI lab has to use all of them.

  What we built

  A distributed runtime that treats heterogeneous nodes (different GPUs, different operating systems, different network reliabilities) as one fabric. Workloads pick the right node by capability, not by hostname. Reliability is in the scheduler, not in a wiki page nobody reads.

  Why it matters

  The lab can run real work without rewriting it every time the hardware shifts. The architecture is the bet that you don't need a hyperscaler to do serious AI engineering, and the bet is paying off.

• Vector

  An edge robotics perception platform.

  The problem

  Robotics perception code is brittle in production and brittle in the loop: it works on the bench, then a new sensor variant or a new operating environment quietly degrades it, and nobody knows until something falls over.

  What we built

  A perception platform aimed at the edge, where you don't get to ship a model the size of a car. Sensor abstraction, model packaging, eval harness on real captured data, and the kind of instrumentation that makes a regression visible the day it happens instead of the quarter it happens.

  Why it matters

  The interesting part of robotics perception isn't getting the model to work once. It's keeping it working as the world it sees changes. Vector is built for the second part.

• Career Ops

  A ToS-safe job-hunt pipeline.

  The problem

  Looking for the right senior ML/AI role is a data problem and a ranking problem before it's a pitch problem. The job boards have different APIs, different terms of service, and different definitions of what a "remote" job actually is.

  What we built

  A pipeline that ingests postings from sources that allow it (with required source attribution), fit-scores them against a profile, tracks applications through their lifecycle, and runs locally on the machine that owns the data. PII never leaves the operator's control.

  Why it matters

  Job-hunt tooling that respects the boards it reads from and the person using it is rarer than it should be. Career Ops is also our own pipeline; we eat the food we cook.

Prior client work

Delivered during prior employment. Named engagements are kept anonymous here; the discipline and the outcomes are not.

• Reporting for a healthcare claims clearinghouse

  Claims and payment reporting on .NET, during prior employment.

  The problem

  An intermediary that sits between insurance carriers and dental plus vision provider networks lives or dies on the credibility of its claims and payment numbers. Adjudication status, EOB generation, statements, payment reconciliation: every one of those steps produces a number someone is going to read and act on, and a number that is slow or unclear is a number that does not get trusted.

  What we built

  Reporting surfaces over the claims and payment pipeline: claims status and adjudication outcomes, payment reconciliation against carrier remits, EOB and statement workflows. Medical coding and billing data, not clinical records. The whole stack inside a HIPAA posture, with the access controls and audit trails that go with it.

  Why it matters

  Claims and billing are where the money meets the spreadsheet. An EOB or a statement is a financial communication a system generates on a payer's behalf, and whoever reads it acts on the number in it, so provenance and freshness have to ride with the number instead of living in a footnote. That is the same burden an agent carries when it drafts or sends a financial message on someone's behalf: the figure it puts in front of a person has to trace back to its source and be known-current before it goes out.

• Decision-support data systems for a manufacturing leader

  Reporting UX on .NET, during prior employment.

  The problem

  Leadership at a Fortune-500 manufacturing company was being held up by reporting interfaces that hadn't been touched in a long time: slow, hard to read, hard to trust. The data was there. The path from data to decision was the slowdown.

  What we built

  Refreshed executive reporting interfaces on .NET. New layouts that matched the questions an executive actually asks. Charts that answered the headline question on first glance, with the supporting numbers one click away. Quiet performance work underneath so reports loaded in time to be useful.

  Why it matters

  The discipline -- get the right number on the screen first, know where it came from, know how stale it is -- carries directly into the AI/ML systems work we do now. Models that decide things deserve the same data hygiene as humans that decide things.

• Applicant tracking system for an aviation operator

  .NET ATS plus microservice integrations, during prior employment.

  The problem

  Hiring teams running real volume need an ATS that does not fight them. Requisitions in flight, candidates moving through pipeline stages, recruiters working three roles at once, interviews to coordinate, offers to track, compliance reporting that has to be defensible. Off-the-shelf options either fit one workflow well or fit no workflow at all.

  What we built

  A from-scratch ATS covering the whole pipeline: candidate sourcing, requisitions and role management, pipeline stages, recruiter workflows, interview scheduling, offer tracking, compliance reporting. On top of that, the integrations a modern ATS is expected to carry (email and SMS notifications, calendar, document and e-sign) wired through a microservices layer using accepted patterns: separation of concerns, idempotent message handling, retry plus dead-letter behavior, schema-versioned events, observability hooks the on-call can actually use.

  Why it matters

  Building ATS-grade integrations is agent-fleet reliability wearing a business-software costume. Idempotent handlers so a retry does not double-fire, dead-letter queues so one poisoned message does not stall the line, schema-versioned events so a producer can change without breaking its consumers: those are not ATS niceties, they are the properties any fleet of independent services needs to stay up in production. We built them there before the AI work made us need them here.

• Aircraft maintenance management for an aviation operator

  Maintenance, parts, and compliance tracking, during prior employment.

  The problem

  An aircraft is a moving compliance posture. Scheduled and unscheduled maintenance, flight hours, cycles, parts with lead times and airworthiness rules, work orders that have to land on the right technician with the right paperwork, and an audit trail an inspector can follow on a bad day. Keep one of those columns out of sync and the airplane does not fly.

  What we built

  A maintenance management system covering scheduled and unscheduled work, flight hour and cycle tracking, parts inventory with lead times and airworthiness compliance, technician work order workflow, and audit trails sized for regulatory inspection. Pre-AI engagement: rigorous data discipline first, then the workflow on top of it.

  Why it matters

  The engagement pre-dated practical AI deployment, but the opportunities were obvious from inside the domain: predictive failure modeling against hour-and-cycle data, parts demand forecasting against the lead-time graph, technician routing against the work-order queue. That kind of domain insight, captured before the tooling caught up, is exactly what the AI/ML positioning the studio runs now is built to deliver against.

Want one of these tailored to your environment? The lab work and the client work share a method; what changes is the data and the constraints. Tell us what you're trying to do.