Picture this: you hire a contractor to renovate your kitchen. They tear out the old cabinets, install new countertops, rewire the lighting, and hand you the keys when it’s done. Gorgeous. Exactly what you wanted. But six months later, the faucet starts dripping. A cabinet hinge comes loose. The overhead light flickers. Do you call the renovation crew back for that? Of course not. That’s a different job, handled by different people, on a different kind of schedule.

A lot of merchants, and honestly some agencies too, treat custom development and ongoing maintenance like they’re the same thing, or assume one automatically covers the other. That mix-up leads to blown budgets, frustrated teams, and stores that quietly fall apart after launch. Understanding the difference between the two sounds boring until it saves you thousands of dollars and a very stressful afternoon. Stores that hold up well after launch typically have dedicated Shopify support and maintenance services handling the ongoing work. 

So let’s get into it properly.

Custom Shopify Development: A Project With a Beginning — and Ideally, Not an End

Custom development is work with a finish line. You identify something you want to build or change, you scope it out, and someone delivers it. The project has a beginning, a defined scope, and an end date. Once it ships, that chapter closes.

But here’s what often gets lost: the finish line of a project doesn’t have to mean the end of a relationship. In fact, the best development partnerships don’t dissolve at launch — they evolve. The team that built your store knows why certain architectural decisions were made, where the custom code lives, and what tends to be fragile. That knowledge doesn’t expire when the invoice gets paid.

In practice, custom development looks like things such as:

  • Building a Shopify theme from scratch or heavily customizing a premium one (Dawn, Prestige, or Symmetry, for example)
  • Developing a custom or private Shopify app to handle business logic your off-the-shelf apps can’t cover
  • Integrating platforms like Klaviyo, Recharge, Gorgias, or ShipBob in ways that go beyond clicking “install” in the app store
  • Building storefront experiences with Shopify’s Storefront API or the Hydrogen/Oxygen framework for headless setups
  • Creating product configurators, bundling logic, subscription flows, or multi-currency and multi-language architectures

The developer (or team) gets a brief, writes code, tests it, and ships it. The deliverable is concrete. You can point to it. “We built X” is a sentence with a clear subject and object.

Custom development is also, let’s be real, the exciting part. It’s what agencies put in their portfolios. It’s where the creative problem-solving happens. It’s the work that makes your store different from the ten thousand other Shopify stores using the same theme out of the box.

But exciting or not, launching a feature is not the same as maintaining one. And the teams best positioned to maintain your store well are often the ones who built it. That’s not a sales pitch — it’s just how institutional knowledge works.

So Then What Does Ongoing Maintenance Actually Cover?

Maintenance is everything that happens *after* the build so that the build continues to work the way it was designed to.

Here’s a picture that might land: imagine your store is a restaurant kitchen. Custom development is the renovation that put in the industrial stove, the ventilation system, and the prep stations. Maintenance is making sure the stove stays calibrated, the ventilation doesn’t clog, and the refrigerators stay at temperature. You’d never skip that stuff just because the renovation went well.

Shopify’s ecosystem moves fast. The platform itself releases updates; app developers push new versions; browsers change how they handle certain scripts; Google updates what counts toward Core Web Vitals. Theme code that ran cleanly in January can start throwing errors after a Shopify update in March. Apps that worked fine in isolation start conflicting when a new one gets added to the mix. A script from a marketing tool you added last quarter is now adding 400ms to your load time. These aren’t edge cases. This is just how the web works.

Good maintenance covers a wide surface area:

  • Catching and fixing bugs before (or right after) they affect customers
  • Keeping themes, apps, and third-party integrations updated and compatible with each other
  • Running regular performance checks: Core Web Vitals via Google Search Console, Lighthouse scores, and actual load time testing with tools like GTmetrix or WebPageTest
  • Security audits and watching for unusual activity, especially on stores handling sensitive customer data
  • Uptime monitoring, typically using services like Better Uptime or Pingdom, with fast alerts when something goes down
  • Backing up store configurations, custom code, and content (Shopify handles some of this natively, but not all of it, and not in ways that cover every scenario)
  • Small, recurring content updates: correcting product descriptions, swapping out banners, adjusting shipping rules, fixing broken links

Some of that work is reactive. Something breaks, you fix it. But the better half of maintenance is preventive: running audits, spotting risks before they become incidents, and keeping the whole system in a state where surprises are rare.

A good maintenance partner does both. And importantly, they do it without you having to ask every single time.

Why Merchants Keep Confusing the Two (And What It Actually Costs Them)

The confusion is understandable. Both types of work involve developers. Both involve Shopify. Both show up on invoices. But they’re structured completely differently, they require different skill sets, and they fail in different ways when they’re handled badly.

The most common scenario: a merchant hires an agency or freelancer to build their store. The project goes well. Launch day arrives, everyone’s happy, and the relationship quietly wraps up. Then, a few months later, something breaks. Maybe it’s a small thing, like a product metafield that stopped rendering. Maybe it’s a big thing, like the checkout throwing errors during a flash sale. Either way, there’s nobody on the other end of the phone.

The original developer has moved on. Emergency rates for pulling someone back in are brutal. Support tickets to a general helpdesk go to junior staff who don’t know the codebase. And in the meantime, the store is either down or limping along at reduced performance while real customers are trying to buy things.

This is a painful and completely avoidable situation. It happens because the original project never included a maintenance agreement. The merchant assumed support was built in, and the agency assumed the engagement ended at launch. Nobody clarified.

The flip side is also true, and it’s worth saying: some merchants accidentally burn through development budgets on tasks that belong in a maintenance plan. “Can you just update this banner?” or “Can you fix this one typo on the product page?” are not development questions. Routing them to a development team is like hiring a plumber to change a lightbulb. The work gets done, but you paid five times what you should have.

Getting this right isn’t about being rigid. It’s about being clear on what kind of work you’re asking for, so you can route it to the right people and pay the right rate.

The Gray Area: When Does Maintenance Become Development?

There’s no perfectly clean line, and anyone who tells you otherwise is oversimplifying. But there are some reliable ways to tell them apart.

A bug fix is maintenance. But if fixing that bug requires redesigning the section where it lives, that starts to look like development. Updating an existing app integration is maintenance. Replacing it with a custom-built solution is development. Adjusting a font size in the theme editor is maintenance. Rebuilding the product page layout using Shopify’s new metaobject system is development.

A useful question to ask: does this work require a scope, a timeline estimate, and the creation of something new? If yes, it’s development. If the goal is simply to keep existing functionality working correctly, it’s maintenance.

When tasks land somewhere in between, the best thing you can do is ask your agency or developer to label it explicitly before work starts. Not after. “Is this a maintenance task or does this need to be scoped as a development project?” is a completely reasonable question, and a good partner will have a clear answer.

One genuine advantage of working with a team that handles both: they already know your store. The people maintaining your codebase know why the original developer made certain architectural decisions. They know where the custom code lives, what it does, and what tends to be fragile. That institutional knowledge has real value, particularly when something unexpected goes wrong at 11 PM the night before a major sale.

How to Build a Budget That Actually Reflects Reality

Here’s advice that doesn’t get said loudly enough: budget for both, separately, from the very beginning.

If you’re kicking off a custom development project, that budget should cover the build and nothing else. Maintenance costs should be a separate line. Don’t assume your development contract includes post-launch support unless those words are actually in the contract. Before you sign anything, ask two questions: “What happens after launch?” and “Who do I contact when something breaks six months from now?”

For maintenance specifically, monthly retainers are the standard. What you pay depends on your store’s complexity, how fast you need a response when issues arise, and whether your agreement includes SLA-backed guarantees (meaning the vendor is contractually committed to responding within a certain number of hours). A straightforward Shopify store without heavy custom code might spend a few hundred dollars a month on a basic plan. A store running custom apps, complex integrations, and high traffic volumes will need more coverage and can expect to pay accordingly.

It’s also worth knowing what “emergency rates” look like in your market before you need them. Outside of a maintenance agreement, pulling in a developer for urgent fixes can run anywhere from $150 to $300+ per hour depending on the work and the region. One bad incident during a peak sales period can easily outpace the cost of a full year’s maintenance plan.

Some merchants also keep development and maintenance with separate vendors intentionally. One agency handles builds; another handles day-to-day support. That setup works, but it requires thorough documentation during handoffs. The maintenance team needs to actually understand the codebase they’re inheriting, not just its surface features.

Questions to Ask Before You Hire Anyone

Whether you’re looking for a development partner, a maintenance provider, or both, the screening questions are different for each. Worth keeping both lists handy.

For development partners, you want to understand their process from discovery through QA and launch. Ask to see Shopify-specific work. Ask how they handle scope changes mid-project. Ask what deliverables you own when the engagement ends (documentation, code comments, staging environments). A team that can’t answer those questions cleanly is a team that will cost you more in the long run.

For maintenance partners, the questions shift toward reliability and communication. How do they monitor your store? What tools do they use (Datadog, New Relic, or something simpler like Better Uptime)? What’s their typical response time for urgent issues versus non-urgent ones? Do they send monthly reports showing what was done and what was found? Ask for references from clients they’ve supported for a year or more. Maintenance is a long-term relationship; you want someone who has demonstrated they can hold it together over time, not just someone who seems capable in a sales call.

Summing It Up

Custom Shopify development and ongoing maintenance are genuinely different things. Not variations of the same thing. Not interchangeable. Different in scope, different in structure, different in what it takes to do them well.

Development builds something new. Maintenance keeps what was built working properly, month after month, as the platform evolves around it. Both are necessary. Neither is optional if you’re running a serious store.

The merchants who get this right do something fairly simple: they decide up front that maintenance is a permanent, budgeted part of running their business, not a reaction to things going wrong. They find good partners for both kinds of work. They know which type of task they’re requesting before they request it.

Your Shopify store is not a one-time project. It’s infrastructure. And infrastructure needs care. Get the right people in place for both jobs, and you’ll spend a lot less time putting out fires and a lot more time actually growing.