How to Structure Milestone Payments for a Shopify Project

How you pay for a Shopify project shapes how the project runs. Pay too much upfront and you have nothing to hold back if work slows. Pay too little and good vendors walk away or quietly deprioritise you. Milestone payments solve this when each payment is tied to finished, checkable work. This post covers what makes a good milestone, an example schedule, what should release the final payment, and the MSME payment rule Indian buyers should know about.

Why tie Shopify project payments to milestones?

Milestones align money with progress. The vendor gets paid steadily as the work moves forward, and you only pay for work you can see. Both sides carry some risk at every point, which keeps both sides attentive.

The alternative arrangements each have a problem:

• Full payment upfront leaves you with nothing to hold back if the project stalls. We see the results of this in rescue projects regularly.
• Full payment on completion asks a vendor to fund your whole project. Good vendors rarely accept it, and the ones who do may be desperate for work.
• Monthly payments regardless of progress make sense for an ongoing retainer, but not for a fixed scope build where the outcome is defined.

Our post on fixed price, hourly and retainer pricing explains when each pricing model fits. This post assumes a fixed scope build, where milestones work best.

What makes a good payment milestone?

A good milestone has a trigger that both sides would agree has happened, without a debate. "Design is 50 percent done" fails that test. "Home, collection and product page designs approved in writing" passes it.

Three tests for any milestone you are asked to sign:

1. Can you check it yourself? A preview link you can click through, a test order you can place, a document you can open.
2. Is the approver named? The contract should say who on your side approves each milestone, so the vendor is not waiting on a group chat.
3. Is there an approval window? If you have not responded within a set number of working days, the milestone is treated as accepted. That protects the vendor from a client who goes silent, and it pushes you to review promptly.

What does an example milestone schedule look like?

The split below is an illustration of how a fixed scope Shopify build might be divided, not an industry standard. Your vendor may propose something different, and that is fine as long as every payment has a checkable trigger.

Two features of this shape matter more than the exact numbers. First, the advance is not the largest payment, so you are not funding most of the project before you see anything. Second, a small final payment sits after launch, so the vendor still has a reason to fix the bugs that only appear once real customers arrive.

How much advance is reasonable for a Shopify build?

An advance pays for the vendor's commitment: blocking out a team, starting design and setting up the project. It should be large enough to cover that first phase and small enough that losing it would not sink you if the relationship fails early.

If a vendor asks for most of the project fee before any work, ask why. Sometimes there is a good reason, for example when the vendor has to buy a premium theme licence or paid app subscriptions on your behalf. In that case, ask for those costs to be listed separately, ideally billed to your own account so they stay yours.

For a very small project, such as a theme customisation that takes a week or two, a simpler split of advance and completion is perfectly normal. Milestones add administration, so match their number to the size of the project.

What should release the final payment?

The final payment is the strongest incentive in the contract, so define exactly what releases it. A good final milestone includes:

• A launch checklist that has been passed. Test orders with each payment method including COD, correct tax and shipping, working notification emails and a mobile check on real phones.
• A support window that has ended. A defined period after launch during which the vendor fixes bugs in the agreed scope at no extra cost.
• Handover. Theme code in your account or repository, admin access transferred, app accounts in your name and short documentation of anything custom.

We keep a longer list in our post on checks to run before the final payment. The point is to agree on the list when you sign, not when the invoice arrives.

Be fair in return. If the store is live and taking orders, holding back the final payment over minor polish that was never in scope damages the relationship and, as the next section explains, can carry legal consequences.

Who should own the code and accounts while milestones are paid?

Ownership should not wait for the final payment. If the theme code sits only on the vendor's laptop until the end, a dispute at any milestone leaves you with a half built store you cannot touch.

A safer arrangement is that work lives in your accounts from day one. The store is in your name, the developer works through collaborator access, and the theme code is kept in a repository you own. Shopify's GitHub integration connects a theme to a repository branch and commits changes made in the Shopify admin back to that branch, naming the person who last edited the theme. That gives you a running record of what was delivered at each milestone.

Legal ownership of the code is a separate question from where it is stored, and in India a contract that says nothing can leave copyright with the developer. Our post on development agreements and code ownership explains the clause to add. Linking the ownership transfer to the payments already made, rather than only to the final one, is a fair middle ground for both sides.

What do MSME payment rules mean for Shopify projects in India?

Many Shopify agencies and freelancers in India are registered as micro or small enterprises. If your vendor is one, the Micro, Small and Medium Enterprises Development Act applies to how quickly you pay them.

According to the Ministry of MSME's MSME Samadhaan portal, a buyer must pay a micro or small supplier for goods or services within 45 days of accepting them. If the buyer does not, it is liable to pay compound interest with monthly rests at three times the bank rate notified by the RBI. The portal also lets suppliers file delayed payment cases with the state's MSE Facilitation Council.

For a Shopify project this has two practical effects:

• Acceptance matters. The 45 days run from acceptance, which is why your contract should say clearly how each milestone is accepted and by whom.
• Silent approval windows cut both ways. If your contract says a milestone counts as accepted after a set number of days without objection, the payment clock can start even if you never replied.

This is general information, not legal advice. If a large project or a dispute is involved, speak to a lawyer about how the Act applies to your contract.

How should change requests affect milestone payments?

Change requests are the most common reason milestone schedules fall apart. A founder asks for a new feature in the middle of the build, the vendor agrees on a call, and three weeks later both sides disagree about whether it was included.

Put a simple rule in the contract: any change outside the signed scope gets a written estimate of cost and time, and only starts once you approve it. Approved changes are billed with the next milestone, or as their own small milestone if they are large. This keeps the original schedule intact and makes the cost of each change visible when you decide on it.

The best way to keep that list short is a detailed scope before signing. Every hour spent on scope at the start saves several hours of argument about changes later.

What should you do if a milestone is missed?

First, check whether the delay is on your side. A milestone that depends on your content or your approval cannot be met if those inputs are late, and a fair contract says so.

If the delay is on the vendor's side, raise it in writing at once and ask for a revised date with a reason. One slip is normal in software. Repeated slips with vague reasons are a signal to review the project before paying the next milestone, not after. If things have gone badly wrong, a short independent review of the work so far will tell you whether the project can be finished or should be handed over.

Want your payment schedule checked? Email hello@exactwhy.com with the subject "Milestone schedule review" and the schedule from your proposal. We will review it for free and point out any milestone that cannot be checked or any payment that comes too early. If you want us to quote the project itself, we do that after the review, and ongoing development and support is available on a monthly retainer.