Approach

How I build: practical AI, strong UX/CX thinking, and system design that starts from real human use instead of technology for its own sake.

I work at the intersection of product logic, user experience, customer experience, system architecture, and AI-native development. Over the years I've worked in many roles, but the core pattern has stayed the same: understand what should exist, shape how it should work, and help bring it into reality in a way that makes sense for real people.

AI-native, but grounded

I'm very interested in AI-native products and systems, but I'm not interested in AI for its own sake. I care about where AI actually makes something more useful, more natural, more scalable, or more valuable for the people using it.

A lot of AI discussion still stays either too technical or too abstract. My own approach is more practical. I start from the real use case, the real customer, the real friction, and the real opportunity. Then I look at how AI can help improve that situation in a meaningful way.

For me, AI works best when it:

Technology moves fast, but adoption still happens at human pace. A system can be technically impressive and still fail if people do not understand it, trust it, or find it meaningful in their actual lives or work.

Builder first

At my core, I am a hands-on builder and creator. I've worked in many roles over the years, including founder, advisor, mentor, speaker, strategist, and product architect. Those roles have given me useful breadth, but building is the part I enjoy most. Especially now, when AI makes it possible to move much faster from concept to structured product, the builder role feels more powerful and rewarding again.

I like shaping systems that:

Bridging business logic, data, and user experience

A lot of my work has happened in roles where I have acted as the glue between business logic, data modeling, and user experience. In practice, this means understanding:

A very common output of that work has been a PRD or similar product definition document that communicates the key logic from all of these dimensions together — not as separate layers, but as one coherent view of how the product should work.

What AI changes most is the way the actual software gets built. The implementation layer becomes faster, more fluid, and more iterative. But the other layers do not disappear. Product logic, business logic, information structure, user experience, and system clarity are still very much needed. In many ways they matter even more, because AI can accelerate implementation only if the underlying intent is clear enough.

UX-driven architecture

I tend to start from the experience side first. If the interaction is unclear, the rest of the system usually ends up unclear too. So I often begin by asking:

From there, architecture becomes more meaningful. Data, identity, memory, and interaction are not only technical choices. They are also product decisions and experience decisions. That is why I often describe my approach as UX-driven architecture — I want the system boundaries, data flows, and AI structures to support the intended experience, not fight against it.

This also means I care a lot about clarity of product logic, information flows, long-term maintainability, observability, system behavior in real usage, and how complexity is exposed or hidden from the user.

More room for the details that make products feel good

One of the things I really enjoy in modern software development is that there is finally much more room for the details that actually make user experience good.

In the past, many of those details were often deprioritized in favor of more features. With AI, this no longer needs to be the case in the same way. Now there is much more room to shape:

Those are often exactly the areas that make the difference between a product that merely functions and a product that actually feels good to use.

My typical build process

  1. Clarify the job to be done, the user or customer reality, and the real constraints
  2. Talk through the problem and shape the product logic
  3. Turn that into structured notes, documentation, flows, and early decisions
  4. Move quickly into the first prototype, usually as close to the end-user experience as possible
  5. Iterate from the UI and interaction outward
  6. Refine the system logic, data flows, and architecture
  7. Observe what happens, learn, and improve

A lot of my early thinking happens by voice, often while walking outside. I use AI — especially ChatGPT — heavily in that phase to help clarify ideas, turn rough thinking into more structured logic, and shape documentation that is actually useful for building.

From there I like moving quickly into the first prototype, often using Lovable to get to the end-user experience immediately rather than staying too long in abstract planning. Once the prototype exists, I iterate through the UI and the interaction flow first, because the customer never experiences the architecture directly — they experience the product.

At the same time, I keep thinking about the underlying structure: what should be persistent, what needs memory, what belongs in structured data, what can stay flexible, what should be observable, and what future complexity is being created or avoided.

AI across the full workflow

I do not use AI only as a coding assistant. I use it across the full product workflow:

  • Brainstorming and voice-based thinking
  • Documentation and feature framing
  • PRD-style structure
  • Prototyping and UI iteration
  • System clarification
  • Coding support
  • Refinement and polish
  • Observation and iteration

The real power of AI is not only that it can generate code. The real power is that it can help reduce the distance between vague idea and clear structure, between structure and prototype, between prototype and refined product, and between observation and iteration.

Customer experience as a real system input

A big part of my thinking comes from customer experience. I care about building systems that do not just function, but actually help organizations understand and serve people better. I'm especially interested in products where customer interaction itself becomes a source of learning, insight, and improvement.

That is why themes like conversational products, customer experience systems, personal AI, and market-facing AI are interesting to me. They all connect to the same broader question: how do we make products and systems more meaningful, more understandable, and more responsive to the people interacting with them?

Technology should not feel like technology

Good technology should enable better experiences, not draw attention to itself unnecessarily. The best systems often feel obvious in use, even if the underlying architecture is complex.

That is one reason I care so much about UX, CX, interaction logic, and system clarity. If the product feels awkward, fragmented, or overly technical, that is usually not just a UI problem. It is often a deeper product and architecture problem.

So I try to build in a way where the human side stays visible, the system side stays strong, and the technology serves the experience instead of dominating it.

Practical principles

I'm most interested in building systems where product logic, user experience, customer reality, and AI capabilities come together in a practical way. That is where I do my best work.

Contact See projects