- Get clear on which Shopify jobs you’re taking on before you quote (it’s very easy to accidentally become an entire eCom department).
- Define a core package you can use for every full build. Mine’s a two-week storefront design and build, and we add what each store needs from there.
- Give add-ons their own scope and time in the calendar. Building the infrastructure around + populating 300 products deserves a proper chunk of the project.
- Have a snoop before the disco call. If their filters are a mess or every product page looks different, you’ve already got something useful to ask about.
- Build 3–5 flex hours into the proposal for the little “could we also…?” requests. Agree how long they’re available after launch, too.
A potential client asks you to build “a Shopify website,” and you’re already daydreaming about how sexy the product page will look and poring over your database of eCom site inspo getting super excited about the build ahead.
BUT. Before you can quote the project, you need to get a really good understanding of the exact responsibilities you're taking on for this project, for the sake of your clients' sanity and your own.
I always make sure to get clear on things like:
- Do they have 12 products already uploaded, or 300 that need moving over from another platform?
- Are you only designing the main pages, or are you also on the hook for things like setting up subscriptions or building a wholesale portal?
- Who’s supplying the product descriptions and organizing the tagging + collections?
These details all heavily influence the scope, price, and timeline. And the thing that trips up newer-to-Shopify designers is the feeling of overwhelm that comes with the multitude of moving parts that could possibly play a role in a Shopify project.
Today I'm peeling back the curtain on how I scope my Shopify projects, and I'll be going through my "signature" core Shopify build, why pairing this with add-ons is the move, and the things I make sure to clarify with clients before we start.
If you're a designer getting into Shopify, I hope this gives you a few "aha" moments that make you feel way more confident taking that next discovery call. And if you're a brand owner considering a project with me, you'll get a good feel for how we collaboratively decide what your store needs.
First thing to understand: Shopify does A. LOT.
When the average person thinks of "Shopify", they think of the customer-facing, nicely-merchandised frontend design.
What they don't realize is that this is just the tip of the eCom iceberg.
The backend admin of Shopify packs a whole lotta punch when it comes to all of the tools and settings and capabilities it offers.
Product data! Inventory! Shipping! Payments! Taxes! Policies! Retargeting Flows! Notification emails! The list goes on, and I'm constantly impressed how polished each and every corner of the Shopify platform is as a whole.
With a brick-and-mortar store, you'd hire separate people to design the space, set up the stock system, and handle the accounts.
With Shopify, because all of these jobs live under the same roof, it's easy to mentally group them together when you're talking about “the website".
But designers + developers aren't accountants, supply chain specialists, or email marketing gurus (usually).
So before quoting a Shopify project, it's important to work out which tasks the designer/developer will take on, which the client will handle, and where another specialist might be needed.
When a client asks for subscriptions, for example, I want to know what they're selling, how often it ships, what customers can change, and what needs to appear on the product page.
What's cool about being a Shopify designer is that you can decide which of these services you want to offer, and add more services to your "I can do this for you" list over time.
Perhaps organizing a big product catalog makes your brain happy. Or you might have an email specialist bestie you regularly work with. Whatever it is, it's important to understand your own expertise well and explain it to clients early.
The importance of a "this is the bare minimum" core package
I used to spend a whole lotta time scoping every project inquiry that came through my door from scratch.
It usually went like this: I'd hop off a really fun discovery call, open a blank document, and try to work some black magic figuring out how long every piece would take. Proposals took ages and resulted in like 20 new gray hairs each time.
After I had enough Shopify projects under my belt, I got a good sense of the things I was doing over and over again on every single full Shopify build.
I'm talking the same main pages, navigation setup, a consistent styling system, product and collection templates, and time to check everything on mobile.
So, I had a "let's make this whole thing way more efficient" burst of energy, and said "Voila! Here's my signature build".
It's a two-week storefront build using Dawn with all of my custom sections and code (my clients' world is their oyster when it comes to the store design—I love pushing the boundaries and going far beyond what a theme offers).
The core build package encompasses what pretty much every single Shopify store would need during a project: it includes things like the home/product/collection pages, but excludes things that not every brand wants/needs (like a wholesale inquiry page)—that'd be an add-on.
This core build package + add-ons approach gets the best of both worlds when it comes to a "productized" signature service and accounting for the variation in client needs. With this approach I get to offer a super-optimized, buttery-smooth project process for my clients without forcing them into a box.
I'm able to pull off a two-week core build timeline works because I've spent years building a library of custom-coded sections that I can use across projects. It was my own secret weapon for a long time, but I decided to make it available to other Shopify designers at The Section Studio.
The add-ons that give clients what they need
One client might have a tiny catalog, all their copy and photography ready, and no real need for a ton of apps.
Whereas another one might need help with hundreds of products with complex variant requirements, a customizable subscription box, and a robust wholesale setup.
I handle these differences via "add-ons" on top of the core build. Each add-on listed in my proposals gets a clear description of what it includes and where it fits into the overall timeline.
| The request | What needs fact-finding |
|---|---|
| Additional pages | Which pages, the general depth/complexity of each one, and any particular special functions that the pages will need (store locator, wholesale, subscriptions, build-a-box etc). |
| Product uploads | How many products and variants there are, how the information will be supplied (organized spreadsheet, or "here's a bunch of links from the supplier"), and whether the work includes cleaning up descriptions or images. |
| Collections and filters | How products will be grouped, whether a custom mega menu is needed, what information customers should be able to filter by, and who'll organize the product data. |
| App setup | The app and features involved, whether it's the entire app that's being set up or just a subset of its capabilities, any styling, and the checks needed before launch. |
| Blog migration | How many posts are moving, what happens to the images and formatting, whether multiple blog post templates are required, and how existing URLs will be handled. |
It's easy to underestimate the potential complexity of product organization at first glance.
Beyond the obvious cleaning + uploading of product data such as pricing/inventory/descriptions/variants etc., properly building the infrastructure to house a catalog of 50+ products involves a lot of to-do list items.
When clients come to me with a sizeable catalog like this, we:
- Decide on the high-level product categories needed
- Define which collections fall under these main categories
- Build a metaobject library and tag taxonomy
- Populate all of the products with these metaobjects and tags where relevant
- Build filtering infrastructure using these metaobjects and tags
- Build a site nav (header, mega menu, and footer) that gets people where they need to go, fast
That's a meaningful amount of work that a lot of 1 to 10-ish product stores don't need, which is why it's separate from a baseline build.
If you're getting into that side of Shopify yourself, my guide to creating collections is a useful place to start.
If a client asks for something that's out of my wheelhouse, I love recommending a specialist to them who I know can get the job done way better.
Lately things like email marketing (beyond just a basic welcome email or two), detailed analytics work, fulfillment integrations, and product photography are all areas I find myself referring clients to quite a bit.
The pre-discovery-call snoop
If a potential client already has an online store, I love to spend some time perusing it before we chat.
I spend some time getting the lay of the land when it comes to their navigation, collections, product pages, mobile experience, technical health, and any features that seem important to the business.
Even just a 20 minute look usually tells me a lot. I might uncover that the menu has several overlapping categories, the hero is loading a 57MB video before anything appears, or collection filters include “Blue,” “blue,” and “Navy Blue” as separate options.
This helps me 1. offer instant value to merchants who hop on my discovery calls and 2. get an understanding of which areas beyond my core build package might need some tender love and care via an add-on.
I take great care to understand the whole picture before scoping a client project, because there's nothing worse than a good old bait-and-switch where a client thinks the project will be one thing only to be surprised by a laundry list of "oh we should totally do this but it wasn't included in your original scope of work".
The discovery (AKA disco 🕺🏼🪩) call
By the time we get on a disco call, I’ve already poked around a potential client's store and they’ve seen my investment guide.
I’ll have a few things I want to ask about (including any “wait, what’s happening here?” moments from my mission), and they’ll have a sense of how I work.
Then we can figure out how my core build fits what they need, which add-ons would be useful, and what they’re happy to handle themselves.
I want to hear what the client needs customers to do and what's making that difficult at the moment. Sometimes the design needs attention, sometimes the team struggles to update the store, quite often there's a bit of both.
A few questions I find useful:
- What are customers regularly asking you before they buy?
- Which parts of the store are difficult for you or your team to update?
- What needs to be ready for launch, and what could come later?
- Is there a particular date we need to plan around, such as a product launch?
As we talk, I start connecting those answers to the work.
Lately I find that clients really appreciate me taking an "okay, so here's what I think would help your store" kind of an approach, rather than a "okay, so would you mind listing which pages you want me to design again??" kind of one.
A juicy, answers-everything proposal
The surprise bonus that comes alongside my proposals
Lately, when my proposals land in potential clients' inboxes, I've been taking my "here are a few findings I found ahead of our discovery call" even further up a notch, including a free 30-ish minute video walkthrough audit of the current state of their store and room for improvement.
I find that this really helps contextualize the project—it helps the client understand what's not working, the potential there is for improvement, and why the project is scoped the way it is.
This video then easily segues into a live walkthrough of the proposal, where I explain it live in order to give more info around the plan ahead (and show my excitement for what's to come!).
What the proposal looks like
I open with a short introduction to the project and its main 4-6 goals. I think it's super important to step back and define these goals for the project before diving into the nitty gritty scope and timeline details, because it's important to get aligned on the things that will essentially serve as your north star for the project and its success.
Then I outline in depth the project deliverables, milestones, timeline, investment, and what I'll need from the client. I also include a short list of items that are NOT included in the project, so that the client is super clear on expectations and can put the right resources towards them if need be.
If we discussed a feature but decided that it's something we'll do after the initial project, I note that down too.
Wiggle room for the unknowns = the best thing ever
One of my FAVORITE changes I've made in my process in the last few year is the inclusion of what I call flex hours in my project scopes: a small bank of time (usually 3-5 hours) for additional work that comes up during the project or shortly afterwards.
Clients love these because they don't need to sweat about the occasional "oh could we actually add this too?" request that pops up, or the final few pieces of content or feedback that might roll in after our official project timeline wraps.
A larger request would still need its own scope, but these flex hours gives us a practical way to handle those smaller requests without needing to have the un-fun conversation of "yes we can get that done, but it will come at an extra fee!".
A super clear timeline = a super smooth project
You know what's the worst? Someone telling you something will take X amount of days/weeks/months, then it snowballs into 3 times the original estimate.
That's not the way I like to work, and that's not the way my clients like to work. So, since forever ago, I've always included super clear project timelines in my project proposals.
They cover when the pre-project milestones happen, when the client can expect updates along the way, and when their feedback is due.
I pretty much never have clients that are "late" with content or feedback throughout the process, which is awesome.
And clients think it's awesome when they get what they wanted in the timeline that was promised to them. Woohoo!
If you're a brand owner reading this
“Shopify website” can cover a very different amount of work depending on who you hire. When you’re comparing Shopify proposals, keep the following in mind:
- How precisely are the features scoped?
- How much design flexibility is included—AKA are you limited to just the layouts that your theme comes with? Are customization limits acknowledged?
- Does the build account for your different product types through clearly defined "I'm building X amount of product page templates for you"?
- Who's in charge of organizing the product data + catalog? Does the scope explain how the store will accommodate new products?
- Does the designer use Shopify's powerful metaobjects engine to manage reusable information across the store? (They should).
- Does the proposal list what's not included so that there are no misunderstandings?
- Will the handover teach your team how to manage this particular store?
If you're preparing for your first store, my 7 things to know before starting your Shopify store will help you get familiar with some of the decisions we'll make.
If you're a designer reading this
Whether you're jumping into scoping a Shopify project for the first time or are a seasoned vet looking to overhaul your proposal process, I recommend the following:
- Get clear on your core/signature build package—again, think of it as the "bare minimum" build where there are no extra pages, apps, or bells & whistles.
- Create a standardized timeline for this package that's easy and quick to pop into your proposals.
- Make sure that your proposals gives clear goals, deliverables, milestones, expectations, and guardrails.
- Go the extra mile ahead of your discovery calls and alongside your proposal sendoff emails to really take a close look at your potential clients' stores. This helps you both wow the client with the value you bring and set yourself up for a successful project that's way less likely to be under-scoped.
Brand owners who’ve made it this far, you’ve had a pretty thorough look at how I plan a Shopify project (thanks for hanging out with the designers). We’d start with my two-week core build, work out which add-ons your store needs, and get clear on who’s handling what before we book anything in.
Have a peek at my recent Shopify builds, or head to the inquiry form and tell me what you’ve got in mind. I’d love to hear about it.
