Most Software Is Workflow Design A developer argues that most software is fundamentally workflow design, not feature design, and that users care more about completing tasks than about the underlying technology. The developer explains that successful products like Instagram, Uber, and GitHub succeeded not because of their features but because they optimized core workflows like "Capture → Filter → Share" or "Request → Ride → Pay." The developer concludes that product opportunities lie in repairing broken workflows and reducing friction, not in adding more features. One of the biggest mistakes I made early in my career was believing that software products were primarily collections of features. This application has authentication. That application has dashboards. This one has AI. That one has collaboration. The assumption was simple: Better technology creates better software. Over time, I realized something uncomfortable. Most users don't care about the technology. Most users barely care about the features. What they care about is getting something done. And that's when I started seeing software differently. Not as collections of features. But as collections of workflows. Nobody wakes up in the morning thinking: I need a note-taking application. They're thinking: I need to remember something. Nobody wants a project management platform. They want a project to move forward. Nobody wants a CRM. They want customers. Nobody wants an AI assistant. They want answers. The software is simply a vehicle. The workflow is the destination. When software teams discuss products internally, conversations often sound like: But users rarely experience software as a list of features. They experience it as a sequence of actions. Consider a note-taking application. A product team may describe it as: A user experiences it as: Capture ↓ Organize ↓ Find Later The workflow is what matters. The features only exist to support it. Once I started thinking in workflows, something else became obvious. Many products compete on features. The best products compete on friction. The question stopped being: What can we add? And became: What can we remove? Every extra click. Every extra form. Every unnecessary screen. Every context switch. Every manual step. All of it accumulates. Users don't usually describe this as friction. They describe it as: This feels annoying. Or: This feels complicated. Or: This feels slow. What they're actually describing is workflow debt. This is why some products appear deceptively basic. Instagram wasn't successful because it had hundreds of features. Its core workflow was: Capture → Filter → Share Uber wasn't successful because of map technology. Its core workflow was: Request → Ride → Pay GitHub wasn't successful because it invented version control. Its core workflow was: Push → Review → Merge The technology matters. But users remember the workflow. This realization changed how I evaluate software ideas. I used to look for missing technologies. Now I look for broken workflows. When people complain: I have to copy this from one system into another. Or: I keep losing track of this information. Or: I spend an hour doing the same thing every week. Those aren't feature requests. Those are workflow failures. And workflow failures are often where product opportunities hide. Many successful products are not technological breakthroughs. They're workflow repairs. This connects directly to something I wrote about in Open Source Is How Small Teams Build Big Things . Most primitives already exist. Databases exist. Authentication exists. Search exists. Payments exist. AI exists. Cloud infrastructure exists. If those layers already exist, then the question becomes: What should we build? Increasingly, the answer is: Better workflows. The opportunity is rarely another database. The opportunity is usually helping someone move from: Problem ↓ Solution with less friction than before. The first time I understood this, I stopped looking at software as a collection of features. I started looking at it as a sequence of actions. A workflow. Users don't buy technology. They buy outcomes. The technology matters because it enables the workflow. Not the other way around. The best software is often not the software with the most features. It's the software that gets out of the way. Because in the end, most software is not feature design. It's workflow design. And the products that win are usually the ones that make progress feel inevitable.