Custom theme or bought theme

A bought theme costs 300 to 400 dollars. A custom theme costs ten to thirty times that. Put like that, the answer looks obvious. For a lot of stores it is. But the day-one price is the wrong number. The number that matters is what the theme costs by the time the store has found its shape. That number moves the other way.

When bought is right

You are launching a store and you do not yet know what sells. You have under 50 products. Your brand is a logo and a colour, not a visual system. You need to be live in three weeks. Buy Dawn or a well-kept paid theme. Spend the budget on product photos and ads. Learn.

A bought theme here is not a compromise. It is the right tool. I have talked founders out of custom builds at this stage more than once, and I will again. A custom theme for a store with no sales history is a beautiful answer to a question nobody has asked yet.

When it stops being right

Somewhere between month six and month twelve, the same store is a different business. It has 400 products and a collection structure the theme never planned for. It needs a bundle builder. A size guide by category. A pre-order flow. A landing page template for each ad campaign. Each of those became an app. Each app bolted a section onto a theme that was not built to hold it.

This is customisation debt. Every change is made in the theme editor, or by a freelancer in the theme code. The next theme update either overwrites it or cannot be installed at all. I often meet stores running a theme version from 2022. Updating would break eleven changes that nobody wrote down.

The hidden costs, both ways

Bought theme: app subscriptions to fill the gaps, often 150 to 300 dollars a month by year two. Speed lost to those apps. Freelancer hours to patch conflicts between them. And the day you want to change something structural and find the theme cannot.

Custom theme: the build cost, of course. Then developer lock-in, if the developer wrote it in a way only they understand. Then the same update problem in a new form. When Shopify ships a new checkout or section feature, someone has to add it by hand.

Lock-in is the risk to manage. A custom theme should be built on Online Store 2.0 with JSON templates and sections. It should use standard Liquid, not a private framework. It should come with a README that a second developer can work from. If a developer cannot promise that, the theme is not custom. It is captive.

Where the lines cross

For most of the stores I have built, the lines cross around month eight. Before that, the bought theme is cheaper in cash and in time. After that, the store pays every month for apps and patches to do what a custom theme would do on its own. And the checkout is slower for it.

The right move is often not custom from the start. It is bought first, then custom once the store knows what it is. The second build is better, because it is built from real data. Which collections people browse. Which product page layout converted. Which features were never used.

The case for saying no

A founder came to me last year with a brief for a custom theme and a budget. His store was doing about 40 orders a month on a stock theme. I told him to keep the theme, fix the three apps that were slowing it down, and rewrite his product pages. He did that for a tenth of the budget. He doubled his orders in four months. He is now a custom theme client. I am designing the build around what those four months taught him.

This week

Add up your monthly app bill. Add the freelancer hours you spent on theme fixes in the last quarter. Multiply by twelve. If that number is more than half the cost of a custom build, ask for a scoped quote and compare properly. If it is not, keep the theme and spend the money on photos.