The moat has moved

Software used to be expensive to build, and that cost forced a kind of discipline.

Founders had to choose carefully what to build and who for. Teams that could ship faster and maintain quality over time built real advantages. The difficulty of the work was part of what made it valuable. That cost is collapsing, and most product teams haven’t figured out what that means for them yet.

Code is now a commodity

When everyone has access to the same models, and those models can produce working software quickly and cheaply, the code itself stops being a moat. A reasonably skilled person can now build what used to take a team of engineers months to ship.

A competitor can reach feature parity in days. The thing that used to protect a business, the sheer effort required to build it, is mostly gone.

Think of it like oil. If every property owner had a well that was cheap to operate, the price of oil would fall toward the price of water. The resource is abundant, the extraction is easy, and the margin disappears. Software features are heading in the same direction.

So where does the moat go?

---

The new constraint is data

A SaaS product has always had two components: the features and the data those features operate on. For a long time the constraint was features. Who could build the most capable, most polished, most reliable product? That was the competition.

When development speed gets fast enough and feature cost gets low enough, you can no longer win on what you can build. The competition shifts to whether you have access to the right data about the business or domain you serve.

A payroll tool is not valuable because of its UI or calculation logic. Both can be replicated quickly. It’s valuable because it holds years of salary history, tax records, and employee data that no competitor can walk in and duplicate.

An e-commerce platform is not valuable because of its product listing interface. It’s valuable because of the behavioral data, supplier relationships, and purchase history accumulated over time. The features are just a rendering layer on top of that.

Netflix understood this early. Their recommendation engine was never really about the algorithm. It was about the volume and specificity of viewing behavior that no competitor could replicate.

Shopify’s power is not in the checkout flow but in the merchant and transaction data that makes every new feature more accurate and useful than what any new entrant can offer on day one.

The return of bespoke software (in the right context)

For most of software’s history, the high cost of development pushed everything toward standardization. We reused frameworks and shared libraries because custom code was expensive. We adopted cloud services and common APIs because building your own infrastructure rarely made economic sense.

Those solutions still work, but they carry costs that are easy to underweight: vendor lock-in, subscription fees for things you barely use, supply chain vulnerabilities, outages you can’t control. The assumption was always that the alternative, building something specific, was too expensive to justify.

That assumption is changing, particularly for business software.

Consumer apps are a different story. A well-designed consumer product reflects years of collective user feedback, UX iteration, and design judgment that no individual could produce on their own. Most people don’t know exactly what they want until they use something well-crafted and realize it fits. That process has real value and it doesn’t go away.

But one layer up, at the organizational level, something interesting is happening. A logistics company running dispatch operations on generic project management software is always going to be fighting against 20% of their workflow that doesn’t fit.

A clinic using an off-the-shelf scheduling tool built for nobody in particular is always going to be working around it.

The specificity of how businesses actually operate has always been real. What’s changed is that matching software to that specificity is now economically viable.

The person who translates a business need into the right software is not the business owner. It’s a product builder who understands both the domain and the tools. That gap between business context and working software is where the service value lives now.

The platform that holds everything

If features are commodity and purpose-built tools become routine, something has to be the durable layer underneath. Something has to hold the data together.

The pattern emerging in enterprise software points toward a central data backbone, something like Salesforce or a modern ERP, where all the information about a business lives and where purpose-built tools connect as needed.

In this model an app like Slack or Jira is not a standalone product but a plugin reading from and writing to a shared layer. A workflow tool built for one team’s specific process connects to the same source of truth rather than becoming another silo.

This is also what makes AI agents actually useful. Conversational agents and automated workflows are only as good as the data they can reach. When business data is scattered across ten disconnected systems, agents are limited. When it lives in a coherent, queryable backbone, those same agents can do real work.

For founders building in this space, the question worth asking is whether your product is becoming the backbone or the plugin. Backbones accumulate data and grow more valuable over time. Plugins get swapped.

---

What this means for building products

Most of this comes down to a few practical shifts in how product decisions get made.

Compete on data access, not feature depth. Ask what data only you can accumulate in your domain and build around acquiring it early, before features become the priority.

Design for the workflow moment, not the application. The unit of product design is shifting from the app to the specific task someone needs to complete. People will increasingly use purpose-built tools for specific things rather than general platforms for everything. The interface follows from the task, not the other way around.

Treat your integration layer as a product decision. If the future is a central data backbone with tools plugging in on top, how cleanly your product connects to that backbone matters. Companies that make their data easy to work with become the backbone. Companies that silo it get replaced.

Stop defending features. If a competitor can ship your feature in a week, it was never your moat. The answer is not to build more features faster but to identify what they actually cannot copy: domain knowledge, accumulated data, relationships, a genuine understanding of the specific problem.

The role of judgment

None of this makes building easier. If anything it makes the hard parts harder.

When execution speed stops being a differentiator, the premium moves to judgment: identifying the right problem, understanding a domain deeply enough to know what data matters, and designing something that fits how people actually work rather than how you imagined they would. Those things are harder to replicate than a codebase.

The role of a product designer or a product-oriented founder becomes more valuable in this environment, not less. The question was never really whether something could be built. It was whether it should be built and whether it fits the way people actually operate. That question gets harder to answer correctly as the cost of building the wrong thing gets lower.

---

The companies that will be hard to compete with in five years are probably not the ones shipping the most sophisticated AI features right now. They’re the ones accumulating domain-specific data, building coherent data backbones, and designing for specific workflow moments rather than broad use cases. The moat has moved, and the builders who figure that out early will have a real head start on those still competing on code.

Thanks for reading.

— Bora @ Nirmata