Approach
Building AI products well requires a different mindset from building traditional software. Here's how I think about it.
Most software companies are adding AI to existing products. That's not the same as building AI products.
When you bolt AI onto a product designed for the pre-AI world, you get incremental improvement at best. You don't rethink what's even possible. AI-native products are designed from first principles around what AI makes achievable — and they produce outcomes that simply didn't exist before.
The best AI-native products don't feel like they use AI. They feel like magic. That's the standard I hold my products to.
Three principles
AI-first design
Every product I build is designed around AI capabilities from day one — not retrofitted. This means rethinking UX flows, data models, and business logic through the lens of what AI makes possible.
Rapid execution
Speed is a moat. I compress the cycle from idea to live product to weeks, not months. This means opinionated tooling choices, focused scope, and shipping before perfecting.
Real distribution
I don't build products without a clear distribution path. Understanding how users will find, adopt, and recommend a product is part of the design process — not an afterthought.
From idea to business
Identify the problem
Start with a real pain point in a market I understand. Not a technology looking for a use case, but a genuine problem that people are currently solving expensively or badly.
Validate the distribution path
Before writing code, I answer: how will users find this? What acquisition channels exist? Is there a community, a workflow, or a regulation that creates natural entry points?
Design the AI-native workflow
Redesign the user workflow from scratch around what AI makes possible. Not a copy of existing software with AI sprinkled in — a fundamentally different experience.
Build the core experience
Ship the smallest possible version that solves the problem compellingly. I use opinionated tooling and avoid premature architecture. The goal is a working product, not perfect code.
Launch and learn
Get the product in front of real users as fast as possible. The first version will be wrong in some ways — the goal is to find out which ways, and fast.
Iterate with discipline
Not every piece of user feedback is a feature request. Distil signals from noise. Iterate on the things that move retention and conversion; ignore the rest.
Build the business
A product is not a business. A business has a sustainable model, a repeatable acquisition motion, and a defensible position. This work begins at launch, not after.
How products become businesses
A product without a business model is a hobby. Every product I build has a clear commercial model from the start.
Recurring revenue beats one-time sales. I focus on subscription or usage-based models that reward retention and product quality.
The unit economics have to work. Customer acquisition cost, lifetime value, and payback period are designed for, not discovered after launch.
Distribution is a product decision. The acquisition channel shapes what features matter, what onboarding looks like, and what price makes sense.
See it in practice
The best way to understand my approach is to look at the products I've built.