For founders putting an AI product in front of paying customers
Launch your AI product knowing exactly how it will hold up.
Most founders launch and find out. I trace how your agents and LLM systems actually behave when providers time out, retries fire twice, and permissions are wider than anyone meant. Ten business days, fixed scope, your team keeps shipping.
Book a free 20-minute reviewI'll tell you where I'd look first. No pitch, no prep on your side.What I look for
- What happens when the model provider times out halfway through a run?
- Which retries can fire twice, and what do they write when they do?
- What can each agent reach that it doesn't need to?
- Where does customer data go once it leaves your database?
- What breaks first when ten users become a thousand?
- What does a deploy do to work that's already in flight?
What you get
A system map
What's actually built, not what the architecture doc says. Every agent, tool, queue, and external call on your critical paths.
A risk register
Every finding with a severity, a blast radius, and the exact path it sits on. Written so an engineer can act on it without a meeting.
A roadmap
Split three ways: fix before launch, fix before scale, accept and monitor. So you know what to do this week and what can wait.
Every review includes
- Fixed price, no surprises. The fee on the SOW is the fee. If your system turns out messier than either of us expected, that's on me.
- Thirty days of questions. After the readout, email me about anything in the report for thirty days and I'll answer. No hours, no invoice.
How it works
- Free 20-minute reviewYou walk me through the system. I tell you where I'd look first and whether a full review is worth it.
- Kickoff and accessOne call with your team. Read access to the repo, infra, and observability. That's usually all I need.
- Ten business days of reviewI trace up to two critical paths end to end. Two or three short interviews along the way. Your engineers stay on their work.
- Recorded readoutNinety minutes walking through the map, the register, and the roadmap with whoever needs to hear it.
- Optional: I stay in the roomSome founders want a senior architect around while they fix things and ship. That's a separate conversation, and it starts on the last page of the roadmap.
Who it's for
Small teams, a founder plus a few engineers, putting an AI product in front of paying customers for the first time. Products that run on AI, and products that were built with AI tools and now have to hold up.
- You have a launch date and a system you don't fully trust yet
- An enterprise customer just sent a security questionnaire
- Investors are asking how the thing actually works
- Something already went wrong once and you want to know what else will
Probably not for you if
- You want someone to build features or take on implementation work
- You need a penetration test or a compliance certification
- You're an agency looking for a subcontractor
- You're choosing on price rather than on what gets found
Questions founders ask
What access do you need?
Read access to the repo, your cloud console or infra-as-code, and whatever observability you have. One 45-minute kickoff with you, and two or three 30-minute conversations with the engineers who built it. I don't need write access to anything.
How much of my team's time does this take?
Two to four hours total, spread across ten business days. The review runs asynchronously. Your engineers stay on the launch.
What exactly do I get?
A system map of what's actually built, a risk register with every finding ranked by severity and blast radius, and a roadmap sorted into fix before launch, fix before scale, and accept and monitor. Plus a recorded 90-minute readout you can share with your team or your investors.
Our engineers could do this themselves. Why hire you?
They probably could, in the three weeks they don't have before launch. And they built it, which makes some of the assumptions invisible to them. I've spent twenty years being the outside set of eyes on systems like yours.
What happens after the review?
Your call. Take the roadmap and work it with your team, hand it to anyone you like, or keep me in the room for the next three months while you fix the things that matter. That conversation happens on the last page of the readout, not before.
Do you review products built with AI, or products that use AI?
Both. A product that was vibe-coded to a working demo has most of the same failure modes as one running an agent in production, and I look for the same things in each.
About
AI made building the easy part. Anyone can get to a demo now, and to an MVP by the weekend. I think that's good. It means more people can build something they own instead of renting their income to someone else. But everything after the demo is where it falls apart, and the product breaking the first time it meets real users is the most expensive way to find out.
That's the part I care about.
I've spent 20 years building and securing distributed systems, at Microsoft, Black Duck, runZero, and a handful of smaller companies. Today I'm a Principal Architect running high-volume workflow infrastructure in fintech. I've watched systems fail under load, under attack, and under growth, and most of my opinions about retries come from watching them go wrong at scale.
I'm also a founder. I build my own products with the same constraints you have, limited hours and my own money, and I'm honest in public about what breaks. So I'm not going to tell you to rebuild for a million users. I'm going to tell you the smallest set of things that need to hold at your next stage, and which ones can wait.
I'm not an agency and I don't take build work. I do one thing: look at a system before it meets real customers and tell you, specifically, how it will fail. Then I hand you the list and get out of the way.
If you're about to launch, the cheapest time to find out is now.
Twenty minutes. You show me the system, I tell you where I'd look first. If a full review makes sense, I'll say so. If it doesn't, I'll say that too.