When Your Customer Becomes Your Competitor: Your Customer Found a Shortcut to the Software Factory

Part four of how 90% of edtech disappears. Software companies spent twenty years convincing customers not to build. Artificial intelligence is changing the distance between wanting software and making it.

I spent part of my summer holiday walking through one of the most beautiful commercial failures ever built. Park Güell is now prime Barcelona: Gaudí, mosaics, extraordinary views and a reliable supply of tourists photographing themselves beside a ceramic lizard. But it was not intended to be a public park. Eusebi Güell and Antoni Gaudí planned it as an exclusive residential estate for wealthy families, with sixty homes set above the city. Only two were ever built.

Our official guide explained that one of the problems was surprisingly practical. The people wealthy enough to live there still needed to reach their factories and the port, which meant travelling by horse-drawn carriage along an inconvenient route, with the journey affected by weather and road conditions. The estate may have offered cleaner air and beautiful views, but it was simply too difficult to get from the house to the place where the money was made.

There were other obstacles. The plots came with restrictive conditions, public transport was inadequate, and the exclusivity that made the development attractive also helped make it commercially unviable. Construction stopped in 1914. Güell's heirs eventually sold the land to the city, and it opened as a public park in 1926.

Today, the location no longer feels remote. Barcelona grew around it, while roads, buses, taxis and the metro changed the practical meaning of distance. Park Güell was not necessarily built in the wrong place. It was built before the road arrived.

I have spent eleven years in SaaS in the edtech industry telling customers not to build software they could buy. Ninety-nine percent of the time, this was genuinely excellent advice. Building your own learning platform meant developers, designers, product managers, infrastructure, integrations, security, maintenance and enough budget to survive the point eighteen months later when somebody discovered that the internal system everyone had worked so hard on was worse than the product they could have bought in the first place.

The software factory existed, but for most companies reaching it was slow, difficult and prohibitively expensive. So we taught companies to rent. Do not build your own learning management system. Buy one. Do not build an authoring tool. Subscribe to one. Do not build an employee academy or assessment platform. Find a specialist company that has already solved the problem. I built a successful, venture-backed edtech company on that logic.

Today, I also own an AI studio, and I increasingly give customers what appears to be the opposite advice: before buying another software product, find out what it would cost to build the functionality you actually need. That does not necessarily mean building it in-house. A company can ask one of its own developers, an AI-assisted contractor or a studio like mine. It does not need to become a software company or own the factory. It simply needs affordable access to one.

I know how disruptive that advice is because I have followed it. I have previously written about my personal newsletter costing approximately 10,000 Danish kroner every month to send emails to around 36,000 people through Mailchimp. I used Lovable to build my own sending tool and connected it to SendGrid. Building it cost less than $30, operating it costs approximately $25 to $30 a month, and the part I did not mention previously is that it took less than a day.

The tool is still not as good as Mailchimp and lacks some of its integrations, templates and edge cases. But I don't need them. It performs the fraction of Mailchimp's functionality I need, replacing a subscription costing roughly 10,000 Danish kroner ($1,520) a month, or around $18,000 a year, with infrastructure costing approximately $25 to $30 a month, or $300 to $360 a year. Mailchimp did not lose me to another email platform. It lost me to myself.

AI is paving the road between the company office and the software factory, which is why I increasingly catch myself asking customers a question I would once have considered terrible advice: Why are you buying this at all?

The purchase used to exist before competition began

Most software companies think about competition after the customer has decided to buy. The customer needs a learning platform, so it compares learning platforms. It needs a CRM, so it compares CRMs. It needs a newsletter system, so Mailchimp competes with HubSpot, Klaviyo and whatever else appears in the shortlist. The category has already won; the only remaining question is which vendor receives the money.

That assumption sits underneath an enormous amount of SaaS strategy. Marketing generates demand for the category, sales converts that demand into a named account, product adds enough features to beat the nearest competitor, and customer success protects the renewal. Even churn presupposes that a customer existed first.

Take a company with 10,000 employees and a terrible learning setup. Ten years ago, HR might have invited five LMS vendors to demonstrate their products and selected one. Now ask what the organisation actually needs. It already has an identity system, policies, videos and internal knowledge. AI can turn that material into exercises. What remains is storing completion, reporting to managers, documenting compliance and connecting the pieces.

Historically, even that narrow workflow required enough engineering effort that buying the platform remained rational. Now the company can describe the workflow, connect its existing systems and have an internal product person, an AI-assisted developer or an external studio build the part it needs. It can still buy if the commercial product is better, but buying is no longer the automatic starting point. The company does not have to recreate the LMS. It has to recreate the reason it bought the LMS.

The most dangerous prospect is therefore not the customer who leaves at renewal. At least that customer entered the CRM, signed a contract and generated a reason for leaving that somebody can analyse. The more unsettling prospect is the company that never becomes a prospect: it never visits the pricing page, appears in the pipeline, requests a demonstration or gives procurement a shortlist. Somebody asks whether this needs to be another subscription, discovers that it does not, and takes the new road to the software factory instead. From the SaaS provider's point of view, no deal was lost because no deal ever existed.

You only have to beat the invoice

For most of the SaaS era, vendors could bundle hundreds of capabilities because reproducing the subset a customer used was expensive enough to make renting the whole product sensible. That threshold is falling. The customer does not have to build something better, recreate the vendor's entire platform or cover every edge case. It only has to solve its own problem well enough to beat the invoice.

Take a deliberately simple learning-platform price of $12 per user per month, with no implementation fee, base fee or volume discount. A company with 10,000 users pays $1.44 million a year. At 50,000 users, the annual cost is $7.2 million; at 200,000, it is $28.8 million. This is not a claim that a competent procurement team would accept that flat rate at 200,000 seats. Even after a 75 percent volume discount, however, the annual subscription would still be $7.2 million. The inputs change the point at which building becomes rational; they do not remove the difference between a cost that scales per seat and one that may not.

Of course, a customer of that size would negotiate. Enterprise contracts are rarely that clean, and a serious learning platform does far more than host a few pages and record completion. It may provide hundreds of integrations, sophisticated permissions, accessibility, audit trails, content standards, localization, support, security documentation and contractual accountability. A credible comparison has to include those things.

But that is precisely the point: the customer does not have to reproduce everything the vendor has built. Imagine, purely as a model, that a tailored learning platform costs $1 million to build and another $2 per user per month to operate, secure and maintain. For 10,000 users, the first year would cost approximately $1.24 million, already below the $1.44 million subscription. For 50,000 users, it would cost approximately $2.2 million rather than $7.2 million; for 200,000, approximately $5.8 million rather than $28.8 million.

Those are illustrative numbers, not a universal business case for building. The calculation can reverse quickly when a company needs global compliance, dozens of deep integrations, round-the-clock support, complex migrations or a supplier willing to assume real operational liability. Custom software creates maintenance, security and technical-debt risks that a spreadsheet can conceal with impressive efficiency. Many enterprise platforms also price by active users, usage or negotiated bands rather than applying a flat public rate.

Yet even after generous caveats, the direction is difficult to ignore. Per-user SaaS pricing rises with the size of the customer, while the cost of building the relevant functionality does not necessarily rise at anything close to the same rate. Larger customers mean more seats and expansion revenue, but they may also have the strongest financial reason to question whether the vendor should exist in the workflow.

Nobody will spend six months recreating a product that costs €200 a month. A small school should probably not maintain a homemade student-information system, and a regulated organization should be careful with sensitive data. A company paying €250,000 a year has a different calculation. Your most attractive customer may also have the strongest incentive never to become your customer.

The old question was whether a custom build could equal the product. The new question is whether it can beat the invoice, which is a much lower bar.

The rent moves down the stack

This is not the end of renting; it is a change in what the customer rents. My Mailchimp replacement still uses SendGrid to deliver email. I did not build global email infrastructure, negotiate directly with every internet provider or create my own system for protecting sender reputation. I replaced an application subscription with a thinner collection of infrastructure and a small piece of software I control.

A company building its own learning environment will probably do the same. It may pay OpenAI, Anthropic or Google for model access, use AWS or Azure for infrastructure, and retain an external team to maintain the system. The software factory has not become free. It still needs electricity, machinery, raw materials and somebody who understands what is being made, but the rent moves down the stack.

Instead of paying a large recurring fee for a finished application containing 400 functions, the customer can pay smaller recurring fees for infrastructure and own the seven functions it actually uses. It can commission a one-time build without creating an in-house software department, just as a fashion company can commission production without owning every machine that makes its clothes. The choice is no longer simply build or buy. It is buy, build, assemble or commission, and AI is reducing the cost of the final three.

SaaS originally won because one specialist company could build a product once and distribute it cheaply to thousands of customers. That advantage does not disappear, but the vendor must recover the cost of a general product, its sales organisation, customer-success team, investors and feature roadmap across its customer base. A custom system only has to serve one company. For years, that was also its weakness because one customer could not justify the journey to the factory. Now the road is shorter.

Edtech is particularly exposed because two costs are falling at once. Generative AI reduces the cost of producing and coordinating learning: a manager can ask an assistant to explain a policy, generate an exercise, adapt material to a role, translate it and test understanding without opening a course catalogue. At the same time, AI-assisted development reduces the cost of building the system that assigns, tracks and documents that learning. One force attacks usage; the other attacks the purchase.

An edtech company can therefore be squeezed even while demand for learning grows. Organizations will still train employees, distribute knowledge, document compliance and develop skills, and may do more of all four. But increasing demand for the outcome does not guarantee increasing demand for the existing product category. People did not stop watching films when DVD rental collapsed, or listening to music when buying CDs became absurd. The activity survived; the product, distribution and payment model around it changed.

Learning is not disappearing. The assumption that it must be packaged inside a separately purchased learning platform is becoming less secure.

Maybe your moat was the distance

The obvious response is that vibe-coded software is unreliable, insecure and easy to demonstrate but difficult to operate. Often, that is true. There is an enormous distance between making a functioning prototype and running a business-critical system, which needs architecture, tests, permissions, monitoring, backups, data governance, accessibility, security reviews and somebody accountable when it breaks. AI can produce bad code very quickly and allow a company to create a fragile internal dependency that nobody understands six months later.

But weak execution does not rescue a weak commercial model; it merely means customers need a competent route to building. The early internet was full of terrible websites, and that did not protect newspaper classifieds, travel agents or high-street retailers. Poor first attempts can coexist with a structural change in cost and access.

The more useful question is which part of a SaaS company's defensibility came from genuinely difficult work and which part came from the customer being too far from the factory. Deep integrations, proprietary data, regulatory approval, contractual liability, trusted credentials, distribution, community and demonstrated outcomes can be formidable. A supplier that understands a complicated domain and accepts responsibility for running it can be worth far more than its features.

Having many features is not necessarily a moat. A beautiful interface is less durable when interfaces can be generated, a decade of accumulated code matters less when the customer needs only a narrow workflow, and switching costs offer limited protection against a company that has not bought anything yet. Many SaaS businesses were safe partly because recreating even an inferior version required a team the customer did not possess and a budget it could not justify.

AI does not make every product easy, safe or sensible to rebuild. It makes enough products cheap enough to question. A harsher definition of defensibility follows: a moat is not what makes your product difficult to recreate. It is what makes the customer's purchase difficult to eliminate.

For twenty years, software positioning mostly answered why us instead of them? The customer had already accepted that it needed to buy something, and the vendor's job was to win the comparison. Increasingly, software companies will have to answer a more dangerous question: why buy at all?

That is a much harder argument because the company is not objecting to your price, requesting another feature or threatening to select your competitor. It may never enter your market in the first place. No opportunity appears in the CRM, no procurement process begins and no lost-deal analysis explains what happened. The need is simply resolved through software the company owns rather than software it rents.

The functionality remains. Employees still learn, managers still need information and compliance still needs evidence. What disappears is the transaction in the middle.

Park Güell was not built in the wrong place. It was built before infrastructure changed what that place meant. SaaS was built for a world in which the road to the software factory was too long and expensive for most companies to travel, so it turned the factory's output into something they could rent. That was genuinely good advice until the road changed.

The software factory has not disappeared, and neither has the need for what it makes. But companies can increasingly reach it without passing through the SaaS provider that expected to sell them a subscription, meaning that your competitor is not another product. It is the disappearance of the purchase.