Do you need a developer for a Shopify store?

Everything that ships as a setting. Choosing and configuring a theme, building collections, writing product content, setting up navigation, configuring shipping profiles and tax, connecting payment methods, publishing pages, and running the whole store operationally.

Most merchandising is in this group too. Section-based themes let you assemble pages from blocks, reorder them, change images and copy, and build landing pages without touching a template.

A great deal of functionality arrives through apps: reviews, email, subscriptions, loyalty, back-in-stock, search. Installing and configuring these is an operator task rather than a developer one, though choosing them well is where the skill sits.

So a store can go a long way on configuration alone, and many do. The point at which that stops being true is usually when you want the store to do something specific to your business rather than something the theme anticipated.

Template changes beyond what the theme exposes. Adding a field to a product page, changing how variants behave, building a fitment lookup, or restructuring a collection template all mean editing the theme's code.

Checkout work. Modern Shopify checkouts are customised through extensions rather than by editing files, which is a development task and, for some capabilities, requires the Plus plan.

Custom logic in the platform. Discount rules, shipping rules, bundling and validation that go beyond the built-in options are implemented as functions that run on Shopify's infrastructure, and they are written in code.

Integrations. Connecting a resource planning system, a warehouse, a supplier feed or an internal tool means working with the platform's APIs, handling failures, and keeping the connection running.

And measurement. Custom events, a data layer, server-side tagging and anything beyond the standard channel connections is a development task even though it looks like a marketing one.

Performance work belongs here too. Diagnosing what is slowing a theme, deferring scripts and cleaning up leftover app code is not achievable from the admin.

Write the outcome, not the implementation. A brief saying what a customer should be able to do, and what should happen to the data, gets a better result than one specifying how you imagine it should be built.

Insist on a duplicated theme for changes and a review before anything goes live. Editing the live theme is how stores end up with a broken product page during trading hours, and it is entirely avoidable.

Ask for version control and a record of what changed. Many small Shopify projects are delivered as edits with no history, which makes the next change more expensive and the cause of a problem impossible to find.

Prefer a fix in the right place to a patch. A workaround pasted into a template solves today's problem and becomes the reason the next theme update breaks something.

And keep documentation of what was customised. Six months later, the person deciding whether an app can be removed or a theme updated needs to know what depends on what.

The switch usually comes when the store has a queue of changes rather than an occasional one. A backlog that keeps growing means the business has moved past what configuration can serve, and a continuing relationship costs less than a series of small engagements each rebuilding context.

A second signal is when the store is genuinely a system rather than a shop: several integrations, custom logic in the checkout, a bespoke measurement setup. That needs someone who understands the whole of it rather than someone brought in per task.

A third is when the changes have revenue attached. If the backlog contains work that measurably affects conversion or acquisition cost, the cost of not doing it exceeds the cost of the capacity.

Until then, occasional development bought carefully is entirely reasonable, and many successful stores run that way for years. What matters is that whoever does it leaves the store in a state the next person can work with.