How we work
Senior engineers, embedded in your delivery.
Three ways to work together. Whichever fits, the people you meet are the people who build. Nothing gets handed off to juniors.
There are three ways to work with us, and the difference between them is commercial rather than technical. The scope changes, the shape of the commitment changes, and who holds the plan changes. What happens in the repository does not.
The team is two people. Both of us write code, both of us review the other's, and there is nobody behind us for the work to be handed to. That is the entire staffing model, and it is why there is no translation layer between the infrastructure and the application: Justin takes the platform, the servers, and the network, Josh takes the applications, APIs, and billing, and neither of us has to negotiate an architecture across an org chart.
This page exists because most of what gets handed to us already has paying customers on it — a billing pipeline halfway through changing processors, a control plane with a server fleet under it, a migration where the old system and the new one both have to be right on the same afternoon. When that is the starting position, how the work is run matters about as much as whether we can do it. So: the arc, the defaults, and what you are left holding when we leave.
The arc every engagement follows.
Four stages. The names are unremarkable — what matters is what each one is expected to produce.
Three ways in.
Same two people, same practices, same review discipline. The mode decides the shape of the commitment around them.
Project work
Fixed-scope builds and rewrites delivered end to end, from discovery and architecture design through launch. You get a defined outcome, a date, and code documented for whoever owns it next.
Learn moreOngoing partnership
We join your team and ship alongside it — writing code, reviewing PRs, and owning systems with you. Same standups, same board, same repo, and the practices stay after we go.
Learn moreFractional leadership
Fractional CTO / VP direction to set architecture, process, and hiring while you scale your team. Part-time senior direction without the full-time hire.
Learn moreWhich one, in one line each
Where AI fits in how we work.
Worth stating plainly, because the honest version and the sales version of this have drifted a long way apart.
We build with AI in the loop — planning, review, the mechanical half of a migration, the first pass at a test suite. It has changed how quickly the boring parts get done. It has not changed whether the hard parts are hard, and there is no version of this page that claims otherwise.
The concrete example is this site. The Vector API reference was ported onto it through a written plan worked one story at a time, each story reviewed and gated on a full test, lint, and build pass, and the generated output diffed against the previous build before any of it shipped — which is also how the port turned up defects in the documentation it replaced. That is the shape we trust: AI inside a process that already had a review gate, not in place of one.
What it does not change is who is accountable. Every pull request is still reviewed by a senior engineer before it merges, the same two names are still on the work, and nothing reaches your production because it looked plausible.
How an engagement ends.
The part most consultancies leave for you to find out, so it may as well be the part that is written down.
Every engagement is built to be leavable. That means code structured and documented for the developer who inherits it, runbooks for the operational parts, and a deploy pipeline your team can run without either of us in the room. None of it is a closing-week scramble; it is the same work, done as it goes.
We have had to prove that more than once. A2's end-to-end test suite was built quickly under real deadline pressure and then handed to a QA engineer who picked it up and ran with it. A full Rails application shipped in six weeks was built for clean handoff and taken over by the next developer without a rescue. Wormhole had a defined end — three legacy billing systems emptied into one platform — and it hit it, and then it was done.
The practices are the part that stays. Review discipline, tests on the paths that matter, deploy hygiene, and documentation that is generated rather than remembered. Those outlast the engagement, which is the point: the measure of the work is whether your team is better off running the system than they were before we touched it.
If you already know which of the three this is, start there. If you don't, say what the situation looks like and we will tell you which one we would pick — including the one where the answer is that you don't need us.