Shopify Project Stalled? Rescue, Switch Dev or Restart

You hired a developer to build your Shopify store. Three months later, it is half-built, they have stopped responding, or the timeline has slipped six months with no end in sight. At this point, the practical question is not why it stalled. It is whether to rescue it with the current developer, hire someone new, or restart from scratch. This guide covers how to diagnose the stall, triage the work in your first week, and make that call with confidence.

Why do Shopify projects actually stall?

Most stalled projects fail for one of five reasons that have nothing to do with whether the developer is technically skilled.

Scope was never actually fixed. You discussed features, the developer quoted, but nobody wrote down what "done" means. The developer built features A, B, C. You expected A, B, C, plus D, E, F. Each time you mention D, E, or F, the developer says "that will be extra" or "we did not agree to that." Meanwhile, six months pass. The project is simultaneously on track (for what they committed to) and behind (for what you need).

The developer is overloaded. They took your project on top of existing retainers, client support, or other commitments. Your store is not urgent because it is not revenue-generating yet. Client emergencies happen, and your project slips. The developer keeps saying "next week" for months because next week, something else is always more urgent.

The foundation is broken and they did not tell you. They built the theme on an older, no-longer-maintained theme base, or chose apps that conflict with each other or with the new Shopify checkout. Or the first developer handed off to a second developer who realized the architecture will not support the roadmap. Rather than admitting the foundation is unsound, they keep building on it, delivering slower and slower.

Too much was paid too early. If most of the fee went out before most of the work was delivered, the money no longer pulls the project forward. A busy developer will naturally give their time to clients whose next payment depends on the next delivery.

Communication broke down. The developer stopped responding to messages, or stopped providing updates. Sometimes this is because they realized the scope is unsolvable and did not know how to tell you. Sometimes life happened and they are too embarrassed to re-engage. Either way, silence is a failure of the engagement, not a reflection of code quality.

In our view, a stall is more often a project management failure than a skills problem. That matters, because it changes which of the three paths below makes sense.

What should you verify in the first week?

Before any conversation about blame or next steps, find out what you actually have. None of this needs technical skill.

Step 1: Confirm you own the store. Log in with your own email and check that you are the store owner. Ownership can only be transferred by the current owner, from Settings, then General. If the store is registered to the developer, or still sits in their Partner development store, getting it transferred to you is the first and most important request you make. Shopify does not let a collaborator become the owner, so being "added" to the store is not the same as owning it. Do this before anything else.

Step 2: Identify what actually exists. In the admin, go to Online Store, then Themes. You will see the live theme and a theme library of unpublished themes, each with the date it was last saved. Take a screenshot. An unpublished theme is usually the work in progress. The last saved date tells you, without asking anyone, when work actually stopped.

Step 3: Check what else was installed. Go to Settings, then Apps, and list every app along with any charges on your Shopify bill. Pay special attention to anything that is not from the Shopify App Store, such as a custom app the developer built for your store. Ask who controls it, because a custom app may depend on the developer's own account to keep working or be updated.

Step 4: Look at the theme code if you can. From the theme library, choose Edit code on the work in progress theme. You do not need to read Liquid, Shopify's theme language. You only need a rough picture: how many files look custom, and whether there are comments explaining what they do. Take screenshots to show whoever picks this up next.

Step 5: Check which theme architecture it is built on. Open the theme editor and go to the default product template. Shopify's theme architecture guide says that if an Add section button appears below the section list, the theme supports sections on every page, which is the Online Store 2.0 generation. If there is no such button, it is what Shopify calls a vintage theme. Work built on a vintage theme is usually harder to hand to a new developer and harder to keep updated.

At the end of this you know what you have, without relying on anyone's description of it.

How do you assess if the half-built work can actually be salvaged?

Salvageability hinges on three facts: is the theme built on a current architecture, are the apps registered to the merchant (not the developer), and is the code documented enough that a new developer can understand it?

Ask a new developer (or us, at no cost) these three questions about what you found in Step 4:

One: Is it built on an Online Store 2.0 theme? Use the Add section check from Step 5. Online Store 2.0 has been Shopify's theme architecture for new themes for years now, and most developers you speak to will expect it. Half-built work on a vintage theme can be finished, but ask any new developer whether finishing it or moving the custom features to a current theme is the better use of your money, and ask them to explain why.

Two: Who controls the apps and accounts? Apps installed from the Shopify App Store are managed from your admin, whoever installed them. Custom apps, and third-party accounts such as a payment gateway, email tool or hosting for an integration, are different: if they are registered to the developer, you need them transferred or rebuilt. List each one and whose name it is in.

Three: Can another developer understand the code? Liquid comments are written with {% comment %} tags or an inline {% # %}, so any developer can quickly see whether the custom work is explained. Clear comments and a short written note on what each customisation does make a takeover much easier. Undocumented, heavily customised code takes longer for a new developer to understand, and that time is what you pay for.

If all three answers are good, finishing the existing work is realistic. If one or more is not, get a new developer to price both finishing and restarting before you decide.

Do you rescue it with the current developer or switch?

This is the decision that matters. There are three paths.

Path 1: Rescue with the current developer. Call them, acknowledge the stall, and ask for a restart date and weekly check-ins. Offer to restructure payment: less upfront, more on milestones. This works if the stall was a project management failure (they got overloaded, scope drifted, communication broke), not technical. If they were capable before and still have the context, context is valuable. A developer who knows your store's history will be faster than a new one starting from scratch. But it only works if they commit to a hard date and you hold them to it. Set a restart date two weeks away. If it slips again, you switch. Do not renegotiate a third time.

Path 2: Hire a new developer for takeover. Bring in a fresh developer specifically to take over the half-built work, not to start fresh. This is called a project rescue. The new developer inherits the theme, the apps, the product data, and the merchant account. Their job is to review, fix any mistakes, complete the roadmap, and ship. This is faster than starting over because the merchant data and theme skeleton are already there. It is also a good test: if the new developer can quickly understand what was built and ship in a reasonable time, the original work was salvageable and the original developer was just slow. If the new developer says "we have to rebuild," you learned that the foundation was broken.

Path 3: Start completely fresh. Abandon the unpublished theme and apps. Create a new theme from a modern theme template (Shopify offers free ones). Migrate your product data from the old store or re-upload it. Start from day zero. This is the slowest path, but sometimes it is the cleanest. You usually choose this when the stall was caused by a bad technical foundation that would haunt you for years, or when the half-built store is such a mess that understanding it costs more than rebuilding it.

Which path is right depends on what you found in the triage, not on how frustrated you feel. If ownership and access are clean and the theme is sound, a takeover usually preserves the most of what you paid for. If the foundation is the problem, restarting can be cheaper than it sounds. And if the current developer is capable and willing, staying may be quickest of all, as the section below explains.

How do you talk to the current developer about what comes next?

Do not accuse. Do ask directly.

Call and say something like this: "We have not heard from you in [duration]. I need to understand what happened and make a decision about how to move forward. Can we talk today or tomorrow?" If they agree, ask three questions:

One: Where is the project actually? What is genuinely done, what is in progress, what is stuck, and what was never started? Do not accept vague answers. Ask them to send you a document: a list of features, and for each one, the status: complete, 50 percent done, not started, blocked. This forces honesty.

Two: What is blocking progress? Is it scope (you kept adding things)? Is it a technical dead end (the approach does not work)? Is it that they got overloaded? Is it that they ran out of budget and you have not paid the last invoice? Each answer changes what comes next. Some are fixable (pay the invoice, agree on scope). Some are not (if the approach is broken, it is broken).

Three: Can you commit to a finish date? Not "soon" or "this quarter". A date. If they cannot, that is your answer. You are switching.

If they admit to a problem, ask: "What would it take for you to finish by [date]?" Listen. They might need a scope reduction (you agree that features D, E, F are post-launch). They might need to hire a junior developer to help. They might admit they are in over their head and refer you to someone who is not. All of these are useful information.

If they ghost you or make excuses, you already have your answer. Move to step 2 or 3 above.

On contract and payment. Read what your contract says about milestones, deliverables and who owns the work in progress, before you say anything about money. Linking any remaining payment to a written restart plan and delivered milestones is reasonable. Threatening to forfeit money you owe, or holding back payment for work that was delivered, is not, and can put you in the wrong. If the amount is significant or the relationship has turned hostile, speak to a lawyer. This is general guidance, not legal advice.

Do not negotiate indefinitely. Give the current developer one chance to restart and commit. If it slips again, you know: the problem is not fixable within that relationship.

How do you structure a takeover engagement with a new developer?

Whether you are rescuing with the current developer or switching to a new one, the handover matters. Here is how to make it clean.

First: Secure ownership. Make sure you are the store owner and control the login, as in Step 1. If ownership still sits with the original developer, resolve that before onboarding anyone new.

Second: Grant access the right way. Do not share your password or OTP. An outside developer should get a collaborator account: they send a request, and you approve it in Settings, then Users with only the permissions the work needs. Collaborators do not count towards your plan's staff limit, which matters on Basic, where Shopify allows no staff accounts at all.

Third: Hand over documentation. Give the new developer the screenshots and lists from your triage: the theme library, the app list, the theme architecture, and whatever the original developer said is done and not done. The more they start with, the less of their time you pay for rediscovering it.

Fourth: Start with a discovery phase, not a build phase. The first piece of work should be a short, paid review: the new developer looks at what exists, lists what is sound and what is not, and prices the remaining work. Keep it small and fixed in scope. It gives you an honest estimate before you commit to the larger job, and our guide on reading a Shopify quote helps you judge the estimate you get.

Fifth: Use a fixed-price milestone structure for the takeover phase. Read our guide on fixed-price vs retainer work to understand the trade-offs. For a takeover, a fixed-price structure with multiple small milestones (complete audit, fix theme rendering, integrate payment provider, QA and launch) protects both of you. The developer knows the scope. You know the cost. You pay as milestones ship, which means they have incentive to ship.

Sixth: Remove the old developer's access. Once the new developer is set up and can reach what they need, remove the old collaborator account and generate a new collaborator request code, so the old code can no longer be used. Our developer handover checklist covers collecting theme files, app access and other assets before that point.

When is staying with your current developer the right call?

Before you assume switching is better: if the developer is technically sound and the stall was caused by scope drift, overload, or communication failure, and they are willing to commit to a date and check in weekly, staying with them can be faster than onboarding someone new. A developer who already knows your store's setup will not waste time reverse-engineering it. But this only works if they genuinely restart and if you hold firm on the date. If the new date slips, switch without negotiating again.

Want a free assessment of your stalled Shopify project?

Free rescue assessment. Get in touch or email hello@exactwhy.com with the subject "Stalled project assessment" and your store URL. Include screenshots of your theme library and app list from the triage above. We reply within 4 hours with an honest view of whether the half-built work is worth finishing, which of the three paths looks most realistic, and what a sensible first step would be. If staying with your current developer is the right answer, we will say so. For how to define the finished job next time, see our guide to scoping a Shopify project.