Who I Am

This is the longer version of the About page—who I am, how I got here, and what I've learned building and shipping software for more than a decade.

Four products, four different bets

Building four products at once may sound unfocused.

For me, it is a way to test several observations against reality.

Each product has a different customer, market, business model, and set of assumptions. Each one forces me to think differently about product design, distribution, technology, and what people are actually willing to pay for.

The goal is not to keep every product alive forever.

The goal is to learn which problems are real, which solutions people care about, and where my judgment is right or wrong.

Not every idea I pursue is completely original. That does not bother me.

Sometimes the opportunity is not inventing a new category. It is looking at an existing problem from a different angle, making a sharper set of decisions, and building the version you believe should exist.

The technology is not the point

I work across the whole stack, from the interface people use to the systems running underneath it.

AI has changed how much of that work I can take on myself. Research, design, engineering, operations, content, and analysis can now be compressed into a much smaller team—and sometimes into a single founder.

That shift gives me more room to explore ideas, move quickly, and build with a level of ambition that once required far more people and capital.

But the technology is not the point.

A product can be technically impressive and still fail to matter.

As an engineer, the temptation to begin with the build is always present. You have a cool idea, convince yourself it should exist, and start writing code. AI makes that temptation even more intoxicating because it has never been easier to turn a half-formed idea into a polished demo.

I have seen enough pitch competitions, startup showcases, and product demos to know that something can look convincing without being useful.

So I try to begin somewhere else.

I observe first.

Shipping is part of the research

I believe there is value in shipping.

Not simply because finished work is better than unfinished work, but because shipping exposes what thinking alone cannot.

A product changes once it reaches another person.

The assumptions become visible. The awkward parts become harder to ignore. People use it differently than expected, misunderstand what seemed obvious, or care deeply about something that felt secondary during the build.

Shipping moves an idea out of your head and into contact with reality.

What counts as shipping, however, changes across industries and business models.

For a consumer product, shipping may mean placing something in the hands of thousands of people and learning from attention, retention, habit, and word of mouth.

For a B2B product, shipping may begin with one customer, one team, or one narrow workflow. The software is only part of the problem. You also have to understand budgets, procurement, security reviews, organizational incentives, and how buying decisions are actually made.

In hard tech or deep tech, the feedback loops are longer and the cost of being wrong can be much higher. Shipping may mean completing a prototype, passing a technical milestone, manufacturing a component, running a field test, or proving that one difficult part of a system can work reliably.

The artifact changes. The principle does not.

Eventually, the idea has to meet the world.

That is one reason I am interested in building across different markets. Each develops a different kind of judgment.

Consumer products sharpen taste, clarity, and distribution.

B2B products force you to understand workflows, budgets, incentives, and institutions.

Hard and deep technology demand patience, technical rigor, capital discipline, and respect for the physical world.

I do not believe every company should be built the same way. I want to understand what shipping requires in each context—and what kind of builder I need to become to do it well.

I've been doing this for a while

I started building personal projects around 2010 and began working professionally as a software engineer in 2012.

I built for the web during the JavaScript and jQuery years. I moved into mobile as the modern app ecosystem was taking shape. I worked with Unity as it became a standard tool for independent game developers and later adopted React Native as cross-platform development matured.

Since then, I have worked across startups, financial institutions, agencies, consulting engagements, internal platforms, mobile apps, games, consumer products, and side projects that never became companies.

The tools changed.

The part I enjoyed did not: taking something unclear and making it real enough to test.

Over time, I also learned that every environment has its own definition of shipped.

At a startup, shipped may mean getting something useful into a customer’s hands before the company runs out of money.

At a large company, it may mean navigating dependencies, security requirements, legacy systems, and several teams before a change reaches production.

On a personal project, it may simply mean resisting the urge to keep polishing and finally letting another person use it.

The work is not finished when the code works. It is finished when the product survives contact with the people and systems it was built for.

Previous work

Before the four products I am building now, there were other products, experiments, client projects, and attempts:

InsOuts · Cutman · Baktun · NiteOwl · PeopleOps · ZeeMee · Vyse · Oiree

Some shipped. Some stalled. Some failed. Some were work for other companies. Others were ideas I could not stop thinking about until I built them.

Together, they are the better part of my education.

For each project, I want to document four things:

What it was — the problem, the intended user, and why I believed it deserved to exist.

What I contributed — what I designed, engineered, led, or helped bring to market.

What happened — whether it launched, found users, stalled, failed, changed direction, or became something else.

What it taught me — the lesson I carried into the next thing.

Not every project needs to become a successful company to have value. Sometimes the value is technical. Sometimes it is commercial. Sometimes it is learning exactly why an idea did not work.