Software With a Spine

I’ve been thinking about this a lot lately. The tools I actually love using have something in common. They don’t ask me how I want to do things. They tell me how things are done. And I’m grateful for it.

The Feature Request Trap

Customer asks for a thing. It’s easy to build now. You build it. Repeat this 500 times and suddenly your settings page has 47 toggles and your navigation has nested menus three levels deep.

You didn’t design software. You accumulated it.

This has always been a problem, but AI is making it worse. The friction between “customer wants this” and “we shipped this” used to be engineering time. That friction forced prioritization. It made you ask whether a feature was actually worth building.

Now you can say yes to everything. Which means you probably will.

The question used to be “is this worth the engineering time?” Now it’s “why not?” And “why not” is a terrible product strategy.

Why I Love Software That Tells Me What to Do

Linear doesn’t ask me how I want to manage issues. It has opinions about how issue tracking should work, and those opinions are baked into the product. There’s one way to do it, and it’s the right way.

Their philosophy is explicit: “Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.”

Compare this to Jira, where you need a dedicated administrator just to configure the thing. Where every team invents their own workflow, their own custom fields, their own way of doing things. Where onboarding a new person means teaching them your company’s specific flavour of Jira chaos.

Linear’s constraints are a feature. When the software has opinions, it makes decisions for you. You don’t have to figure out the “right” way to use it because the right way is the only way.

Superhuman charges $12 a month for email and won’t even let you use it without completing their onboarding. They have strong opinions about keyboard-first workflows, about how email should feel, about what belongs in an email client and what doesn’t.

You can’t customize your way out of their vision. And that’s why people love it.

Basecamp and HEY are famous for saying no. 37signals has been preaching opinionated software since the mid-2000s. Their products work a specific way, and if that way doesn’t work for you, you’re probably not their customer.

They’re fine with that.

Apple used to be the poster child for this. Jobs-era Apple was ruthlessly opinionated. No stylus on the iPhone, no Flash, one-button mouse for years. “You don’t need it” was practically a company slogan. They decided what users wanted before users knew they wanted it. The company is less opinionated now (more ports, more options, more configurations) but the products that defined them were built on strong opinions about how technology should work.

The Paradox of Choice

Users say they want flexibility, but they love products that make decisions for them. Every customer survey will tell you people want more options, more customization, more control. Then you give them a blank canvas and they stare at it paralyzed, unsure where to start.

Notion is the ultimate example. I love Notion, it's incredibly powerful, infinitely flexible, but yeah... most people’s Notion workspaces are a mess of half-finished dashboards they set up once and never touched again. The tool does everything, which means the user has to figure out everything.

The opinionated column is full of products with passionate users. The unopinionated column is full of products people tolerate.

The Builder’s Perspective

Saying no is a feature.

Every feature you don’t build is maintenance you don’t have, edge cases you don’t handle, documentation you don’t write, support tickets you don’t answer.

Opinionated software is easier to explain, easier to market, easier to maintain. “We do X this way” is a clearer message than “we do X however you want.”

The first one is a position. The second one is a void.

I’ve built products both ways. The ones where I tried to please everyone ended up pleasing no one. The ones where I made decisions and stuck with them attracted people who wanted exactly what I was building.

I mean, Stripe is opinionated about how payment APIs should work. They spent years thinking about the right abstractions, the right patterns, the right way to handle edge cases. You don’t configure Stripe to work your way. You learn the Stripe way, and the Stripe way is really good.

That’s the trade. You give up flexibility and you get quality. You give up customization and you get coherence.

The Vibe Coding Danger

AI makes building easy. Too easy maybe.

I can describe a feature and have working code in minutes. I can take a customer request and ship it the same day. The technical barrier to saying yes has essentially disappeared.

This is great for prototyping. It’s dangerous for product development.

The problem is that good product decisions require saying no to most things. They require understanding that every feature has a cost beyond the engineering time. There’s cognitive load for users, there’s surface area for bugs, there’s complexity in the mental model of how the product works.

When building was hard, you had to be selective. Now that building is easy, you have to be disciplined. And discipline is harder than necessity.

I catch myself doing this. Customer asks for something, I think “that would only take an hour,” and suddenly I’m building it without asking whether it should exist at all.

The chat box in every app is the symptom. The disease is the belief that more features equals better product.

The Courage to Have a Fucking Point of View

Opinionated software requires confidence. You have to believe your way is good enough that some customers will leave over it. That’s scary, especially when you’re small, especially when every customer feels precious.

But the customers who stay are the ones who actually want what you’re building. The ones who leave were never really your customers. They were tourists looking for something you were never going to be.

Owner, a restaurant software company, is very opinionated about how restaurant websites should work. Customers can upload their logos and brand colors, but they can’t change the placement of CTA buttons or the conversion flow. The company optimizes for performance, not customization.

This drives some potential customers crazy. It also means their actual customers get websites that convert better than whatever custom solution they would have designed themselves.

The point of view is the product.

How to Actually Build Software With a Spine

There’s no tutorial for this. Nobody teaches you how to have opinions about software. So here’s what I’ve figured out from building things that worked and things that didn’t.

Step 1: Start With Your Frustrations

The best opinions come from lived experience. You built this thing because something else sucked. What specifically sucked about it? Write that down.

Not “it was hard to use.” That’s too vague. What was hard? What decision did they make that pissed you off? What did you wish it did instead?

Those frustrations are your first opinions, and they’re also your marketing. “We built this because that sucks” is a message that resonates with everyone who also thinks that thing sucks.

Step 2: Write Your Beliefs Before Code

Before you build anything, write down what you believe about how this type of software should work. Not features. Beliefs.

For example, if you’re building a task manager:

• “Tasks should have one owner, not multiple”
• “Due dates create anxiety and should be optional”
• “Weekly reviews matter more than daily planning”

These might be wrong. That’s fine. The point is to have a starting position. You can evolve your opinions, but you can’t evolve from nothing.

I keep a doc called “Opinions” for every product I build. When I’m stuck on a feature decision, I go back to that doc and ask which choice aligns with what I said I believe.

Step 3: Pick One User and Optimize Ruthlessly

“Small businesses” is not a user, and “Marketing teams” is not a user. These are categories that contain thousands of different people with conflicting needs.

Pick one person, give them a name if it helps, and describe their day, their frustrations, and their workflow. Now build for that person and nobody else.

When someone asks for a feature, ask whether your one person would want it. If the answer is “maybe some users would,” that’s a no. Your person either wants it or they don’t.

This feels limiting but it’s actually freeing. You stop trying to please everyone and start building something that’s perfect for someone.

Step 4: Make the Decision, Then Remove the Option

When you’re tempted to add a setting or a toggle, stop. Make the decision yourself instead. Don’t add “choose between list view and board view.” Pick the one that fits your beliefs about how work should be organized. Ship that.

If you’re wrong, you’ll hear about it. But you’ll hear about it clearly, because users will tell you the decision is wrong. That’s useful feedback.

If you ship both options, you’ll never know which one is right. You’ll just have two half-maintained views forever.

The rule: every toggle is an opinion you refused to have.

Step 5: Document Your Opinions Publicly

Write them down where customers can see them. Basecamp has their books. Linear has the Linear Method. Stripe has their API design philosophy.

This does two things. First, it forces you to articulate what you actually believe, which is harder than it sounds. Second, it lets customers self-select. The ones who disagree don’t sign up in the first place.

Step 6: Defend Your Opinions (But Update Them Deliberately)

When customers push back, don’t fold immediately. Ask why they want something different, and often you'll realize they’re trying to solve a problem you should solve a different way.

But don’t be stubborn for the sake of it either. Sometimes customers are right and your opinion was wrong. The difference is:

• Folding: Customer asks for X, you add X
• Updating: Customer asks for X, you understand why, you realize your belief about Y was flawed, you update your belief, you build Z which solves their problem better than X would have

Folding accumulates features. Updating evolves your product. One makes software worse. The other makes it better.

Step 7: Review for Accumulation

Individual features seem harmless. It’s the accumulation that kills you.

Every few months, look at your product with fresh eyes. Does it still express a coherent point of view, or have you slowly added enough exceptions that the opinions got buried?

If you can’t explain your product’s philosophy in two sentences, you’ve probably drifted. Time to cut things.

The Products I Actually Love

When I think about the tools I reach for every day, they’re almost all opinionated.

Fastmail for email, iA Writer when I need to focus on words without fifty menus staring at me, Rails and sometimes Next.js for building web apps, and Go for CLI tools. I built Preflight on it, and the language’s opinions about formatting, error handling, and simplicity meant I spent less time arguing with myself about how to structure things.

I’ve suffered through enough Jira to know the difference between software with opinions and software that makes you configure everything yourself. Phabricator got this right years ago. Strong defaults, clear workflows, opinions about how code review should work. Linear carries that torch now.

The tools I dread using are the opposite. The ones where I have to configure everything, where every team has their own setup, where the product is a framework instead of a solution.

Flexibility sounds good in theory. In practice, it means I’m doing product design work that the product team should have done for me.

Software With a Spine

The best products feel like they were made by someone with a point of view, not a committee, and not an AI that said yes to everything.

You should not be a feature factory that ships whatever customers asked for. Be a person, or a team, that decides this is how it should work and stand by it.

That confidence is rare now. Everyone is afraid of losing customers, afraid of bad reviews, afraid of the tweet that says “I can’t believe this product doesn’t do X.” So they add X, and Y, and Z, until the product does everything and stands for nothing.

I’d rather use software that does one thing really well than software that does everything adequately. I’d rather have a tool that makes decisions for me than a tool that makes me make all the decisions myself.

Opinionated software is harder to build because it requires you to be right about things. It requires taste, and confidence, and the willingness to lose customers who want something different.

But the products that survive, the ones people actually love, almost always have a spine. They know what they are, and they know what they’re not. And they’re not afraid to tell you.