About

I'm Alex.

I'm an engineer. If you've spent time around engineers, you probably know the type. I don't like making decisions until I understand what's actually happening underneath.

Most of the time, that starts with data.

Not because data is perfect — it isn't. But it's usually a better starting point than marketing copy, social media hype, or whatever the loudest person in the room happens to believe this week.

I started my career writing and reviewing code. Eventually I found myself spending less time evaluating pull requests and more time evaluating the software businesses built on top of them. Somewhere along the way I noticed a pattern:

There is no shortage of information.

There is a shortage of signal.

Most software content is surprisingly difficult to use.

A product page tells you why a company thinks its tool is amazing.

A review tells you why someone loves it.

A Reddit thread tells you why someone hates it.

By the time you've finished reading all three, you're often less certain than when you started.

Natural language is a terrible compression format.

People use the same words to mean different things. Marketing teams describe possibilities as outcomes. Assumptions get repeated until they become facts. Somewhere along the way everyone forgets where the original claim came from.

The result is thousands of words and very little clarity. This site is my attempt to fix that. I analyze AI and SaaS tools, and when I review a tool, I'm usually trying to answer a handful of questions:

• What does it actually cost?
• What are the tradeoffs?
• Where does it perform well?
• Where does it break down?
• Which claims are supported by evidence?
• Which claims are mostly marketing?

The "best" tool is usually just the least wrong tool for a particular situation. Different constraints produce different answers. My task is to gather the best information I can find, organize it, explain it clearly, and show my reasoning. After that, you decide what matters for your situation.

How I Work

Every analysis starts the same way. I collect evidence from product documentation, pricing pages, benchmarks, public data, technical reports, user discussions, changelogs, and independent testing. Then I try to separate facts from claims. If something is well supported, I'll say so. If something is uncertain, I'll say that too. If the available evidence is weak, conflicting, or mostly anecdotal, I don't pretend otherwise.

My Biases

I'm making a meal out of this because it matters — only with these in mind could you ever critique my assessments.

• I instinctively distrust claims that can't be measured.
• I am often willing to sacrifice convenience for transparency.
• I probably spend too much time understanding how something works before deciding whether I need it.
• I tend to underestimate the importance of aesthetics and overestimate the importance of technical merit.
• I trust reproducible results more than extraordinary claims.
• I prefer transparent pricing over sales calls.
• I generally favor simple systems over complicated ones.

You don't need to agree with my conclusions. You should be able to see how I arrived at them.