The Case for Constrained Tools: Why Less Software Means More Productivity

The Paradox of Choice in Software

In 2004, psychologist Barry Schwartz published “The Paradox of Choice,” arguing that more options do not make us happier or more effective. They make us more anxious, more prone to regret, and less likely to act at all. Two decades later, the software industry has done everything possible to prove him right.

The average knowledge worker uses 13 different applications per day and switches between them over 30 times. Each application offers dozens or hundreds of configuration options. Project management tools alone present teams with decisions about workflow stages, custom fields, automation rules, view types, notification settings, permission levels, and template selections before a single task is created.

This is sold as flexibility. It is actually overhead.

Every decision your team makes about how to configure a tool is a decision they are not making about their actual work. Every hour spent debating whether the Kanban board should have 5 columns or 7 is an hour not spent on the project the board is supposed to track. And every “customization” your team adds creates ongoing maintenance that compounds over time.

The alternative is deliberate constraint: tools that make fewer decisions available, so your team can focus on the decisions that matter.

Decision Fatigue Is a Real Problem

Decision fatigue is not a metaphor. It is a well-documented psychological phenomenon. The quality of decisions degrades as the number of decisions increases. A famous study of Israeli parole judges found that favorable rulings dropped from 65% to nearly 0% as the day progressed and decision fatigue accumulated. After a break (and a meal), favorable rulings jumped back to 65%.

Your team experiences the same effect with software decisions:

Morning: “Let me set up this project with the right columns and properties.” Midday: “I will just use the default template, it is close enough.” Afternoon: “I will track this in a spreadsheet.” End of day: “I will just remember it.”

Each trivial configuration decision chips away at the cognitive resources available for meaningful work. And because tool configuration feels productive (you are working on the system!), teams rarely recognize the cost until months of accumulated overhead become undeniable.

The Configuration Spiral

Tool configuration has a compounding property that makes it particularly dangerous:

1. Initial setup: You customize the tool to fit your workflow. Reasonable.
2. First project variation: The second project needs a slightly different setup. You add new status options. Still reasonable.
3. Third month: You have 12 different status options, 8 custom fields, and 3 workflow templates. New team members need a training session just for the tool.
4. Sixth month: Someone proposes simplifying the setup. This requires migrating existing data, which is risky. So you add more complexity instead. The spiral continues.

This pattern repeats in virtually every team that uses a highly configurable tool. The configuration grows monotonically. Nobody removes options because existing work depends on them. The tool becomes harder to use, not easier, over time.

How Constraints Drive Productivity

Eliminating Non-Productive Decisions

When a tool has a fixed workflow, your team never discusses what the workflow should be. That conversation, which can easily consume hours across multiple meetings, simply does not happen. The tool has made the decision for you, based on patterns that work for thousands of teams.

Consider a 5-column Kanban board: Backlog, To Do, In Progress, Test, Complete. There is nothing to debate:

• A new idea goes in Backlog
• Committed work goes in To Do
• Active work goes in In Progress
• Finished work waiting for review goes in Test
• Approved work goes in Complete

Every team member understands the system immediately. There is no training, no documentation, and no ongoing maintenance. The workflow is the tool.

Reducing Onboarding Time

One of the hidden costs of flexible tools is onboarding. When you join a team that uses a highly customized PM setup, you need to learn not just the tool, but the team’s specific implementation of the tool. Which views should you use? What do the custom status labels mean? How do you find your tasks? Why are there three different “done” states?

Constrained tools have identical setups across every team. A new hire who has used the tool before can be productive immediately. Even someone who has never used the tool can learn it in minutes because there are so few concepts to understand.

Research from the Nielsen Norman Group shows that software onboarding time is directly proportional to the number of concepts a user must learn. A tool with 5 fixed columns has 5 concepts. A tool with configurable columns, custom fields, multiple view types, and automation rules has dozens.

Forcing Process Clarity

When you cannot customize a tool’s workflow, you are forced to fit your process into the tool’s framework. This sounds like a limitation, but it is actually a forcing function for clarity.

Many teams’ “complex workflows” are actually unclear processes disguised as sophistication. When a team says they need 9 Kanban columns, what they usually mean is they have not clearly defined what “in progress” and “done” mean. Adding columns is easier than having the hard conversation about process.

A fixed workflow forces that conversation. “This tool has 5 columns. How does our work map to these 5 stages?” The answer often reveals that the team’s process was more complex than it needed to be.

For a detailed exploration of this idea, read our article on why constraints beat customization in Kanban workflows.

Evidence From Successful Constrained Tools

The most beloved software tools in history share a common trait: they do less than their competitors but do it better.

Basecamp

Basecamp famously refused to add features that competitors considered essential: Gantt charts, resource management, time tracking, custom fields. Their argument was that every feature added is a decision imposed on every user. By keeping the tool simple, they kept the cognitive cost low for all users rather than adding value for a few power users at the expense of everyone else.

The result: one of the highest customer satisfaction ratings in the PM tool market and a multi-decade business built on simplicity.

Linear

Linear entered the issue tracking market in 2019 against established players like Jira. Their pitch was radical simplicity: a fixed workflow, keyboard-first interface, and almost no configuration options. In Jira, setting up a new project takes 20-30 minutes of configuration. In Linear, it takes seconds.

Within three years, Linear became the default issue tracker for high-performing engineering teams. Not because it had more features, but because it had fewer decisions.

iA Writer

In the crowded writing app market, iA Writer stands out by removing options. No font choices (one font). No formatting toolbar (Markdown only). No themes (one theme, light and dark). No plugins. Every decision that could be removed was removed, leaving only the writing.

The result: one of the highest-rated writing apps on every platform, used by professional writers who could afford any tool. They choose the constrained one because constraints let them focus on what matters.

What These Tools Share

Each of these tools made an opinionated bet about what their users actually need and removed everything else. They traded flexibility for focus. And in every case, the market rewarded them with loyal users who chose constraint over customization.

The Psychology Behind Constraints and Creativity

There is a well-documented relationship between constraints and creative output. Studies at the University of Amsterdam found that participants given more constrained tasks produced more creative solutions than those given open-ended ones. The constraint forces the brain to work within boundaries, which paradoxically generates more novel thinking than unlimited freedom.

This applies directly to work management:

• Unlimited custom fields lead to over-categorization and metadata maintenance. Fixed fields force you to capture only what matters.
• Unlimited workflow stages lead to tasks getting stuck in ambiguous intermediate states. Fixed stages force clear definitions of progress.
• Unlimited views and dashboards lead to analysis paralysis and dashboard maintenance. A single board view forces you to design your workflow so that the board itself tells the story.

The creative constraint is not about limitation. It is about focus. When the tool limits your options, your attention goes to the work, not the tool.

Applying This to Your Team

Step 1: Audit Your Current Tool Usage

Before changing tools, understand how your team actually uses what you have:

1. How many custom fields exist? How many are regularly updated?
2. How many workflow stages are there? Do tasks move through all of them?
3. How many views or dashboards exist? How many are used weekly?
4. How much time does someone spend maintaining the tool setup each month?

Most teams discover that they use 20-30% of their tool’s configuration. The rest is accumulated cruft that costs maintenance time without adding value.

Step 2: Identify Essential vs. Incidental Complexity

Essential complexity is inherent to your work. If you build software, you need to track bugs, features, and releases. That is essential.

Incidental complexity is added by your tools and processes. If your bug tracking system requires choosing from 15 priority levels, 8 status stages, and 12 custom fields before you can file a bug, most of that is incidental complexity.

The goal is to minimize incidental complexity while preserving essential complexity. Constrained tools do this by default: they support the essential workflows and refuse to add incidental options.

Step 3: Try the Constraint

If you currently use a highly configurable tool, try this experiment:

1. Create a new project with the simplest possible setup: a 5-column board, no custom fields, no automations.
2. Use it for two weeks with a real team.
3. Track every moment someone says “I wish I could…” and write it down.
4. At the end of two weeks, review the list. How many items are genuine needs vs. habits from your old workflow?

Most teams find that 80% of their “requirements” are actually habits. The 20% that remain are your true essential complexity, and they are much easier to address with a focused tool than with a sprawling one.

For more on this philosophy, our article on why simple tools win explores how teams that choose simplicity consistently outperform those chasing features.

The Business Case for Constrained Tools

Beyond productivity, there is a straightforward business case:

Lower Total Cost of Ownership

Constrained tools are typically cheaper because:

• Less engineering effort means lower prices passed to customers
• No enterprise features means no enterprise pricing tiers to subsidize
• Faster onboarding means lower training costs
• No configuration maintenance means lower ongoing administration costs

Faster Time to Value

A configurable tool requires setup before it provides value. A constrained tool provides value immediately. For teams evaluating PM software, this means faster trials, quicker decisions, and earlier ROI.

Sagan Orbit’s feature set embodies this principle. A fixed 5-column Kanban board, real-time sync, and opinionated workflow means your team is productive from minute one, not after a week of configuration.

More Consistent Execution

When every project follows the same workflow, execution quality becomes more predictable. Managers can look at any project board and immediately understand its status because the visual language is identical everywhere. This consistency is impossible to maintain with configurable tools where every project can have a different setup.

The Right Amount of Constraint

To be clear: we are not arguing that all software should be rigid. There is a spectrum between “no configuration” and “infinite configuration,” and the right position depends on your context.

The principle is this: default to constraint and add flexibility only when the cost of the constraint exceeds the cost of the flexibility.

For most teams doing project management, the cost of a 5-column Kanban board (some work does not map perfectly to 5 stages) is dramatically lower than the cost of infinite customization (decision fatigue, onboarding overhead, maintenance burden, inconsistent workflows).

The teams that thrive are the ones that recognize this asymmetry and choose tools that respect their attention rather than competing for it. In a world drowning in options, the most productive choice is often the one that gives you fewer of them.