A checkbox should not need a monthly business model. Yet on a Shopify store, a small request can become another app, another script, another subscription and another dependency to remember. That arrangement made sense when building even a modest feature required scarce time and specialist skill. The economics are changing.

The title is deliberately blunt. The Shopify app is not disappearing. Apps that do difficult work can be useful for years. What is dying is the assumption that every useful storefront feature should be rented from a separate company.

Code has become easier to write, test and revise. AI agents can help translate a merchant’s description into a first implementation, explain existing theme code, find defects and exercise the customer journey. A feature that once demanded a specialised product may now be a focused piece of work inside the store itself.

That shift changes the question. Instead of asking, “Which app adds this button?” a merchant can ask, “What must happen for my customer and my team, and what is the smallest reliable way to make it happen?”

The app store solved a real problem

There was a good reason to install apps. A merchant could not wait weeks for a developer every time a product needed a new choice or a page needed another block. An app packaged working software, support and updates behind an install button. It let a small team borrow capabilities it could not afford to build from scratch.

That bargain also created a quiet accumulation. One app adds a selector; another adds a recommendation; a third changes the cart. Each seems small by itself. Over time, the storefront depends on a collection of vendors, each with its own price, configuration, scripts, customer experience and idea of how the store should behave.

Recurring payment is reasonable when a provider keeps doing valuable work. It deserves a closer look when most of the value is a bit of presentation and conditional logic that rarely changes. At that point, the merchant may be renting a general-purpose control panel to operate one switch.

One product, one extra choice

Imagine a maker selling a notebook. Customers can add a short name on the cover. A product-options app might offer a text box, a character limit, conditional instructions and a field visible to staff on the order. For a general tool used across a changing catalogue, that package can earn its place.

But if this is one product with one engraving field, the store can present the choice directly on the product page. The field can explain the limit, show the customer’s text and carry it into the cart and order. Shopify themes support line-item properties for collecting extra information such as monograms or engraving. The product form can submit that information alongside the selected variant. Shopify’s product-form documentation.

This example is purposefully modest. The field is not a new pricing system. A personalisation request that changes the price needs a real priced item, variant or supported pricing mechanism, with the total shown correctly before purchase. A field that merely stores text must not pretend to charge for the work.

The build still needs care. What happens when the customer leaves the field blank? How does the value appear in the cart, confirmation and fulfilment workflow? What if the customer buys two of the same product with different text? A successful design answers those questions before the feature goes live. The work may be smaller than installing a large app, but it is real work.

For choices that map to products, variants, colours, sizes or inventory, Shopify already has product structures. For extra instructions, line-item properties may fit. For one catalogue-wide product-options platform, an app may remain the sensible answer. The deciding factor is the shape of the need, not the number of toggles in an app listing.

An upsell is a choice, not a subscription

Consider a customer choosing a coffee grinder. The store wants to show filters that fit it. A small related-products section on the product page can make that offer. Shopify provides a product recommendations API, and its Search & Discovery tools let merchants choose complementary products. The theme decides where and how to display them. Shopify’s complementary-product guide and recommendation settings.

A narrow offer does not necessarily need an elaborate recommendation engine. If every grinder pairs with two known filter packs, the store can show those two choices, their prices and a clear add button. The cart should then display both products accurately. If an add fails or stock has changed, the customer should see a useful message rather than a false success.

The logic may be three rules: show these accessories on this product, hide an item that is unavailable, and add the selected items. That can be enough. A sophisticated upsell app still has a case when recommendations adapt across a large catalogue, experiments are central to the marketing team, or reporting ties performance to the offer. A fixed recommendation may call for a fixed feature.

Bundles, bars and other small jobs

A bundle sounds complicated until we ask which kind we mean. A shop might sell a fixed kit containing a lamp and a spare bulb. Inventory needs to stay accurate for each part, orders need useful line items, and discounts must be right. Shopify’s own Bundles app handles fixed bundles and multipacks on all Shopify plans; it is free. That is a revealing detail: sometimes the best replacement for a paid app is a capable tool the platform already supplies. Shopify Bundles and its limits.

Another store may simply want a “Complete the set” row beneath selected products, or a free-shipping bar that reflects a threshold. Those can be small theme features reading product and cart data. A progress bar that misstates the threshold or ignores a discount is worse than no bar, so the rules need testing against actual cart states.

The same pattern applies to tabs for delivery information, product-specific FAQs, size guidance, a store notice or a WhatsApp contact link. Shopify metafields and metaobjects let a team keep structured content in the admin and connect it to a theme, while custom theme code can display the content in the right place. Shopify’s metafield guide.

This matters because a merchant should not have to choose between editing every answer in code and paying for a large app. The code can define the display; the merchant can keep the words and product-specific details in Shopify. Good ownership includes a usable editing path for the people who run the shop.

AI changes the price of a first draft

The strongest change is not that an AI can write a snippet. It is that the distance between “I wish the store did this” and a testable version has shrunk. A merchant can describe the customer journey. An agent can inspect the theme, propose where the feature belongs, draft the implementation and help exercise it in a preview.

For the notebook, the task could be stated plainly: show an optional cover-name field, cap it at twelve characters, explain that it is printed as entered, attach it to the correct cart line and order, and preserve separate text on separate copies. Then test empty input, maximum length, mobile layout, cart display and checkout handoff.

That is a much better starting point than asking an AI to “build an options app.” It names the result, the boundaries and what counts as working. An agent can reduce the cost of exploration, but a fluent answer is not proof that a customer can complete the purchase. The preview, cart, order and mobile experience still have to be checked.

When the first attempt is cheaper, merchants can build for their own actual workflow. A feature no catalogue app has prioritised may be easy to make. Another may prove too complex, at which point a mature app is clearly worth the subscription. AI makes both choices faster to reach.

Do the arithmetic over the life of the feature

An app’s monthly price is visible; the full cost of ownership is easier to miss. An app may bring installation and setup, recurring fees, a support relationship, updates, script weight, configuration to maintain and time spent diagnosing interactions with other apps. A custom feature has a different bill: the initial build, review, testing, documentation and future changes.

Neither side is automatically cheaper. A feature used on thousands of products may be cheaper to rent from a specialist than to maintain in-house. A narrow feature that has barely changed in a year may be cheaper to own, especially if the store already has a developer or an agent that knows the theme.

Imagine an app costs $25 a month for a single feature. That is $300 a year. A custom version costing $600 would take two years to match the subscription price, before maintenance. The calculation changes when the app handles five complex workflows, when the build takes much longer than estimated, or when it prevents an expensive mistake. The numbers are a simple illustration, not a claim about app prices or typical savings.

There is another cost worth counting: freedom. If the feature is part of the theme, the merchant can adjust its language and behaviour to fit the storefront. If it lives inside an app, that control may be limited by settings the vendor chose to expose. A merchant should weigh that flexibility alongside dollars and hours.

Some jobs deserve a specialist

There is a trap in a headline like this: seeing every installed app as a target. A service can contain a lot more than a storefront widget. Subscriptions may require billing, recurring orders, retries and customer self-service. Reviews need invitations, fraud filtering and moderation. Search across a large catalogue can need indexing and ranking. Tax calculation, address validation, accessibility support, fraud analysis and fulfilment connections can each depend on changing rules and reliable infrastructure.

Shopify also sets boundaries. Developers can use Shopify Functions for supported backend purchase logic, but access depends on the Function type and how it is distributed. Custom apps with Shopify Function APIs are limited to Shopify Plus stores. Checkout extensions at the information, shipping and payment steps also require Plus. Those limits matter when a proposed custom feature reaches beyond the storefront theme. Shopify Functions availability and checkout extension availability.

That is not a failure of imagination. Platform limits are part of the design brief. An app that solves a restricted or operationally demanding problem may be exactly the right tool. A clever theme change cannot safely replace a service it does not have permission or infrastructure to perform.

The rule I would use is straightforward: rent ongoing expertise, infrastructure and responsibility; question a recurring fee for a thin layer of display and logic. Apps that keep earning their place will survive that test comfortably.

Owning code means owning the details

“We can build it” cannot mean “we can paste code into the theme and forget it.” Theme code has to be readable by the next person. A feature should have a clear place, a simple way to change its content and a record of why its important rules exist. Changes should be made in a copy or preview theme, reviewed and tested before they reach customers.

The testing should follow the customer’s actual path. A button that looks right can still add the wrong variant. A form can save its text to the wrong line. A recommendation can disappear at mobile widths. A cart update can run twice. The useful definition of done is not that the code compiled; it is that a customer can understand the choice, make it, see the right total and complete the order.

AI agents make the building quicker and raise the value of that discipline. They can generate a patch quickly. They can also misunderstand the existing theme, miss a hidden dependency or report a success they never verified. The owner’s judgment, a good brief and a repeatable preview test determine whether speed creates value.

When software becomes cheaper to make, knowing what deserves to exist becomes more valuable.

The app store will have to earn the install

The app store is not emptying. Its centre of gravity is moving. A few years ago, convenience alone could justify a product. Increasingly, a product must offer expertise, infrastructure, a hard-to-reproduce network or dependable maintenance. The thinner the feature, the harder it will be to charge for it every month.

That change should be good for merchants and demanding for app makers. Merchants can choose the arrangement that fits their business: install, subscribe, build or combine the two. App companies can respond by solving problems that a merchant cannot sensibly maintain alone, or by making their products more open and adaptable.

For a founder, the best first move may be neither an app marketplace search nor an AI prompt. It may be to describe the customer, the moment that frustrates them, the rule the store needs to apply and the evidence that would show the change worked. Then look at what Shopify already provides. Then price the remaining gap.

That is why I say Shopify apps are dead. The slogan is a provocation about the default, not a prediction that software will vanish. A small feature no longer has to arrive as a permanent subscription. The merchant can ask what the feature is worth, how hard it is to keep correct and who should own its future.

The next time the answer seems to be “install another app,” pause at the size of the problem. Sometimes the app is the right tool. Sometimes Shopify already does the job. And sometimes the thing that once looked like a product is now just a feature your store can own.