These twelve are ordered roughly by how much they reveal. For each, what a good answer sounds like and what a bad one tells you.<\/p>\n Why it matters more than anything else.<\/strong> This separates advisors from order-takers, and the difference determines whether you get what you asked for or what you needed. An agency that builds exactly what you specified, including the wrong parts, has technically delivered and practically failed you.<\/p>\n A good answer<\/strong> names one or two specific things, explains the reasoning, and proposes an alternative. It may be uncomfortable to hear. Someone telling you a feature you are attached to will not work is demonstrating precisely the judgement you are buying.<\/p>\n A bad answer<\/strong> is enthusiastic agreement. “It all looks great, we can definitely do that” means either they have not read it properly or they will not tell you when you are wrong. Both are expensive.<\/p>\n Why it matters.<\/strong> Every project has a riskiest part. An agency that has identified yours has thought about it; one that has not will discover it mid-build, at your expense.<\/p>\n A good answer<\/strong> is specific and technical: your ERP integration<\/a>, your variant complexity, your content volume, your subscription migration, the fact that nobody knows what a previous developer did to your theme.<\/p>\n A bad answer<\/strong> is reassurance. “Nothing really, we do this all the time.” Either they are not looking or they will not tell you about problems, and the second is worse.<\/p>\n Why it matters.<\/strong> The person selling is frequently not the person building. That is normal and fine \u2014 what is not fine is not knowing, or discovering your project is staffed entirely by juniors with no oversight.<\/p>\n A good answer<\/strong> names people, describes their experience, explains who reviews code and how, and tells you who your day-to-day contact will be.<\/p>\n A bad answer<\/strong> is vague about staffing, or promises the senior person you are speaking to without explaining how that is possible alongside their other commitments. Also watch for undisclosed subcontracting \u2014 ask directly.<\/p>\n Why it matters.<\/strong> Process is what makes outcomes repeatable. An agency without one is improvising, which can work and cannot be relied on.<\/p>\n A good answer<\/strong> describes discrete phases with deliverables, names what happens in discovery, explains how testing works, and covers handover and documentation. It should include what they need from you and when.<\/p>\n A bad answer<\/strong> is a list of technologies, or something so generic it could describe any project. Follow up with “what does testing actually consist of?” \u2014 the specificity of that answer is informative.<\/p>\n Why it matters.<\/strong> A reference for a comparable project is worth ten portfolio pieces. And how the request is handled is itself a signal.<\/p>\n A good answer<\/strong> is yes, with a relevant introduction, promptly. When you speak to them, ask what went wrong and how it was handled \u2014 every project has something, and the answer tells you what you need to know.<\/p>\n A bad answer<\/strong> is reluctance, delay, or only offering written testimonials. Also be wary if the only available references are for much smaller or much simpler projects than yours.<\/p>\n Why it matters.<\/strong> Something will. What differs is whether anyone answers the phone.<\/p>\n A good answer<\/strong> describes a defined period of post-launch support, what is covered, response expectations, and what happens after that period \u2014 usually a maintenance arrangement<\/a>. It distinguishes between fixing their own defects, which should be free, and new work, which should not.<\/p>\n A bad answer<\/strong> is vague, or treats every post-launch issue as chargeable from day one. The second is a warning about how they view the relationship.<\/p>\n Why it matters.<\/strong> You will have changes. How they are handled determines whether the project stays collaborative or becomes adversarial.<\/p>\n A good answer<\/strong> describes a process: how a change is raised, how it is assessed for impact on cost and timeline, who approves it, and what the rate is. It should also acknowledge that some changes are small enough to absorb.<\/p>\n A bad answer<\/strong> is either “we’ll be flexible”, which means no process and probably a dispute later, or an aggressively transactional approach where every clarification becomes a change order.<\/p>\n Why it matters.<\/strong> Projects overrun on client dependencies at least as often as on development. An agency that has thought about what you owe them has managed projects before.<\/p>\n A good answer<\/strong> is a specific list with dates: content, images, product data, access credentials, decisions, approvals. It should include what happens if you are late, because you will be.<\/p>\n A bad answer<\/strong> is silence on this, or a general request for content with no deadline. That is a project that will overrun and it will be partly your fault, which is an unpleasant position.<\/p>\n Why it matters.<\/strong> Nobody has done everything. Someone who claims otherwise is either inexperienced enough not to know what they do not know, or willing to misrepresent.<\/p>\n A good answer<\/strong> identifies a genuine gap and explains how they will handle it: research time, a specialist partner, a conservative estimate, or a recommendation that you find someone else for that part.<\/p>\n A bad answer<\/strong> is a claim of comprehensive expertise across everything. The specific things worth probing are subscriptions, ERP integrations, Plus functionality<\/a>, and migration SEO, because these are where confident inexperience is most expensive.<\/p>\n Why it matters.<\/strong> On a migration<\/a> or a rebuild, this is the difference between keeping your organic traffic and losing a third of it. Many competent developers treat it as somebody else’s job.<\/p>\n A good answer<\/strong> mentions crawling the existing site before changes, a complete redirect map<\/a> covering all URL types rather than just products, preserving content and metadata on ranking pages, structured data<\/a>, and post-launch monitoring. If they raise this before you ask, that is a strong signal.<\/p>\n A bad answer<\/strong> is “we’ll set up the redirects” with no further detail, or treating it as an optional extra. On a migration, this question alone can eliminate half a shortlist.<\/p>\n Why it matters.<\/strong> You should be able to leave. An agency that makes leaving difficult has an incentive problem, and you want to know before you are dependent.<\/p>\n A good answer<\/strong> describes documentation, credential transfer, code access, an explanation of any custom work, and a willingness to brief a successor. Custom code should be yours, and the contract should say so.<\/p>\n A bad answer<\/strong> is vagueness, or any arrangement where custom work remains their property, or a store built so that only they can maintain it. Ask specifically: “if we hired someone else next year, what would they need from you?”<\/p>\n Why it matters.<\/strong> The answer reveals self-awareness, and self-awareness correlates strongly with good outcomes. It also tells you whether you are a good fit, which matters as much as capability.<\/p>\n A good answer<\/strong> is honest and specific. “We work well with clients who can make decisions quickly and badly with committees.” “We are not the right choice if you want the cheapest option.” An agency that can describe who they are wrong for is describing real experience.<\/p>\n A bad answer<\/strong> is “we work with everyone”. Nobody works well with everyone, and claiming to means either no reflection or no honesty.<\/p>\n A supplements brand shortlisted three agencies for a Plus build with a subscription component. All three had good portfolios and credible references.<\/p>\n Question nine \u2014 which part have you done least often \u2014 produced three different answers.<\/p>\n The first said they had extensive experience across everything in the brief. Pushed on subscription migration specifically, they described a process that made clear they had not moved a live subscriber base before, and had not considered payment token portability at all.<\/p>\n The second said subscriptions were their weakest area, recommended a specialist partner they had worked with, and priced the project with that partner involved.<\/p>\n The third said they had done subscription builds but never a migration of existing subscribers, proposed a paid discovery phase specifically to establish payment token portability before committing to an approach, and said they would recommend against proceeding if the tokens could not transfer.<\/p>\n The brand hired the third. During discovery it emerged that tokens could transfer but only for subscribers on one of their two historical payment configurations \u2014 about 80% of the base. That finding changed the whole plan and was worth many times the cost of discovery.<\/p>\n The first agency would have found this in month three, with a fixed price and a deadline, and the brand would have lost a meaningful share of their recurring revenue.<\/p>\n One question, asked of three competent-seeming agencies, produced three answers of radically different value.<\/p>\n Send the brief in advance<\/strong> and ask them to come with questions. How they respond to a brief in writing tells you a lot before you speak.<\/p>\n Ask the same questions to everyone,<\/strong> so you can compare.<\/p>\n Take notes on specificity,<\/strong> not enthusiasm. Specific answers indicate experience; enthusiastic ones indicate sales skill.<\/p>\n Notice who asks you questions.<\/strong> An agency that interrogates your brief is doing the thing you want them to do on your project.<\/p>\n Pay attention to bad news delivery.<\/strong> Anyone who tells you something you do not want to hear in a sales call will tell you things you do not want to hear during the project, which is exactly what you need.<\/p>\n Do not decide in the meeting.<\/strong> Write up what you heard, compare, and follow up on anything vague. Vagueness that survives a follow-up question is a finding.<\/p>\n Consider a paid discovery phase<\/strong> with your top choice before committing to the full project. It is the single best way to test a working relationship, and it produces a better-specified project regardless of who builds it.<\/p>\n The conversation runs both ways, and an agency’s questions tell you as much as their answers. If nobody asks you most of these, they are not scoping your project \u2014 they are quoting a template.<\/p>\n What does your catalogue actually look like?<\/strong> Product count, variant complexity, how many options your most complicated product has, whether you have configurable or personalised items. This determines whether Shopify’s structure fits without workarounds.<\/p>\n What apps and plugins are you currently running, and what does each do?<\/strong> On a migration this is the largest source of hidden scope, and an agency that does not ask will discover it in week six.<\/p>\n What systems does your store talk to?<\/strong> Accounting, ERP, 3PL, POS, email, reviews, loyalty. Each integration is work, and the ones nobody mentions are the ones that overrun.<\/p>\n Where does your traffic come from, and which pages produce revenue?<\/strong> An agency that asks this is thinking about preserving what works rather than just building something new.<\/p>\n Who makes decisions, and how many people need to approve things?<\/strong> Experienced agencies ask because approval chains drive timelines more than development does.<\/p>\n What have you tried before, and what went wrong?<\/strong> Both about the store and about previous suppliers. It shapes how they work with you.<\/p>\n What does success look like in six months?<\/strong> If nobody asks what you are trying to achieve, nobody is going to tell you when your brief works against it.<\/p>\n What is your timeline driven by?<\/strong> A trade show, a season, an investor deadline, or nothing in particular. This changes how they would phase the work.<\/p>\n What is your budget range?<\/strong> Some clients resist answering this, understandably, but an agency that knows the range can tell you what is achievable within it rather than quoting something you will reject. Withholding it usually costs you a round of proposals.<\/p>\n Who will run the store day to day after launch?<\/strong> This determines how much flexibility the build needs and how much documentation and training matters.<\/p>\n The hiring decision is the beginning. A few things done at the start change how the next three months go.<\/p>\n Agree the communication rhythm explicitly.<\/strong> Which day the call is, who attends, what gets written down, where questions go. Ad hoc communication degrades into whoever shouts loudest.<\/p>\n Nominate one decision-maker on your side.<\/strong> Multiple people giving conflicting direction is the most common client-side cause of project failure, and it is entirely self-inflicted.<\/p>\n Meet your delivery dates for content and approvals.<\/strong> Client delay is the single largest cause of overrun. If you will be late, say so early rather than letting the agency discover it.<\/p>\n Ask for a staging environment from week one<\/strong> and look at it regularly. Problems found early are cheap.<\/p>\n Write down decisions.<\/strong> “We agreed to drop that” means nothing in week nine without a record, and this protects both sides.<\/p>\n Raise concerns immediately.<\/strong> Clients frequently sit on a worry for a fortnight because they do not want to seem difficult. That fortnight is often the difference between an adjustment and a rebuild.<\/p>\n Assume the first estimate will move.<\/strong> Something always emerges. Holding a contingency and expecting a conversation about it is more productive than treating every change as a breach.<\/p>\n Plan for the handover before you need it.<\/strong> Ask for documentation as work progresses rather than as a final deliverable that gets rushed.<\/p>\n Portfolios and case studies tell you what an agency can produce under ideal conditions. These questions tell you how they will behave when your project gets difficult, which is the thing that actually determines the outcome.<\/p>\n The three that reveal most: what would you change about our brief, what worries you most, and which part have you done least often. All three reward honesty and punish sales polish, which is precisely why they work.<\/p>\n And weight one signal above the rest. The agency that tells you something uncomfortable in the first conversation is the one that will tell you when a project is going wrong early enough for you to do something about it.<\/p>\n The single most revealing question is what they would change about your brief. An agency that names specific things, explains the reasoning, and proposes alternatives is demonstrating the judgement you are actually buying; one that agrees enthusiastically with everything will build the wrong thing without comment. Follow it with what worries them most about the project, which part of it they have done least often, and who will actually write the code and review it. Those four questions reward experience and honesty while being difficult to answer well through sales polish.<\/p>\n![\"Seven](\"https:\/\/www.liquidwebdevelopers.com\/blog\/wp-content\/uploads\/2026\/10\/258-twelve-questions.svg\")
<\/span>1. “What would you change about our brief?”<\/span><\/h2>\n
<\/span>2. “What worries you most about this project?”<\/span><\/h2>\n
<\/span>3. “Who will actually do the work, and who reviews it?”<\/span><\/h2>\n
<\/span>4. “Walk me through your process from kickoff to launch.”<\/span><\/h2>\n
<\/span>5. “Can I speak to a client whose project was similar to ours?”<\/span><\/h2>\n
<\/span>6. “What happens when something goes wrong after launch?”<\/span><\/h2>\n
<\/span>7. “How do change requests work, and what do they cost?”<\/span><\/h2>\n
<\/span>8. “What do you need from us, and when?”<\/span><\/h2>\n
<\/span>9. “Which part of this project have you done least often?”<\/span><\/h2>\n
<\/span>10. “How will you handle the SEO side of this?”<\/span><\/h2>\n
<\/span>11. “What does handover include, and what happens if we leave?”<\/span><\/h2>\n
<\/span>12. “What kind of client do you work best with \u2014 and worst with?”<\/span><\/h2>\n
<\/span>A worked example: the question that ended a shortlist<\/span><\/h2>\n
<\/span>How to run the conversation<\/span><\/h2>\n
<\/span>Questions they should be asking you<\/span><\/h2>\n
<\/span>After you choose: setting the relationship up well<\/span><\/h2>\n
<\/span>The bottom line<\/span><\/h2>\n
<\/span>Frequently asked questions<\/span><\/h2>\n
<\/span>What should I ask a Shopify agency before hiring them?<\/span><\/h4>\n
<\/span>How can I tell if a Shopify agency is any good?<\/span><\/h4>\n