I’ve spent nearly two decades building software and solving complex technical problems. Much of my career has involved modernizing large systems—breaking apart legacy applications, designing cloud-native architectures, improving reliability and scalability, and helping teams evolve how software is built and delivered.
That experience taught me something important: the technology is rarely the hardest part.
The harder problems are understanding what actually matters, deciding what not to build, earning trust, working within real-world constraints, and creating something valuable enough that people willingly change their behavior to use it.
Those lessons increasingly shape everything I build.
From Engineer to Builder
Earlier in my career, I measured progress primarily through technical accomplishments. Could we make the system faster? More resilient? Easier to deploy? Could we design a cleaner architecture?
I still care deeply about those things.
But a technically excellent product that nobody needs is still a failure.
I’ve experienced that personally.
I previously built two startups—Mighty Buzzwords, a word game, and PaerMe, a professional networking platform. Neither became the business I hoped it would become.
Those experiences were valuable because they forced me to confront the distance between building something and building something people truly value.
Today, I approach entrepreneurship very differently.
I start with the problem. I talk to people. I look for evidence. I test assumptions. And I try to understand the existing behaviors, relationships, incentives, and constraints surrounding a problem before introducing more technology into it.
The goal isn’t to build more software.
The goal is to create something useful.
What I Believe
Technology should augment human capability rather than compete for human attention.
The products I admire most help people accomplish something they already care about: communicate more effectively, make a difficult decision with greater confidence, save time, reduce uncertainty, or gain capabilities they didn’t previously have.
That philosophy has become increasingly important as AI changes what individuals and small teams are capable of building.
AI dramatically lowers the cost of creating software. But lowering the cost of building something does not automatically make that thing valuable.
Understanding people, identifying meaningful problems, earning trust, and translating technology into useful outcomes become even more important.
That is where I want to spend my time.
How I Work
I tend to approach problems through a few principles.
Understand before building.
I want to understand how people solve a problem today before deciding how technology should change it.
Evidence over assumptions.
Ideas are hypotheses. Real behavior, customer conversations, experiments, and results are what turn those hypotheses into knowledge.
Simple systems beat impressive complexity.
Good technology should make difficult things feel easier. Complexity belongs behind the product, not in front of the customer.
Trust is part of the product.
People need to understand what a system is doing, why it is doing it, and how it benefits them. This becomes especially important as software becomes more autonomous.
Value should come before monetization.
I want to build businesses where revenue is a consequence of creating measurable value—not businesses designed primarily to extract as much attention or money as possible from customers.
What I’m Exploring Now
My current work sits at the intersection of software engineering, entrepreneurship, AI, and human decision-making.
I’m particularly interested in using AI and modern software to build systems that reduce friction and uncertainty without requiring people to reorganize their lives around another application.
That means thinking beyond the latest model or technical framework and asking more fundamental questions:
What problem are we actually solving?
What behavior already exists?
Where does trust come from?
What would make someone willingly pay for this?
And can technology make the experience meaningfully better without making it unnecessarily complicated?
Those questions guide the products I’m building, the experiments I’m running, and much of what I write about here.
Why I Share My Work
I don’t have a story where every project succeeded and every decision was correct.
I have something I believe is more useful: nearly two decades of building systems, making mistakes, learning from them, and becoming considerably better at recognizing what matters.
This site is where I share those lessons.
You’ll find ideas about software engineering, AI, entrepreneurship, product development, and the process of turning technology into something people actually value.
And as I build new products and services, this will also be where I share what I’m learning along the way.
If something I build can save you time, reduce uncertainty, help you make a better decision, or produce an outcome worth more than what you paid for it, then I’ve built something worth selling.
Explore my writing