Taste as a Service

I have been using Omarchy recently, and it has made me reconsider what I value in software.

Omarchy is a Linux distribution created by David Heinemeier Hansson, better known as DHH, the creator of Ruby on Rails and co-owner of 37signals. It brings together existing open-source technologies, applications, and tools into an opinionated desktop experience.

I could assemble many of those ingredients myself. Most are freely available.

I would still rather use Omarchy.

What I value is the judgment behind how those ingredients fit together: which applications belong, how the shortcuts work, what the desktop looks like, and what I shouldn’t have to configure before getting started.

The idea comes from omakase, the Japanese dining practice of leaving the selection to the chef. You bring your appetite and preferences. The chef decides what to serve.

DHH described this philosophy when introducing Omakub, his earlier Ubuntu setup: someone with a strong point of view does the configuration and curation upfront, giving others a coherent place to start.

That is what appeals to me about Omarchy. I can change the decisions. I simply appreciate not having to make all of them.

As AI expands what we can build, I suspect that feeling will become increasingly important.

Put the same ingredients in front of an average cook and a great chef, and you will get very different meals. A great chef knows what belongs together, what needs another minute, and what should never have been added. Experience becomes hundreds of decisions the person eating the meal never sees.

Software works much the same way.

We notice additions. Features appear in release notes, product demos, and sales pitches. Omission is harder to advertise. Yet deciding what to leave out can contribute as much to a product as anything it ships.

AI is giving more people access to a bigger kitchen. Prototypes, small applications, and internal tools are becoming easier to create. More people can attempt work that previously required a specialist or a team.

Turning those experiments into dependable software still takes engineering, maintenance, and care. But as the effort required to produce an initial implementation falls, another question becomes more prominent:

What should we build in the first place?

For much of the software era, the cost of building helped justify the cost of buying. If I needed a CRM or a project management system, paying a vendor was usually far more practical than creating and maintaining my own.

Vendors still earn their fees through reliability, security, integrations, support, and the responsibility they take off a customer’s hands. Those benefits survive cheaper code.

What becomes harder to defend is a product whose main selling point is a collection of features that customers can increasingly reproduce themselves.

Imagine a customer who dislikes one workflow in your product. Their choices used to be fairly constrained: tolerate it, configure around it, switch vendors, or pay for custom development.

AI makes another option more accessible: build the small piece they actually need.

They may never replace your entire product. They may only replace the part that once made it worth buying.

That puts pressure on a familiar SaaS promise: we give you the features, and you configure them however you like.

Flexibility has real value. It also transfers work to the customer.

Someone still has to decide which fields matter, how a workflow should operate, what deserves attention, and which exceptions are acceptable. More possibilities do not automatically make those decisions easier.

Eventually, flexibility can start to feel like administration.

Call it the configuration paradox: the easier software becomes to customize, the more valuable good defaults can become.

Customers may increasingly pay for a product because they trust its approach to the work. They want the benefit of decisions someone else has already considered, tested, and refined.

You can see this philosophy in Linear’s product principles. Linear argues for software designed around a clear purpose and warns that letting everyone invent their own workflows can create disorder as teams grow.

The promise is straightforward: we have thought carefully about how this work should happen. Start here.

37signals has advocated the same principle for years. In “Make Opinionated Software,” the company argues that a product should express a clear vision and serve people who share it.

AI may give that philosophy greater economic weight.

The word taste can make this sound like an argument about appearances. Typography, visual balance, and satisfying interactions matter. But the taste I mean reaches deeper.

It is deciding that five options are enough. It is declining a feature request because satisfying one customer would complicate the product for everyone else. It is knowing which metric deserves the most prominent place on a screen.

It is deciding when AI should act, when it should ask, and when it should stay out of the way.

Taste, in this sense, is judgment expressed through the product.

That is what I mean by Taste as a Service: software that carries some of the burden of deciding how the work should be done.

A sales product might recommend a useful next action instead of presenting another dashboard. A marketing product might help a team identify which signals warrant a response. A project management product might provide a working rhythm that a team can adopt without designing its own operating system first.

The value is in helping the customer move forward with fewer unresolved decisions.

This requires restraint. A good default should fit the people the product serves, and customers need a way to depart from it when their circumstances demand it. An opinion becomes useful when it reflects understanding of the work. Otherwise, it is just another obstacle.

There is also an obvious challenge to the argument: AI can reproduce product decisions as well as code.

It can study an interface, imitate a workflow, and copy a set of defaults. A founder’s claim to good taste is a fragile basis for a lasting business advantage.

The stronger possibility is judgment that improves through use.

Imagine two companies with similar products. One responds to every request by adding functionality. The other has a clear view of the work and keeps testing that view against customers’ experiences.

Where do people get stuck? Which defaults help them finish? Which automations create extra work? What can be removed?

Over time, those answers can become institutional knowledge. The company learns which decisions work, for whom, and under what conditions. Customers gain confidence in its recommendations because those recommendations keep proving useful.

Trust makes customers more willing to delegate. That creates further opportunities to learn—provided the company measures whether its choices actually help. Acceptance alone is weak evidence; people also accept defaults through inertia.

The advantage is therefore something the company must continually earn. A competitor can copy the current interface and many of its visible choices. It may be harder to match the customer relationships, accumulated context, and ability to make the next good decision.

That is the difference between copying a recipe and running a restaurant.

I think this leaves some software companies in an uncomfortable position. Broad platforms offer enormous capability. Custom tools increasingly offer a closer fit to a particular need. A generic product between them needs a compelling reason to exist.

A long feature list may become a less persuasive answer.

A stronger answer is a product that understands a particular kind of work exceptionally well. It makes useful choices, delivers dependable results, and keeps improving as it learns. It is willing to disappoint people whose needs it was never designed to serve.

There will still be markets where flexibility is the product. There will still be customers who want to build everything themselves. But greater freedom to customize does not mean everyone wants the responsibility.

Sometimes the most valuable thing software can say is: we recommend doing it this way.

That brings me back to Omarchy.

It is a small example of a preference I expect to matter more broadly. I have access to the ingredients. I value a coherent experience assembled by people whose judgment I trust.

We understand this instinct when we choose a restaurant. Part of what we pay for is the relief of leaving decisions in capable hands. Choose the ingredients. Prepare them well. Serve something worth coming back for.

AI will help create an enormous amount of software. The companies I expect to stand out will give customers a reason to trust the choices inside it.

Building is getting cheaper. Knowing what is worth building still has to be earned.