Every technology leader has been in the meeting. A board member, or a CFO, or a founder returning from a conference says some version of: “We need our own software.” The implication is that building something in-house will create competitive advantage — a moat, something proprietary, something rivals cannot just go out and buy.
Sometimes that is true. Often it is not. A large fraction of custom software built in the name of competitive advantage turns out, two years later, to be commodity work dressed up in bespoke clothing. The company spent a year and a budget building something that a competitor with similar engineering talent could reproduce in six months if they ever decided it mattered.
The difference between software that creates a moat and software that is commodity is not about technology stack, team size, or build quality. It is about structural properties — what the software does, what data it touches, and how it compounds. This piece is about how to tell the difference before you commit the budget.
What actually creates a moat
Four properties come up consistently when we look at software that has held up as a competitive advantage over years, not quarters.
Proprietary data flows
Software that touches data that only your business has — specific customer behavior patterns, internal operational metrics, supply chain signals, pricing responses from your specific market — gets better as that data accumulates. A competitor cannot clone it by reading the code, because the code is only half the system. The other half is the data that has been collected by running it for years.
This is the single most durable form of software moat. It is also the easiest to miss, because the code on day one looks identical to a commodity equivalent. The differentiation only shows up over time, as the data layer gains history and the algorithms tune themselves to signals nobody else has.
Operational process encoded in software
Every business has operational processes that are specific to how it runs — how it onboards customers, how it routes support tickets, how it approves quotes, how it triages incidents. Most companies run these processes on a mix of spreadsheets, Slack, and tribal knowledge. A small number encode them into software.
When the process is encoded, two things happen. It scales past the point where tribal knowledge breaks down, and it becomes tunable — small improvements in the process compound because every new employee and every new customer benefits from the current version, not a worse version that got passed on verbally. A competitor can copy the output of that process, but they cannot copy the years of tuning that produced it.
Integrations with proprietary systems
When a piece of software integrates with common services — Salesforce, Stripe, HubSpot — it is valuable but not defensible, because any competitor can build the same integration. When it integrates with systems that are themselves proprietary — your own operational database, your own pricing engine, your own customer data platform — the integration becomes inseparable from the rest of the business.
This is why the question “what does this software talk to?” is often more important than “what does this software do?” Software that only speaks to commodity services is commodity by proxy. Software woven into proprietary infrastructure inherits that infrastructure’s defensibility.
Compounding learning loops
The strongest moat is a learning loop — a system where usage generates signal, signal improves the system, improved system drives more usage. Recommendation engines at scale have this property. Fraud detection at scale has it. Well-instrumented internal pricing tools have it.
The hard part is that learning loops are difficult to design and require volume to work. A small-scale recommendation engine that does not have enough users to generate meaningful signal is just a worse version of an off-the-shelf one. The loop becomes a moat only once the system has been running long enough to produce signal a competitor cannot match.
What does not create a moat
Three categories of custom software consistently fail to produce durable advantage, regardless of budget or build quality.
Generic user interfaces. A slicker internal admin panel, a better-looking dashboard, a more modern CRM skin — these feel differentiated when they ship, but a competitor can either build their own version or buy a product that does ninety percent of the same thing. UI is important for adoption and productivity, but it is almost never the source of the moat.
Well-solved algorithms. Shortest-path routing, standard machine learning classification, generic recommender systems, optimization problems with textbook solutions — these are solved problems. Implementing them in-house does not produce advantage over a competitor who uses a well-tuned library or a commercial API. The signal of commodity here is that there is a conference paper from 2015 that describes roughly what you are building.
Standard integrations with common services. If the functionality is “connect our email tool to our CRM” or “sync our billing to our accounting software,” the integration is commodity. Build it if it is cheaper than buying it, but do not confuse building it with creating a strategic asset.
The six-month test
The single most useful question we ask clients who are about to commit a large budget to custom software: if a well-resourced competitor decided tomorrow that they needed this exact capability, could they have a working equivalent in six months?
If the answer is yes, the software is commodity. That is not a disqualification — plenty of commodity software is still worth building, either because the build cost is lower than the SaaS equivalent, or because integration with the rest of your stack demands it, or because the capability matters strategically even if it is not proprietary. Build it, but plan its lifecycle and budget as a cost center, not as a strategic asset.
If the answer is no — if the competitor genuinely could not reproduce the capability in six months because the capability depends on data, integrations, or compounding loops that take years to build — then the software is a strategic asset. It deserves a different budget posture, different staffing, and different executive attention. Under-investing in a real moat because the line item “looks expensive” is one of the most common and most expensive mistakes in corporate technology planning.
What to do with the answer
Once a project is classified honestly, the planning shape changes.
Commodity software should be built lean. Buy as much off-the-shelf as possible, keep the custom surface small, accept that the team working on it is not earning a premium skill-set by doing so. Optimize for maintenance cost and graceful replacement.
Moat software should be built with different priorities. Data retention, instrumentation, integration depth, and the slow-burn work of building compounding loops — all of these matter more than shipping speed in year one, because the asset you are building only becomes valuable over three to five years. Staffing should match that horizon. So should patience.
The most expensive mistake we see is the inversion: commodity work funded as if it were a moat (over-investment in something that will be replaceable in two years), or moat work funded as if it were commodity (under-investment in something that needed durable attention to pay off). Both mistakes come from the same failure — not asking the six-month question before writing the first line of code.
Custom software is not automatically strategic. The small subset that is strategic has identifiable properties. Checking which category a project falls into, before the budget is committed, is the single highest-leverage decision a technology leader makes in a given year.
Top comments (0)