Every app on the bill gets the same rent-or-own test

A subscription is a decision you keep making

An app is quick to install and quiet to keep. A stack built over two launches and one agency handover renews every month without anyone signing it off again, so it is never priced as the commitment it is.

At Sleeken, the Shopify studio I run inside Saar, a Stockholm software house, I read the bill over three years, not one month. On a P&L a monthly fee reads as a rounding error; on the three-year view it is counted 36 times. The App Tax Calculator does that sum for you: it takes one figure, your current monthly app spend, and shows the total per year and over three years.

So I treat an app bill as a code decision, not a subscription. The comparison that matters is not app versus app. It is rent versus own.

Own the code, rent the operation

Go down the billing page and mark each line rent, own or undecided. The rule for sorting them comes from my guide to native equivalents: own the things that are only code, and rent the things that are also an operation.

Some lines are only code. A page builder becomes OS 2.0 sections in the theme. Size guides and spec tables become native metaobjects, and an app for them is a monthly fee for a text field. Bundles and volume pricing move to Shopify Functions, which run at checkout, with no script on the storefront and no discount that quietly stops applying.

A currency switcher on a one-currency store, one of the five app scripts I remove, can go too. Shopify Markets does this natively now, and the app usually predates it.

Other lines are also an operation, and three are worth keeping: reviews, search at real catalogue size, and the email platform. Keep renting those, not because they cannot be built, but because each holds data, moderation queues or deliverability you would have to rebuild from nothing. Undecided is a mark too. I give it to predictive search, which has only a partial native equivalent.

Eighteen months to pay back

An "own" mark is not yet a reason to build. A build costs more than a month of licences and less than three years of them. So the test is payback: if a replacement pays back inside eighteen months, I recommend it; if it does not, I say so and you keep the app. As a ratio, the build has to cost less than eighteen months of the fees it removes, which is half the three-year view.

I run the test before quoting, not after, so nothing goes into a quote that has not already passed it. An honest "keep the app" matters more to me than a larger quote.

The calculator also shows an estimated native-replaceable share. Is that a promise? No: it rests on a typical figure, about 65% of app spend replaced with native OS 2.0 features and custom app extensions. That is my estimate, not a measurement of your store, so the eighteen-month test still decides each line.

Owned code ships once

Owned code ships once, sits in your theme and carries no scripts a visitor has to download. The bar for the extensions I build is public, on Sleeken's About page: under 100 kb, natively integrated, fully owned, zero subscriptions. A typical premium store's app stack, by contrast, is megabytes of rented JavaScript.

I care about how a size guide or a bundle offer looks, but just as much about what it costs a phone to load.

One limit: "owned" is my stance, not a guarantee written on a web page. Sleeken's terms say ownership of work delivered to a client "is defined in that client's proposal", so that is where it is settled, project by project.

Uninstalling stops the bill, not the weight

Theme snippets, script tags and orphaned metafields survive an uninstall, so the page stays exactly as heavy as it was. The bill stops; the page does not get faster.

So removing an app is a build task with a checklist, not a click. Budget an afternoon for it.

Start with the calculator for your own three-year number, then take the bill one line at a time. A line is done when the leftover code is gone, not when the bill stops.