What's the most important section of a shopify development proposal?

The assumptions section. Most freelancers skip it or treat it as a footnote. The assumptions section is where you list every thing you're assuming about the project that, if wrong, changes the price. Stock count under 500 SKUs. Theme selection: client supplies, modifications under 20 hours. Existing brand assets ready. No third-party app development required. When the client provides 4,000 SKUs and wants three custom Shopify apps built, you point at the assumptions section and re-quote. Without it, you eat the extra work.

How do I price a shopify development proposal when scope is unclear?

Quote two phases. Phase 1 is a discovery sprint (1-2 weeks, fixed price 1.5-3k) that produces a detailed technical spec, app stack decision, theme decision, content plan, and final build estimate. Phase 2 is the build, quoted from the spec produced in phase 1. This protects both sides: the client doesn't commit to a 30k build they can't scope, and you don't quote a 30k build blind. About 80 percent of clients who buy phase 1 move to phase 2, usually because by then you've earned their trust.

Should I include app subscriptions and theme costs in the shopify proposal?

List them but separate them from your fee. Clients should see 'Shopify Plus subscription: 2,300/mo, paid directly by client to Shopify; required apps: Klaviyo (variable), Loox (39/mo), Rebuy (99/mo); theme purchase if Premium: 350 one-time, paid by client.' Mixing these into your fee makes your number look inflated and creates billing confusion. Listing them separately positions you as the operator who understands the full stack the client needs to budget for.

How do I handle the client who keeps adding 'small' features during a shopify build?

Use a change request log from day one. Every new request gets logged with an estimate. Anything under 1 hour: included as goodwill (cap at 5 hours total goodwill across project). Anything over 1 hour: written change request, priced, signed before work begins. Most scope creep happens because each request feels small. The log makes it visible. Clients who see 'you've added 14 hours of unscoped requests so far' usually self-regulate. Clients who don't are the ones you need the signed change requests from.

How long should a shopify development proposal actually be?

8-14 pages for most builds. Cover, project understanding, recommended approach (theme choice, app stack), detailed scope, assumptions, deliverables, timeline, investment, payment terms, terms and conditions, FAQ. Shopify builds have enough technical complexity that a short proposal feels unserious. But anything over 14 pages and the client stops reading. Save the deep technical detail for the spec document produced after phase 1 discovery.

The Shopify Build Proposal That Pre-Empties Scope Creep

Shopify builds look simple from the client side. Pick a theme, install some apps, add products, launch. Anyone who’s actually built one knows the work is in the seams: payment edge cases, shipping logic, inventory sync, abandoned cart flows, the 11 apps that conflict with each other.

The Shopify proposal that survives the project is the one that documents every seam before work begins. Most don’t, and the budget overrun starts in week two.

I’ve watched a friend lose three weeks of his life to a single sentence the client casually dropped on a kickoff call: “oh, and we sell to Canada and Europe too.” Multi-currency, multi-language, three new tax setups. He hadn’t listed those as out-of-scope in the proposal because it didn’t occur to him to. Now he lists everything, even the stuff that seems silly. Especially the stuff that seems silly.

The assumptions section is the proposal

In a normal proposal, assumptions are a footnote. In a shopify development proposal, assumptions are the load-bearing wall.

Real assumptions to list explicitly:

Stock count: under 500 SKUs at launch (above this, data migration is re-quoted)
Variant complexity: standard size/color variants only (custom variant logic is re-quoted)
Theme: client chooses from Shopify theme store or supplies existing custom theme; theme modifications capped at 20 hours
Apps: stack agreed in discovery; any new app added mid-build requires change request
Custom Shopify app development: not included
Content: copy and product descriptions provided by client by date X
Images: high-res product photography supplied by client; lifestyle photography not included
Email templates: 3 transactional templates customized (order confirm, shipping, abandoned cart); additional templates priced separately
Payment gateway: Shopify Payments + 1 alternative; additional gateways re-quoted
Shipping: standard rate-based shipping; custom shipping logic re-quoted
Multi-currency: single currency at launch
Multi-language: single language at launch
Subscription products: not included
B2B features: not included
Custom checkout: not applicable on standard plan; Plus features priced separately

That list is 16 items. It looks like overkill. It is not. Every one of those items is a real fight you’ve had or will have on a Shopify build that didn’t list them.

Two-phase engagement structure

The cleanest shopify development proposal is split into two engagements.

Phase 1: discovery and technical spec

Duration: 1-2 weeks
Fixed price: 1,500-3,500
Deliverables: technical spec document, app stack recommendation, theme decision, content plan, integration map, final build estimate with locked scope

Phase 2: build

Quoted from the spec produced in phase 1
Fixed price for the locked scope
Change requests handled via written log

This structure does three things. It protects you from quoting blind. It gives the client a small, low-risk first commitment. It produces an artifact (the spec) that anchors the build phase.

About 80 percent of phase 1 clients move to phase 2. The other 20 percent either decide Shopify isn’t right for them (which you helped them figure out, which they appreciate) or take the spec to another developer (rare, and you got paid for your thinking).

App stack recommendation, with reasoning

Clients respond well to recommendations they can see your reasoning behind.

Example app stack block:

Need	Recommendation	Cost	Reasoning
Email/SMS marketing	Klaviyo	~150/mo at start	Best segmentation, integrates cleanly with Shopify customer data
Reviews	Loox	39/mo	Photo reviews convert better than text-only; UI doesn’t bloat product pages
Bundles + upsell	Rebuy	99/mo	AI recommendations are above industry average; tracking is clean
SEO basics	Yoast for Shopify or Smart SEO	30/mo	Schema and meta management without dev work
Loyalty	Hold for phase 2	-	Premature for current order volume; revisit at 200 orders/mo

The “hold for phase 2” line is the move. It positions you as someone who doesn’t just sell every available app. It also seeds the next engagement.

Theme strategy in the proposal

Three theme paths, picked in discovery:

Off-the-shelf Shopify theme (Dawn, Sense, Studio) with light customization. Cheapest, fastest, most upgradeable.
Premium theme from Shopify Theme Store (Impulse, Prestige, Symmetry). Better aesthetics out of the box, more customization options, around 350 one-time purchase.
Custom theme build. 4-8x the cost, only justified for stores at scale or with truly distinct UX needs.

State the path in the proposal. Document which path the price assumes. If the client wants to upgrade paths mid-build, re-quote.

Pricing structure for shopify builds

A typical price range for a shopify development proposal (post-discovery):

Small build (off-the-shelf theme, standard apps, under 50 SKUs): 5-9k
Standard build (premium theme, customized apps, 50-500 SKUs, basic custom dev): 12-22k
Complex build (custom theme work, multiple integrations, large catalog): 25-50k+

The price should be specific to the spec produced in phase 1. Don’t quote ranges in the final build proposal; quote a number.

Payment structure

For Shopify projects:

Builds under 10k: 50/50 (signature/launch)
Builds 10-25k: 40/30/30 (signature/midpoint demo/launch)
Builds over 25k: 30/30/30/10 (signature/midpoint/launch/post-launch retention)

Avoid net-30. Most Shopify clients are owner-operated businesses without procurement departments. Net-30 just delays your cash flow.

Timeline that includes content dependency

The single most common reason Shopify builds slip is the client doesn’t deliver content on time. Build that into the timeline.

Standard timeline: 6-9 weeks from kickoff to launch.

Assumes:

Content (copy, product descriptions, image assets) delivered by end of week 2

Feedback on each milestone within 5 business days

App account access provided within 3 business days of kickoff

Each business day of delay on the above shifts the launch date by an equivalent day.

Don’t soften this. Clients respect timelines that come with dependencies. The ones who push back on dependency language are the ones who will absolutely miss every deadline and blame you.

Change request log, named in the proposal

State the change request process in the proposal itself.

Change requests during the build are welcome and handled through a shared log:

Requests under 1 hour of effort: included as goodwill, up to 5 hours total across the project

Requests over 1 hour: written estimate provided within 1 business day, signed before work begins

Estimates are billed at 150/hr, billed in 30-minute increments

Change requests that affect launch date trigger a timeline re-baseline

This sounds bureaucratic. It is. That’s the point. The proposal that prevents scope creep does so by making scope creep visible as it happens.

Post-launch support window

Include a post-launch support window in the base proposal. 14 days of bug fixes and small adjustments after launch, included. Anything beyond that is a separate engagement.

Post-launch support: 14 days of bug fixes and minor adjustments included after launch. Issues identified during this window are addressed at no additional cost. After day 15, ongoing work is handled through a separate maintenance retainer (priced separately) or via hourly engagement.

This protects you from the “well, you built it, you should fix it forever” client and gives you a natural lead-in to a maintenance retainer.

What a maintenance retainer for shopify looks like

Tag a maintenance retainer onto the shopify development proposal as an optional add-on.

Sample maintenance tiers:

Light (400/mo): monthly health check, app updates, 1 hour of small changes/mo
Standard (1,200/mo): above + 4 hours of changes, performance monitoring, monthly report
Full (3,000/mo): above + 12 hours of changes, conversion rate monitoring, weekly check-in

Many clients sign up for the retainer at launch because they’re nervous about the site breaking. The retainer turns a 15k one-time project into 15k plus 14k/year recurring. That’s the math worth showing in the proposal.

Ready to send stronger proposals?

Build, send, and track proposals in one place so follow-up is easier.

Start your free trial →