SaaS Is Dead. Now It’s Shopify’s Turn.

There is a strange reaction whenever somebody suggests that a business could rebuild its ecommerce website outside Shopify. People immediately start talking as though the proposal is to recreate the global banking system, establish a new card network, build an internet server in the office and personally defend it from international cybercriminals. The warnings arrive almost automatically: checkout will break, payments will be insecure, rankings will collapse, integrations will disappear and the entire business will apparently grind to a halt.

It is an extraordinary level of fear surrounding what is, ultimately, a software platform. Shopify is an excellent ecommerce platform. It has enabled millions of companies to start selling online without commissioning an expensive custom system, maintaining their own infrastructure or employing an internal engineering team. For a large number of retailers, Shopify remains an entirely sensible decision.

But that does not mean Shopify owns ecommerce. It does not mean that products, baskets, payments, customer accounts, discount codes, delivery calculations, order histories, stock management and returns can exist only inside Shopify. These are standard commercial functions. Shopify packages them conveniently, but it does not possess some exclusive technological right to provide them.

The distinction matters because the economics of software development are changing rapidly. AI-assisted engineering is reducing the time and cost required to build interfaces, databases, integrations, administration systems and automated workflows. It does not eliminate the need for proper technical judgement, but it does challenge the old assumption that renting a generic system is always cheaper and safer than owning software designed around your business. That assumption deserves to be questioned.

Rent the commodities. Own the differentiation.

The ecommerce industry has confused convenience with inevitability

Shopify’s greatest achievement may not be its software. It may be the belief it has created around the software. For many agencies, developers and ecommerce consultants, Shopify is no longer presented as one possible solution. It is presented as the starting point, the finishing point and the only professionally responsible recommendation in between.

The conversation often begins with, “Which Shopify theme should we use?” rather than, “What does this business actually need?” That is backwards. Technology should follow the commercial and operational requirements of the business. A retailer selling a straightforward catalogue of clothing has very different needs from a manufacturer selling configurable products, a wholesaler operating customer-specific pricing, or a company whose quotations depend on technical calculations and supplier availability.

Yet all of them are frequently pushed towards the same fundamental architecture, followed by an expanding collection of themes, apps, plugins, workarounds and external systems designed to make the platform behave like their actual business. Eventually, the company is not simply paying for Shopify. It is paying for Shopify, a premium theme, a search application, a filtering application, a review application, a subscription application, a loyalty application, a product-options application, an integration platform, additional reporting software and a developer who understands how all of those separate parts have been connected.

The original promise was simplicity. The eventual reality can become a complicated rental stack held together by subscriptions and hope.

The comparison being made is deliberately misleading

The standard defence of Shopify depends on a false comparison. On one side, people place a mature global SaaS platform with years of development, managed infrastructure and a vast ecosystem. On the other, they imagine one junior developer attempting to build an entire ecommerce operation from scratch. Naturally, Shopify wins that comparison. But that is not what a credible modern ecommerce build looks like.

A business rebuilding its digital commerce operation does not need to invent everything itself. It can use established payment infrastructure, managed cloud hosting, specialist authentication, transactional email services, shipping APIs, tax services, fraud tools, search technology and open-source commerce components. The bespoke system sits above and between those services, controlling the experience, data and workflows that are genuinely specific to the company. This is the approach we take when we design bespoke ecommerce websites for clients whose operations have outgrown a template.

Nobody sensible is proposing that a retailer should recreate Visa or Mastercard. Nobody needs to write their own encryption standards, operate a private data centre or build a carrier network before accepting an order. The real choice is not Shopify versus rebuilding the internet. The real choice is between renting one broad platform and composing a more tailored system from reliable infrastructure, established services and bespoke software. That is a completely different discussion.

What about checkout and payment security?

Checkout is usually presented as the decisive argument because it sounds sufficiently frightening to end the conversation. Payments are serious. Security is serious. Compliance is serious. None of that makes Shopify the only legitimate way to sell something online.

A custom ecommerce system can use a managed payment provider to handle sensitive card information and payment authorisation. The website can control the product configuration, basket, customer journey, delivery logic, upsells and post-purchase experience while the payment provider handles the most sensitive part of the transaction. That does not remove every responsibility from the merchant or developer. The surrounding application still needs secure authentication, appropriate permissions, protected credentials, proper logging, reliable backups and disciplined deployment processes.

However, the claim that a custom storefront requires a business to build its own payment network is nonsense. The correct statement is that Shopify manages more of the technical and compliance burden on behalf of the merchant. That is a genuine advantage and should be included in the commercial comparison. It is not proof that other architectures are reckless or impossible.

Security is determined by architecture, implementation and governance. It does not magically appear because the website carries a Shopify checkout.

But a custom website will never scale

Scale is another word frequently used without definition. A retailer processing a few hundred orders each month does not have the same infrastructure requirements as a global brand experiencing hundreds of transactions per second during a product release. Both businesses need reliability, but they do not need identical architecture.

Modern cloud infrastructure allows applications to scale databases, application services, queues, storage and content delivery according to demand. These are established engineering practices, not experimental concepts. The more honest concern is not whether a custom system can scale. It can. The concern is whether it has been designed, tested and monitored properly.

An AI-generated application produced carelessly from a single prompt should not be entrusted with a major retail operation. Nor should a badly configured Shopify store containing conflicting apps, excessive scripts and undocumented integrations. AI does not excuse poor engineering. It accelerates good engineering when used by people who understand architecture, security, testing and deployment. The answer to bad custom software is competent development, not eternal dependence on one platform.

You will destroy the company’s SEO

A badly managed migration can damage organic visibility. That applies when moving from Shopify to a custom platform, from WooCommerce to Shopify, between two custom platforms or even between substantially different versions of the same website. SEO risk is caused by poor migration planning, not by leaving Shopify.

A responsible rebuild should begin with a complete record of the existing website: URLs, rankings, metadata, canonical references, internal links, structured data, image locations, indexation rules and backlinks. Valuable URLs should be retained wherever possible. Where changes are necessary, exact permanent redirects should be created rather than sending everything to the homepage. The new site should be crawled and tested before launch, followed by continued monitoring after migration. Changes in visibility, indexing and crawl behaviour should be identified and acted upon quickly.

There is real work involved, but none of it is mysterious. In fact, a bespoke system can provide exceptionally strong technical SEO when it is built around performance, clean rendering, structured data, controlled navigation and carefully designed page templates. Shopify can perform very well in search, but it does not own search-engine compatibility either.

“SEO migration needs planning” is a valid warning. “You must remain on Shopify forever or lose all your rankings” is fearmongering.

What about all the apps?

The app argument sounds convincing until somebody audits what those apps are actually doing. Many ecommerce companies have accumulated applications gradually over several years. Each solved a small problem at the time, but the full stack may now contain overlapping functionality, duplicated customer data, multiple tracking scripts and separate subscription costs.

One application handles reviews. Another handles loyalty. Another handles product recommendations. Another handles filters. Another handles subscriptions. Another connects customer information to the CRM. Another exists because two of the previous applications cannot communicate directly. This is not always an ecosystem advantage. Sometimes it is simply fragmentation presented as flexibility.

A custom system does not need to reproduce every application in the marketplace. It needs to provide the capabilities that the business actually uses. Some should be built directly into the platform. Some should remain external specialist services. Others may be unnecessary once the underlying workflow has been redesigned properly.

Losing fifteen applications is not a disadvantage when ten of them existed only to compensate for the limitations created by the others. The real question is whether the resulting system performs the required functions more reliably, economically and efficiently. The number of logos appearing on an integrations page is not itself a measure of business value.

Custom software costs more

Custom software can require a larger initial investment. That is obvious. What is less obvious is how often the comparison stops there. Businesses compare the price of a bespoke build with Shopify’s headline monthly subscription while ignoring premium themes, application subscriptions, transaction charges, integration platforms, development retainers, specialist reporting tools and internal staff time.

They also ignore the cost of operational friction. How many hours are spent exporting data into spreadsheets because the systems do not communicate properly? How many orders require manual intervention? How many staff members repeat administrative tasks that could be automated? How many commercial ideas are abandoned because the platform cannot support them without another application or complex workaround? Those costs rarely appear on the software invoice, but they are still costs.

A proper comparison should examine the total cost of ownership over several years. That includes implementation, maintenance, hosting, security and technical support for a custom system. It should also include every subscription, workaround, manual process and commercial limitation associated with the existing SaaS stack.

Sometimes Shopify will remain decisively cheaper. Sometimes the business will discover that it is spending a substantial amount each year to rent a system that still does not reflect how the company operates. The point is not that bespoke software is always cheaper. The point is that SaaS is not automatically cheaper once the whole business is included in the calculation.

What AI has actually changed

AI has not made serious software development free, instant or riskless. Anybody claiming that an entire mission-critical ecommerce operation can be generated from one casual prompt is selling fantasy. What AI has changed is the amount of human time required to perform large sections of development work.

Coding agents can help create database structures, administration screens, API integrations, validation rules, migration scripts, automated tests, technical documentation and frontend components. They can investigate errors, refactor repetitive code and accelerate iteration. Work that once required a development team to manually write thousands of routine lines can now be completed far more quickly. Skilled engineers can therefore spend more time on architecture, security, user experience and the difficult commercial rules that make the system valuable.

This changes the build-versus-buy calculation. Generic SaaS became dominant partly because custom software was historically slow and expensive. Businesses accepted imperfect workflows because building an alternative could not be justified. AI is steadily reducing that economic barrier. It does not mean every company should become a software company. It means companies can become more selective about which parts of their operation they rent and which parts they own.

The intelligent future is not “build everything”

There is no virtue in rebuilding a commodity service that already works perfectly well. Businesses should continue using specialist providers for functions where scale, compliance and infrastructure matter more than differentiation. Payments, cloud hosting, email delivery, identity verification, messaging and fraud prevention are obvious examples.

The commercial advantage comes from owning the layers that shape the business. That could include the customer experience, product-discovery logic, recommendation system, trade-pricing model, quotation workflow, account portal, supplier integrations, order-processing rules, internal administration and AI automation.

This is not the complete death of SaaS. It is the death of default SaaS: the assumption that a company should rent its entire operating model simply because renting used to be cheaper than building. The emerging model is far more selective. Rent the commodities. Own the differentiation.

Shopify is still the correct decision for many businesses

Criticising Shopify absolutism does not require pretending Shopify has no value. A business selling a conventional range of products through a straightforward purchasing journey may gain very little from replacing it. Shopify can provide a fast launch, predictable infrastructure, familiar administration and an enormous ecosystem without the company assuming substantial technical responsibility. Rebuilding a successful store purely to make an ideological point would be ridiculous.

The case for reconsidering Shopify becomes stronger when the business has outgrown generic workflows. Complex product configuration, customer-specific pricing, specialist quotations, unusual fulfilment routes, fragmented reporting and extensive manual processing can all indicate that the software no longer fits the company. The warning sign is usually not the monthly platform fee. It is the growing effort required to make the platform imitate the business.

At that stage, the organisation should not ask, “Can we survive without Shopify?” It should ask, “What would we build today if we were designing our commerce operation around the way this company actually works?” That may result in remaining on Shopify. It may mean using Shopify as a headless backend with a bespoke customer experience. It may involve replacing only certain functions, or it may justify moving to a completely different architecture.

A serious technology strategy permits all of those answers. A cult permits only one.

Shopify is a platform, not a religion

Shopify deserves respect for transforming ecommerce. It made sophisticated online retail capabilities accessible to businesses that could never have afforded to build them independently. But success does not create ownership of an entire category.

Shopify does not own checkout. It does not own product catalogues, customer accounts, stock control, subscriptions, reviews, delivery rules or online payments. It combines those capabilities exceptionally well and rents access to them through a managed platform. That may be the best option for your company. It may not.

The only responsible approach is to compare the available architectures honestly: cost, risk, performance, flexibility, maintenance, commercial opportunity and operational fit. Use Shopify because it wins that comparison, not because an agency is frightened of working outside its ecosystem. Do not remain trapped because somebody mentioned PCI compliance in a sufficiently serious voice. Do not confuse the convenience of an application marketplace with proof that every function must remain permanently rented.

The debate was never about whether ecommerce could exist outside Shopify. Of course it can. The real debate was whether building an alternative could be commercially justified. AI is changing the answer to that question, and the ecommerce industry needs to stop pretending otherwise. If you want that comparison run properly for your own business, our team can take you through it.