Start here, because these are the ones that catch careful people.<\/p>\n
They agree with everything in your brief.<\/strong> The most dangerous signal in this article. Enthusiastic agreement feels like a supplier who understands you and is easy to work with. What it usually means is either they have not read the brief properly, or they will build whatever you specify including the parts that are wrong, without comment.<\/p>\n Every brief has something questionable in it. You are not an expert in Shopify \u2014 that is why you are hiring one. A developer who reads your brief and finds nothing to challenge is not being agreeable; they are declining to supply the judgement you are paying for.<\/p>\n They quote immediately without questions.<\/strong> Fast quoting reads as responsive and efficient. It means they have not scoped your project. An accurate quote requires knowing your catalogue complexity, your apps, your integrations<\/a>, your content volume, and your existing SEO position. Nobody can know those from a two-page brief, so a same-day quote is a number attached to assumptions you have not seen.<\/p>\n They promise an unrealistically short timeline.<\/strong> Appealing, especially under pressure. A migration for an established store is not a two-week project, and anyone saying it is has either not understood the scope or is planning to skip the parts that protect you \u2014 usually the redirect map and the testing.<\/p>\n They are dramatically cheaper than everyone else.<\/strong> Sometimes legitimate. Usually it means a smaller scope than you think you are buying. Ask what is explicitly excluded, and compare against the other quotes line by line.<\/p>\n They say yes to everything technically.<\/strong> “Can Shopify do X?” answered with an unqualified yes, repeatedly, across things that have real constraints. Shopify has genuine limits<\/a> \u2014 option counts, checkout customisation below Plus, native filtering. A developer who never mentions a constraint either does not know them or will discover them mid-build.<\/p>\n They never deliver bad news in the sales process.<\/strong> Related to all of the above, and the underlying pattern: if nothing uncomfortable is said before you sign, nothing uncomfortable will be said afterwards either, and you will hear about problems late.<\/p>\n No discovery phase for a substantial project.<\/strong> Starting to build on Monday with no specification is how scope disputes happen. For anything beyond a small task, some form of discovery is not optional.<\/p>\n No mention of testing<\/a>.<\/strong> Ask what testing consists of. A vague answer, or an assumption that you will test it, tells you where quality is going to come from.<\/p>\n No staging environment.<\/strong> Working directly on a live theme is how stores break during business hours. This is a basic professional practice and its absence is a genuine warning.<\/p>\n No version control.<\/strong> If you are told changes are made directly in the theme editor with no version history<\/a>, there is no way to undo a bad change cleanly, and no record of what happened when.<\/p>\n No documentation or handover discussed.<\/strong> The signal that you are being made dependent, whether deliberately or through carelessness. Ask what a successor developer would need, and listen to how readily it is answered.<\/p>\n SEO treated as separate or optional on a migration.<\/strong> The single most expensive process failure. If nobody on the call raises the redirect map<\/a>, the content preservation, and the post-launch monitoring before you do, they do not consider it their job \u2014 and a technically clean migration<\/a> that loses a third of your traffic is still a failure.<\/p>\n No plan for what you owe them.<\/strong> A developer who has not told you which content, images, data, and decisions they need and by when has not managed a project before, and the resulting delay will be blamed on you.<\/p>\n Vagueness about who does the work.<\/strong> Ask for names and experience. Resistance here usually means either a junior team or undisclosed subcontracting.<\/p>\n The senior person you are talking to will not be involved.<\/strong> Normal and fine if disclosed; a problem if implied otherwise. Ask directly how much of their time your project gets.<\/p>\n Undisclosed subcontracting.<\/strong> Ask whether any of the work goes outside the firm. Subcontracting is not automatically bad and concealing it is.<\/p>\n No reference for a comparable project.<\/strong> Portfolio pieces much smaller or simpler than your project, with nothing similar available, is informative. So is reluctance to arrange a conversation rather than supplying a written testimonial.<\/p>\n Testimonials you cannot verify.<\/strong> First names only, no company, no role, no way to check. Increasingly common and worth noticing.<\/p>\n High staff turnover, if you can detect it.<\/strong> Hard to assess from outside, but worth asking how long the team has been together. Continuity in the team is continuity for your project.<\/p>\n Large upfront payment with no deliverable milestones.<\/strong> Stage payments against things you can see. A substantial sum before any output leaves you with no leverage and all of the risk.<\/p>\n No written scope.<\/strong> Verbal agreement about what is included is how every scope dispute begins. If it is not written, it is not agreed.<\/p>\n They will not put custom code ownership in writing.<\/strong> Work you paid for should be yours. Any arrangement where custom development remains the agency’s property is a constraint you will feel when you want to leave.<\/p>\n No change request process.<\/strong> “We’ll be flexible” means no process and a difficult conversation later. You want to know how changes are assessed and priced before you need one.<\/p>\n They own your accounts.<\/strong> Your Shopify admin, domain, and app accounts should be in your name with you as owner. A developer who sets these up under their own account has created a hostage situation, usually without intending to.<\/p>\n Aggressive contract terms on termination.<\/strong> Long notice periods, penalties, or arrangements that make leaving expensive. Read this section specifically.<\/p>\n Pressure to sign quickly.<\/strong> Discounts expiring, slots filling, urgency generally. A good developer with a full pipeline does not need to rush you.<\/p>\n A furniture retailer hired a developer for a WooCommerce migration. In hindsight the client identified three signals from the sales process, each of which they had noticed and explained away.<\/p>\n First, the quote arrived within four hours of a two-page brief, with no questions. They read this as impressively responsive.<\/p>\n Second, when they asked about their custom shipping calculator \u2014 which handled oversized item rates by postcode zone \u2014 they were told it would be “no problem”. No questions about how it worked, what the rules were, or whether Shopify’s native rates could express them. They read this as reassuring expertise.<\/p>\n Third, the timeline was three weeks for a store with 1,200 products, 400 blog posts, and eight years of accumulated content. They read this as efficiency, and it suited a deadline they had.<\/p>\n The migration launched late, at seven weeks. The shipping calculator did not work, because nobody had established that their zone logic could not be expressed in Shopify’s native shipping rules and would need custom development. Their blog posts returned 404s because no redirect map had been built. Their collection page content was gone.<\/p>\n They spent four months and a substantial second budget on repair.<\/p>\n Each of the three flags pointed at the same underlying problem: nobody had scoped the project. The fast quote, the confident “no problem”, and the short timeline were all symptoms of the same absence, and any one of them examined properly would have revealed it.<\/p>\n Some problems only become visible after you start. These warrant immediate action rather than patience.<\/p>\n Communication going quiet.<\/strong> The single most reliable predictor of a bad outcome. A developer who stops responding is almost always hiding something, and the gap between the problem and your knowledge of it is where the damage accumulates.<\/p>\n No visible progress on staging.<\/strong> If you cannot see the work developing, you cannot verify anything. Insist on access from week one.<\/p>\n Every clarification becoming a change request.<\/strong> A sign the scope was never agreed properly, and that the relationship is heading somewhere adversarial.<\/p>\n Requirements you agreed to being treated as new.<\/strong> Keep written records of decisions. This protects both sides, and its absence favours whoever has the better memory.<\/p>\n Deadlines slipping without notice.<\/strong> Slippage happens. Slippage you discover yourself is a process failure.<\/p>\n Work going live without your review.<\/strong> A serious professional failure and a sign there is no process at all.<\/p>\n Defensiveness when you raise a concern.<\/strong> How a supplier receives criticism in month two predicts how they will handle a real problem in month four.<\/p>\n If two or more of these appear, address it directly and in writing rather than hoping it improves. And consider what your position would be if you had to change supplier \u2014 which is much stronger if you own your accounts, have staging access, and have paid in stages.<\/p>\n Worth covering, because anxious clients reject good suppliers for the wrong reasons and some genuine positives read as negatives.<\/p>\n Pushing back on your brief.<\/strong> This is the strongest positive signal available and it frequently feels like difficulty. A developer who tells you a feature will not work, or that your approach will cause a problem, is doing the most valuable part of the job. Being disagreed with in a sales conversation is a good sign, not friction to avoid.<\/p>\n Refusing to quote without discovery.<\/strong> Reads as evasive or as an attempt to charge for a proposal. It usually means they take scoping seriously and have been burned by quoting blind. A paid discovery phase that produces a written specification is good value even if you then take that specification elsewhere.<\/p>\n Admitting they have not done something before.<\/strong> Far more trustworthy than a claim of universal expertise. Nobody has done everything, and a developer who identifies their weakest area and explains how they will handle it is telling you something a confident generalist will not.<\/p>\n A higher quote than others.<\/strong> Not a flag in itself. It frequently means a wider scope, a more thorough process, or more realistic risk pricing. Normalise the scopes before drawing conclusions, and the expensive quote is often the accurate one.<\/p>\n Being busy.<\/strong> A developer with a waiting list is usually a good developer. Immediate availability is not automatically a warning, but full capacity is mildly reassuring rather than inconvenient.<\/p>\n Not being the cheapest, and saying so.<\/strong> An agency that tells you plainly that they are not the low-cost option is being straight with you.<\/p>\n A small team.<\/strong> Small does not mean less capable, and being an important client to a small team usually beats being a minor account at a large one.<\/p>\n Asking about your budget.<\/strong> Sometimes read as an attempt to price to your wallet. More often it lets them tell you what is achievable within your range rather than producing a proposal you will reject, which saves everybody a round.<\/p>\n Declining your project.<\/strong> A developer who says your project is not a good fit for them has just done you a favour and demonstrated judgement most of their competitors lack.<\/p>\n![\"Four](\"https:\/\/www.liquidwebdevelopers.com\/blog\/wp-content\/uploads\/2026\/10\/262-red-flags.svg\")
<\/span>The flags about process<\/span><\/h2>\n
<\/span>The flags about people<\/span><\/h2>\n
<\/span>The flags about commercial terms<\/span><\/h2>\n
<\/span>A worked example: three flags, ignored<\/span><\/h2>\n
<\/span>Flags during the project<\/span><\/h2>\n
<\/span>The things that are not red flags<\/span><\/h2>\n
<\/span>A short pre-signing checklist<\/span><\/h2>\n