Guide
How to write a Shopify freelancer proposal
A Shopify proposal should make the client feel that you read the job. Most proposals fail before the pricing section because they begin with a biography, a list of tools, or a promise to build anything. The client still does not know how you would handle their store.
Short answer
Start with one detail from the brief. Explain the first step you would take, list the deliverables, state the main assumption, and ask one question. Give a price or a clear condition for narrowing it. Keep the document short enough to read before a call.
Start with the store problem
A proposal for a theme edit should mention the theme or the visible behavior. A migration proposal should mention data, URLs, or the launch plan. An app integration proposal should mention the two systems and the event that connects them.
For example:
"The product page works on desktop, but the variant picker leaves the add-to-cart button below the fold on a narrow phone screen. I would reproduce that in a duplicate theme before changing the section code."
Only write what you actually saw in the brief or public store. If you have not tested the store, say that the point is something to confirm. Specific does not mean certain.
AiProposer's Shopify template (June 2026) leads with a diagnosis, a Shopify-specific approach, deliverables, and a closing call to action. It also says that opening with credentials tells the client nothing they do not already expect from every applicant. That order is useful because it puts the client's concern before your background.
Explain the first step
The first step protects both sides. For a theme job, it might be reproducing the issue in a duplicate theme and checking whether an app injects the behavior. For a migration, it might be mapping products and URLs before quoting the build. For an integration, it might be checking the available events and the client's current plan.
Do not call a discovery step free if it is really a project. Say what you will inspect and what the client receives. A small paid review can come before a larger fixed scope.
If you have relevant work, add one short line after the approach. Do not add a client name, result, or number you cannot prove.
List deliverables and exclusions
A deliverable is something the client can check. "Improve the website" is an activity. "Update the product template, test three variants on mobile, and hand back the changed theme" is checkable.
For a small theme job, the list might include:
- reproduce the reported issue in a duplicate theme
- change the agreed section or template
- test the stated browsers and screen sizes
- check cart behavior after the change
- record the files changed and hand back the theme
Then list what is outside the quote. It may be app conflicts, new sections, copy, product data, checkout changes, or work on another theme. A short exclusions line prevents a one-hour fix from turning into a redesign.
RuleDox's Shopify proposal template (updated February 2026) separates the proposal from the scope of work. The scope holds deliverables, exclusions, responsibilities, acceptance criteria, and a change process. RuleDox sells proposal software, but the split solves a real problem, and you can copy it in a plain document.
Give a price without guessing
If the task is clear, use a fixed price and state what it covers. If the task depends on the theme, app count, or an unclear bug, give a discovery price first or provide a range with the condition that changes it.
Write payment triggers in plain language. For example, "The fixed price covers the listed change and one round of checks. New sections are quoted separately." Do not hide third-party app fees or subscriptions inside your own fee.
Pricing pages written by sellers show very different price points. That is evidence that prices vary by provider and scope, not evidence of an average. Your own past jobs, time required, risk, and the client's requested outcome are better inputs.
For broader questions about fixed fees and support plans, see how to price n8n and Make automation work. For recurring Shopify support, see Shopify store care retainers.
End with one useful question
Ask something that changes the scope. Examples:
- Is the problem present in a duplicate theme too?
- Which theme should remain live while the change is tested?
- Does the app need to send data at checkout or after payment?
- Is the launch date fixed, or can the work be split into phases?
One good question is better than a list of questions that asks the client to do your discovery work.
A simple proposal outline
Use this order:
- One sentence about the problem you saw.
- Your first step and the reason for it.
- Deliverables.
- Exclusions and client responsibilities.
- Timing and price or the condition that sets the price.
- One relevant proof line, if you have one.
- One question.
AnyGen's ecommerce proposal template includes launch, dependencies, acceptance, and handover. You do not need every section for a small task. Add the ones that affect this store.
Shopify's own partner blog has a proposal guide, but it is from 2016 and describes a ten-part agency document with a cover page, team section and signature page. A solo freelancer quoting a small fix rarely needs that much.
Read it back before you send it
Read the proposal as the store owner would. Could they tell, in under a minute, what you will do first, what they get, and what you need from them? If a sentence only describes you, cut it or move it below the plan. If a sentence makes a promise you cannot check yet, change it into an assumption. Short proposals with one clear next step are easier to answer than long ones that try to cover every outcome.
What to do after sending
Do not send five follow-ups that repeat the proposal. If the client replies, update the scope from the new fact. If they go quiet, keep the draft and note what was unclear. That record improves the next proposal.
Thomas Partners brings client work to freelancers. You keep 90% of the profit after documented costs are repaid. Apply to join.
FAQ
How long should a Shopify proposal be?
For a small fix, a page is often enough. A migration or rebuild needs more detail about data, redirects, testing, and handover.
Should I include a portfolio link?
Yes, if it is relevant and real. Link to one or two examples instead of a gallery of unrelated work.
Should I promise a launch date?
Only when the client dependencies and approval steps are known. Otherwise state what the date depends on.
What if I have no client examples?
Use a clearly labelled demo. Explain what you built, what data it uses, and what you did not test. A demo is useful proof of method, not proof of a client result.
Sources
- AiProposer, Shopify Proposal Template for Upwork Freelancers (2026): https://aiproposer.com/templates/upwork-shopify-development-proposal
- RuleDox, Shopify Agency Proposal Template: https://ruledox.app/content/shopify/shopify-agency-proposal-template
- AnyGen, Ecommerce Development Proposal Template: https://www.anygen.io/showcase/ecommerce-development-proposal-template/index.html
- Shopify Partners blog, The Ecommerce Proposal Guide for Shopify Experts (2016): https://www.shopify.com/partners/blog/the-ecommerce-proposal-guide-for-shopify-experts
Tell me what you build and who you build it for. It takes a few minutes.