When app subscriptions start adding up

How often are you charged fixed monthly amounts by Shopify App Store apps that add up and drive business costs higher? Each app may be solving a tiny problem you needed to solve when your business was getting started. At that stage, using an app makes sense. It is quicker to install and test, and you do not want to spend weeks building something before you know whether the feature is useful.

But once the business becomes more stable, it is worth reviewing those subscriptions. Is the app still the best option? Is the feature complicated enough to justify paying every month, or could a small custom solution do the job?

That was the thinking behind a Shopify project at AutoBizz. We needed a separate copy of a live Shopify store so a developer could build and test a custom replacement for the CEDD Estimated Delivery Date app without experimenting on the actual storefront. The goal sounded simple. The process had a few surprises.

Why we created a development store

It can be tempting to make changes on a live store because it feels like the quickest way forward. But the live store has real customers, real orders, and a business depending on it, and testing a replacement there can create problems that are completely avoidable.

So instead of taking that risk, we created a separate Shopify development store and started recreating the environment the developer would need. The idea was to get the existing theme, products, data, apps, and settings into a place where we could test things safely.

There is another thing worth considering before starting this kind of work: do the expected savings justify the effort? A custom app is not automatically cheaper once development, testing, future maintenance, and unexpected edge cases are included.

But a development store can be useful beyond one project. You can reuse the setup for future app tests, theme changes, and custom features. It is a tree that keeps on bearing fruit without demanding a constant water supply. The important thing is to build only what is useful for the work, rather than making the process unnecessarily complicated

Copying the theme and bringing over the store data

We started by downloading the theme from the live Shopify store and uploading it to the development store. After that, we exported the products from the live store and imported them into the new environment.

At first, this sounds like most of the work is done. But a Shopify store is more than its design and product catalogue. A theme can depend on product templates, metafields, app snippets, and settings that do not automatically appear just because you have copied the theme files.

We also needed customer records so the development environment would be realistic enough for the work. At AutoBizz, we take confidentiality seriously, so we did not simply copy the customer information with the original identifying details intact. We changed customer names, email addresses, and other identifying details before importing the data into the development store.

This gave us workable data while avoiding unnecessary exposure of customers' original personal information. Copying a store for testing should not mean casually copying every piece of personal information along with it.

Finding the missing templates and metafields

The first gaps appeared during setup. Some product templates were missing, and the product export had not brought over the metafields that the copied theme expected.

One of the errors we encountered was:

FileSaveError: Dynamic source 'product.metafields.custom.product_details_tab | metafield_tag' does not exist.

The theme was trying to use a product metafield that did not exist in the development store. We created only the missing metafield definitions that were needed to save the theme configuration, not every possible field just in case.

It is a useful reminder that a product export should not be treated as proof that every part of a Shopify store has been transferred.

The theme editor worked, but the storefront did not

Then came the problem that needed more investigation. The copied theme rendered in the Shopify theme editor, but when we opened the actual storefront, the homepage showed a page-not-available or 404-style result. The same thing happened on other routes, including /collections/all and product pages.

Rather than keep changing random settings, we started narrowing down the possibilities. Since /collections/all was showing the same problem, it did not look like an issue limited to the homepage assignment. We also tested the stock Dawn theme, and that worked. This pointed towards something in the copied theme rather than a general issue with the development store.

We then looked through the theme code and found references to EasyLockdown. The live store had been using that app, but EasyLockdown was not installed in the development store. The copied theme had carried over code that depended on it.

This was one of those details that can be missing from a project description. The client may not mention an app dependency because it is simply part of how their store has always worked, and sometimes they may not even know the theme relies on it. We had not been told EasyLockdown might be relevant, so we had to find the connection ourselves.

Follow the evidence, not every possible guess

The relevant code treated the theme editor differently from the actual storefront. In design mode, it output the page content directly. Outside the editor, it passed the content through an EasyLockdown snippet.

{% comment %}ElBodyStart{% endcomment %}
{% unless request.design_mode %}
  {% comment %}{{ content_for_layout }}{% endcomment %}
  {% render 'easylockdown_body',
    content_for_layout: content_for_layout,
    elhDefines: elhRender[1]
  %}
{% else %}
  {{ content_for_layout }}
{% endunless %}
{% comment %}ElBodyEnd{% endcomment %}

Since EasyLockdown was not installed in the development store, we bypassed the wrapper and restored direct output using {{ content_for_layout }}. The homepage finally loaded. We did not need to rebuild the theme, only remove the dependency that had travelled with it. App code should never be removed blindly, but here the clues were clear: the copied theme behaved differently from the stock one, and the code pointed to EasyLockdown.

The lesson is simple: compare what works with what does not, isolate the difference, and test one likely cause at a time. Sometimes the best solution is not a new system, but understanding the existing one well enough to find what is getting in the way.

Recreating the app setup and handing it to the developer

Once the storefront was loading, we installed the necessary apps in the development store, including CEDD Estimated Delivery Date, and set them up to match the live store as closely as the development environment required.

The point was not just to make the theme preview look similar. The developer needed to understand the existing app behaviour and configuration so the custom replacement could be developed and tested against what was already in use.

A handoff is only useful when the next person can actually continue from it. A store that looks roughly right but is missing important settings or dependencies can waste the developer’s time, so we focused on getting the necessary pieces in place.

What this process says about how we work at AutoBizz

• We figure things out as we go

Not every project arrives with a perfect technical brief. Sometimes it explains what the client wants but leaves out how the existing system works. We are good at figuring things out on the go, but that does not mean guessing blindly. It means checking the evidence, testing possibilities, and learning enough about the system to make the next decision. Missing information is normal in real projects. The important part is not letting those gaps stop progress.

• We look for the simplest solution that actually works

It would have been possible to turn every missing detail into a separate task and spend much longer trying to recreate everything. Instead, we focused on what the developer needed and fixed the blockers. Simplicity does not mean ignoring complexity. It means understanding which complexity matters for the job.

• We take confidentiality seriously and protect the live business

Customer information is not just another file to move between stores. Changing names, email addresses, and other identifying details before import was a practical part of preparing the test store, not an afterthought. A separate development store also gives the team room to test theme changes, app settings, and custom features without turning the production store into a laboratory.