Why I'm Consulting

I’ve spent the last twenty years inside some of the largest infrastructure organizations in the world. Amazon, AWS, Uber, Twitter, Meta. The problems were fascinating: global-scale storage systems, real-time ride matching, social graphs with billions of edges. I learned more than I could have imagined when I started as a kid running Linux on spare hardware in New Mexico.

But somewhere along the way, I noticed a pattern. The hardest problems I was solving weren’t actually that hard. They were hard because of organizational complexity, not technical complexity. The underlying infrastructure challenges that kept startups up at night were things I’d solved dozens of times before. The difference was that I had the context of having seen it at every scale, from a single EC2 instance to the largest distributed systems on the planet.

What I Keep Seeing

I talk to a lot of founders and early engineering leads. The conversations sound the same. They’re running on AWS with a setup that was fine at ten customers but is starting to creak at a thousand. Their “security posture” is one person’s Google account with a password they also use for Netflix. They want to add AI features because their investors keep asking about it, but nobody on the team has deployed a model to production before.

These aren’t hard problems. They’re solved problems. But they’re solved problems that require specific experience to solve well, and that experience is concentrated in a handful of large companies that early-stage startups can’t hire from.

The Break-Glass Problem

The service I’m most convinced about is the simplest. I hold your AWS root credentials and Google Workspace super admin access. That’s it. If every internal admin gets compromised, locked out, or goes rogue, I’m the external failsafe who can recover your accounts.

It sounds paranoid until you need it. I’ve seen what happens when a startup’s only AWS admin leaves the company and nobody can find the root credentials. I’ve seen what happens when a disgruntled employee with super admin access decides to cause damage on their way out. These scenarios are rare, but when they happen, they’re existential.

The model is a monthly retainer. You’re paying for insurance and expertise, not hours. Quarterly I verify the access still works and do a quick review of who has admin privileges. The rest of the time, you don’t hear from me. That’s the point.

Infrastructure Without the Enterprise Overhead

For Cloud and SRE work, I do architecture reviews, infrastructure design, and reliability engineering. The thing I bring that a generic consultant doesn’t is context. I know what good looks like at scale because I’ve operated it at scale. But I also know that a ten-person startup doesn’t need the same tooling as a ten-thousand-person company.

The instinct in this industry is to over-engineer. Kubernetes when a few containers on ECS would do. Microservices when a well-structured monolith would be faster to ship and easier to maintain. Multi-region active-active when a single region with good backups covers the actual reliability requirements.

I help teams build what they need now, with a clear path to what they’ll need later. Not the other way around.

AI That Actually Ships

The AI infrastructure work grew out of what I do at Tensor9. We build deployment infrastructure for air-gapped and on-premises environments, which means I spend my days thinking about how to run models in places where you can’t just call the OpenAI API.

Most startups don’t need air-gapped AI. But they do need someone who understands the infrastructure side of deploying AI features. How to structure the API gateway. When to cache responses. When to switch from a cloud API to a self-hosted model. How to keep token costs from eating the margin on your product.

The ML researchers know the models. I know the infrastructure that makes them production-ready.

Why Not Just Keep Working Full-Time

I am working full-time. Tensor9 is my primary focus and I love the work we’re doing there. Consulting is a complement to it, not a replacement. The problems I help with are scoped engagements, not open-ended retainers that would conflict with my day job.

There’s also a selfish reason. Working with different startups keeps me sharp. Every new codebase, every new architecture, every new set of constraints teaches me something. The best infrastructure engineers I’ve known were the ones who’d seen the most variety, not just the most scale.

Getting Started

If any of this sounds relevant to what you’re building, I do a free 30-minute intro call. No pitch, no slide deck. Just a conversation about your infrastructure and whether I can help.

The consulting page has the details on services and pricing. Or just grab time on my calendar and we’ll talk.