We've spent 30 years bridging the gap between business and engineering, providing technical leadership across companies of every size and delivering results when it matters most.
We joke that we have a hundred years of experience, because we skip the quiet years. Organizations only bring us in when things are on fire. 🔥 That's exactly where we do our best work.
Fractional CTO, architecture review, or a trusted technical voice for decisions that carry real business risk.
Sometimes true. Usually not. You spent years building what you have, you need an objective assessment based on business reality, not just engineering preference.
Delivery failures almost always trace back to unclear ownership, mismatched process, or architecture that's become a bottleneck.
Recurring incidents mean the root cause has never been fixed, only the symptom. We fix root causes.
The worst time to be without a technical rudder is when the team is already uncertain. We step in fast.
Maybe. More often the team is fine, they just don't have the direction and leadership they need. We'll find out.
Rebuilt an engineering organization and delivered a production-ready payroll and HR management platform within five months after more than two years of unsuccessful development. Migrated 2,000+ existing customers while onboarding ~800 new ones directly onto the new platform.
Took over a platform team with daily production failures and eliminated recurring incidents within approximately eight weeks. The result: the smoothest Black Friday deployment in company history. The root cause wasn't the code. It was communication, ownership, and process gaps nobody had named.
Managed production systems for Ubuntu Linux ~393 services, Kubernetes and OpenStack deployments, and package infrastructure exceeding 100 Gbps during major release periods. Millions of systems depending on it every day.
20+ years of technical leadership across LATAM Airlines, Best Buy, Colorado State University, and many others. Architecture decisions, vendor risk, security posture, hiring, and the hard conversations that needed to happen before they became crises.
We don't just write code. We find the real constraint, technical, organizational, or both, and fix it.
Senior technical leadership without a full-time hire. Strategy, architecture, hiring, product alignment, and the honest conversations that need to happen at the executive level.
When things aren't shipping, incidents keep recurring, or the team is demoralized. We find what's actually wrong and fix the conditions, not just the code.
An honest assessment of where you are: what's solid, what's fragile, what's a hidden business risk, and what you actually need versus what you've inherited.
Pre-investment or pre-acquisition technical review. What's real, what's hidden, and what it'll actually cost to build on or dig out of.
Authentication, authorization, and trust infrastructure designed for real-world failure modes, compliance requirements, and adversarial environments.
Cloud infrastructure, operations, and SRE. Build systems your team can confidently own and maintain without depending on any single indispensable person.
Most serious engineering failures are not purely code problems. They surface as missed deadlines, production failures, or stalled products but the root cause is almost always a leadership, communication, ownership, process, or architecture problem underneath.
We look at both the technical system and the human system around it. We find the smallest practical changes that create meaningful improvement. And when we leave, the team can sustain what we built because the team is better, not just the code.
We fix the systems. More importantly, we fix the conditions that created them.
There's a lot of code out there. Most problems have good solutions: existing tools, known patterns, established approaches.
But sometimes you hit a problem where the existing tools don't cut it. Sometimes the accepted wisdom is that it can't be solved at all. We hit those walls too. The difference is we don't stop there.
These are the things we built when we kept thinking. And when we solve something genuinely new, we give it to the world — because hard problems deserve open solutions.
Every IAM system inherits this assumption: OAuth, SAML, certificate authorities, token registries. All require a network call at the moment of decision. All require a central authority to issue or validate identity. Vouchsafe / ZI-CG is what you get when that isn't good enough.
ZI-CG breaks both assumptions simultaneously. Identity is self-issued, no central authority, no registry, no issuer to trust or compromise. And yet tokens are fully, cryptographically verifiable by anyone, anywhere, with no network call required. That combination was assumed to be impossible. It isn't.
Vouchsafe is the working implementation. Built on JWT, compatible with existing tooling, deployable today. Trust travels with the token. Verification is a local computation, not a runtime query. It works online, offline, and in environments where centralized identity infrastructure is a liability rather than an asset.
Read the paper (arXiv) → getvouchsafe.org →Every integration project reinvents the same transformation logic, usually as bespoke, untested code that becomes someone's problem later. DTL replaces that with a sandboxed transformation language: describe the shape of the data you need, and DTL handles the restructuring. Because DTL has no access to your filesystem, environment, or libraries, it's safe to run even when the transformation comes from a third party. Transformations are data, not code: storable, versionable, and portable across every environment where JavaScript runs.
getdtl.org →Client/server architecture is so pervasive we've almost forgotten it's not the only option. Servers, databases, APIs, authentication layers, deployment infrastructure... all of it has to exist before you can even start your actual application development. PAN is what happens when you reject that constraint.
PAN is a communication substrate that lets independent programs find each other and cooperate without a central server. There's no backend to deploy, no canonical authority, no infrastructure that has to exist before your first feature works. Applications emerge from participants: actors that join groups, exchange messages, and decide locally what those messages mean. Add a persistence actor and you get history. Add an arbiter and you get coordination. The application grows by gaining participants, not by a central service accumulating complexity.
Client/server means application functionality is an all-or-nothing affair. Either you can reach the server and everything works, or you can't and the world goes silent. PAN changes the rules. Without a central server there's nothing whose absence causes total failure. Users continue to communicate with whoever is still reachable. Degradation becomes graceful by default, or in many cases not degradation at all.
PAN is currently in beta. We're building with it and actively looking for collaborators who want to explore what application architecture looks like without the baggage.
Get in touch →We're selective about the work we take on... because our best work happens when the fit is right. Tell us what's going on.
Start a conversation