Taste is a moat

It has never been easier to build software that looks finished and feels empty.

For a long time, the hard part was getting anything built at all. You needed the technical depth, the time, the team, or the money just to get from idea to something working, and that alone filtered most people out.

That filter is much weaker now. More people can build, more people can ship, and more people can get to version one without waiting on a big team or a big budget. That is a genuinely good thing.

But it also means execution, by itself, is less defensible than it used to be.

If a thousand people have access to the same models, the same editors, and the same infrastructure, then the toolchain is not the edge. The tools matter, and I use them every day, but they are not the moat.

Taste becomes the moat.

What is easy to copy is the visible output. The screens, the features, the polished surface. What is much harder to copy is a product that feels like somebody cared enough to make the right trade-offs.

Taste is judgment

When I say taste, I do not just mean visual design. I mean knowing what to build in the first place, and knowing what not to build even when you technically can.

I mean noticing when a flow works on paper but feels annoying after the third time. I mean knowing when a feature makes a product look more complete while actually making it worse. I mean caring about the difference between functional and clear.

That is taste.

It is product judgment, restraint, coherence, and standards. It is being able to look at something that technically "works" and still feel that something is off.

A lot of people hear the word taste and think about style first. Fonts, colours, motion, polish. That stuff matters, but it is the shallow end of the pool.

Real taste shows up much earlier than that. It shows up in the decision to make one thing good instead of six things average. It shows up in whether the product explains itself or needs a tutorial. It shows up in the naming, the defaults, and the things you never ask the user to do because you took the time to think it through first.

The best products often feel obvious, which is usually a sign that somebody made a huge number of good decisions to keep them that way.

Great products are edited

A lot of software gets built by addition. It keeps picking up more options and more surface area until the original thing gets harder to understand.

The part people miss is that good product work is usually editing. It is cutting the extra step, deleting the feature that drags the whole product sideways, and deciding that the clever solution is not worth the cognitive cost.

This is where taste stops being abstract and gets painfully practical.

Adding feels productive. Removal feels risky. Addition gives you something to point at; removal mostly gives the user less to think about, which is harder to celebrate in a roadmap and much easier to feel in the product.

But users feel it. They feel when a product has been shaped by someone who kept asking, does this need to be here? They feel when the path is clean and when the product respects their time.

They also feel the opposite.

You can open a product and sense that it was assembled rather than considered. Everything is there, technically. The features exist. The buttons work. But nothing feels settled. Every screen seems to have been designed in isolation. Every new capability sits next to the last one without a real point of view tying it together.

That kind of product is hard to love.

Small teams have the edge

This is also why solo founders and small teams have an advantage right now. It is not because speed alone wins, since plenty of fast products are forgettable. It is because smaller teams can keep a product coherent.

They can hold the line on what the thing is and what it is not. They can care about details without needing a meeting for every decision. They can protect the original point of the product before it gets diluted into something broader and safer and less useful.

Committee-built products usually do not fail all at once. They just drift.

One compromise at a time.

One exception. One stakeholder request. One extra flow because nobody wanted to say no.

A few months later the product still works, but the centre of it is gone.

Taste survives better when fewer people are touching the wheel. That does not mean every solo founder has great taste, obviously, only that when taste is there it is easier to preserve.

And that matters more now because so much of the technical leverage has been flattened.

Care is visible

Users can tell when something has been made with care, even if they would not say it that way.

They can tell when the copy sounds like a person thought about what they needed in that moment. They can tell when a setup flow does not ask too much up front and when the product gets out of the way.

They can also tell when something has been shipped with no real conviction behind it.

A lot of products now feel like they were assembled from the outside in. The pieces are familiar and it all looks competent enough, but there is no real judgment inside it. No sharpness. No sense that someone decided what mattered and protected it.

That is what happens when code gets cheap. You can build more than ever and still end up with something strangely empty. Not broken, just forgettable.

Taste can be trained

The good thing is that taste is not some magical trait that only a few people get. It can be built, and you build it by paying attention.

You build it by noticing what feels smooth and what feels clumsy, by using your own product enough to get annoyed by the right things, and by looking closely at products you respect.

You also build it by staying close to your users. By talking to them, caring about what they say, helping them debug when things break, and spending enough time with them to understand what they actually think about the product.

That is where standards get real. Not the kind that only sound good in your head, but the kind that hold up with real users.

Does this make the job easier? Does this deserve to exist? Is this clear the first time? Why am I asking the user to care about this at all?

Those are taste questions, and they compound.

If you answer them honestly, the next decision usually gets easier. Every sloppy compromise makes the next one easier to justify.

That is why taste is not just about what you like. It is about what you repeatedly allow.