How to Choose an Ecommerce Agency: 10 Questions to Ask
The Standish Group's CHAOS research — one of the longest-running, most widely cited studies on software and technology project outcomes — has found across recent survey years that only around 29-31% of projects are considered fully successful: delivered on time, on budget, with the intended scope. The rest are either "challenged" (late, over budget, or missing features) or fail outright. Separately, the Project Management Institute's Pulse of the Profession research finds that 52% of projects experience scope creep, with an average cost overrun of 27% attributable to it. Hiring an agency and getting a bad outcome isn't bad luck — statistically, it's closer to a coin flip skewed against you.
This guide is built around 10 direct questions, each with what a strong answer actually sounds like versus the version that should make you pause. Before the questions, one thing worth being transparent about: a lot of "how to choose an agency" content on the internet is itself published by agencies competing for the same business, which creates an obvious incentive to make competitors look bad or make vague self-reported claims look like data. We've tried to keep this piece honest about which claims below rest on independent research and which are pattern-level observation — see the note after the questions.
Before the questions: understand what you're actually buying
The ten questions below work better once the pricing model itself is understood, because the same question can have a perfectly good answer under one pricing structure and a red-flag answer under another. Three models dominate ecommerce agency engagements, and each shifts risk differently between you and the agency:
| Model | How it works | Where risk sits |
|---|---|---|
| Fixed-bid | One price for a defined scope, agreed upfront | Agency absorbs the risk of underestimating; strong incentive for the agency to define scope narrowly and charge for anything outside it |
| Time & materials (T&M) | Billed by actual hours or days worked, no fixed ceiling | Client absorbs the risk of scope or timeline running long; requires more active client oversight of hours and progress |
| Retainer | A fixed recurring fee for an ongoing, ill-defined scope of work (support, iteration, optimization) | Shared risk — client risks paying for underutilized capacity; agency risks overservicing a demanding client for a fixed fee |
None of the three is inherently better — a well-scoped fixed-bid project for a narrow deliverable (a migration, a defined build) can be the lowest-risk option precisely because both sides know exactly what "done" means. A retainer makes more sense for ongoing work with no natural end point. The red flag isn't the pricing model itself; it's a pricing model mismatched to the actual nature of the work — a retainer for what's really a one-time project (which never has a clear end), or a fixed-bid quote for genuinely exploratory, poorly-defined work (which almost guarantees scope disputes once real requirements surface). Understanding which model you're actually being offered — and asking directly if it's ambiguous — should happen before any of the ten questions below, because the "right" answer to several of them shifts depending on which model is on the table.
The 10 questions to ask
1. Can you show me a live, production reference I can talk to directly?
A portfolio of polished screenshots proves an agency can produce polished screenshots. It doesn't prove the underlying build works, performs, or survived contact with real customers and real traffic. Asking for a live URL and a direct conversation with that client — not a testimonial quote the agency selected and edited — tests something a case study can't fake: whether a real client, unprompted, would say yes again.
Worth pushing further than the first reference offered: ask specifically for a client whose project is roughly your size and complexity, and ask what that client would say the agency's actual weaknesses are, not just its strengths. A reference who can name a genuine, specific limitation ("they're not the fastest on urgent turnarounds, but the quality is consistently high") is more credible than one who describes the agency as flawless — real working relationships have friction points, and a reference willing to name one is more trustworthy on the points where they praise the agency too.
2. Who exactly will work on my project, and can I meet them before signing?
A specific, structurally common failure pattern in outsourced development: a prospective client meets senior, experienced people during the sales process, signs the contract, and is then quietly handed off to a more junior team never introduced during evaluation. This isn't automatically a sign of bad faith — agencies do legitimately staff differently for delivery than for sales — but it needs to be disclosed and agreed upfront, not discovered after signing.
This pattern is structurally more common in high-volume outsourcing shops specifically, where the business model depends on billing at senior rates while the actual work is performed by less experienced staff — a margin structure that only works if the client doesn't notice the substitution until well after signing. It's worth asking not just who will work on the project, but how long that specific team typically stays assigned to a single client relationship, since a pattern of frequent reassignment even without an explicit bait-and-switch produces a similar loss of context and continuity.
3. What does your discovery process actually involve, and how long does it take?
Discovery — stakeholder interviews, a current-state audit, requirements gathering — is the phase that determines whether an agency is solving your actual problem or a guessed version of it. Research attributed to Forrester and cited across industry sources found that projects with a formal discovery phase were reported as roughly 2.7 times more likely to be delivered on budget and 3.1 times more likely to meet stakeholder satisfaction goals, compared to projects that skipped straight to execution.
The underlying logic is straightforward once stated plainly: a client rarely arrives at a first sales call with a perfectly accurate, complete description of the actual problem — they arrive with a description of the symptom they've noticed. "Our conversion rate is low" might really be a catalog data problem, a checkout friction problem, or a traffic-quality problem, and each of those has a completely different solution. An agency that quotes a fix before discovering which one it actually is has, at best, made a lucky guess. This is precisely the pattern discussed throughout this site's data engineering content: solving the wrong layer of a problem, confidently, is often worse than acknowledging you don't yet know which layer needs fixing.
4. Who owns the code, data, and credentials when this engagement ends?
This is the single most consequential question on this list, because its consequences are invisible until the relationship ends and suddenly matter enormously. Domain registration, hosting and cloud accounts, source code repositories, and platform admin credentials should be registered in the client's own name and accounts from day one — not the agency's, "for convenience," with a promise to transfer later. When an agency controls these and a relationship sours, transferring them can be slow, costly, or in the worst documented cases, contested outright.
A useful concrete test: ask to see, in the actual contract, the specific clause covering intellectual property assignment — not a general statement that "you'll own the work," but language that explicitly assigns all rights, in every deliverable, to the client, effective immediately upon creation rather than upon final payment or project completion. The distinction matters because an assignment triggered only "upon final payment" can leave ownership ambiguous during a dispute over a late invoice — exactly the moment ownership clarity matters most. Similarly, ask directly whether any part of the technical solution depends on a platform or tool the agency owns exclusively; a dependency on the agency's own proprietary CMS or hosting environment is a form of lock-in even when the code itself is technically "yours."
5. How do you handle scope changes, and what's your change-order process?
Given that PMI's research puts scope creep at 52% of all projects, the question isn't whether your project will encounter a scope change — it's whether there's already an agreed process for handling one when it happens. Ignition's 2025 Agency and Cash Flow Report found that 78% of agencies rarely or only sometimes actually charge for out-of-scope work, and separately that 57% of agencies lose $1,000-$5,000 a month to unbilled scope creep — numbers that describe the agency's financial pain, but translate directly into your risk too: an agency bleeding margin on undocumented scope changes eventually recovers it somewhere, often through rushed work or a sudden, unexplained budget request.
It's worth understanding the mechanism behind why scope creep happens so consistently, because it isn't usually deliberate dishonesty on either side. PMI's research describes it as an accumulation of individually small, reasonable-sounding requests — "can we also add," "while you're in there, could you" — none of which feels significant enough in the moment to trigger a formal change request, until the sum of them has meaningfully expanded the project without anyone deciding that on purpose. A described process doesn't need to be bureaucratic to be effective; it just needs to exist as a habit triggered by any new request, however small it seems.
6. What happens if my main point of contact leaves the agency?
Staff turnover is a normal fact of agency life, not inherently a red flag — but a project's continuity plan for it either exists or doesn't. High turnover specifically on your account, with no documented handover process, tends to show up as lost context, restarted decisions, and a slower project than anyone intended. Attrition data from the professional services industry generally sits in the low-to-mid teens percentage range annually, meaning most engagements of any meaningful length will encounter at least one personnel change somewhere on the team — the question is whether that change is disruptive or nearly invisible to you as the client.
7. Can you walk me through a project that went wrong, and what you did?
Every agency that's been operating for more than a couple of years has had a project go sideways — a missed deadline, a technical decision that didn't pan out, a client relationship that ended badly. The answer to this question tests something a polished pitch can't: whether the agency can be honest about failure and describe what it actually learned, or whether it insists everything has always gone perfectly (which is itself an implausible claim worth treating skeptically, given how consistently independent research finds the majority of projects across the industry encounter some form of challenge).
The most revealing follow-up here isn't about the failure itself but about what changed afterward — a specific process, a specific new check, a specific role added — because that's the difference between an agency that learns from mistakes systematically and one that simply moved past a bad outcome without changing anything structural about how it operates.
8. How do you measure success, and what's your reporting cadence?
An agency that reports on activity (hours logged, tickets closed, deployments shipped) is measuring something different from one that reports on outcomes (revenue impact, conversion movement, resolution rate) — and the gap between those two framings is exactly the "handled vs. resolved" distinction that matters across ecommerce automation generally, not just agency reporting specifically.
A useful way to test which framing an agency actually operates from: ask what happens in their reporting if activity is high but the business outcome doesn't move — a busy month of deployments and tickets closed, with flat or declining revenue. An agency built around activity metrics will often present that month as a success anyway, because the metrics they track technically went up. An agency built around outcomes will treat the same month as a signal to investigate and change approach. Neither framing makes an agency dishonest, but the difference matters enormously for how a stalled project gets diagnosed and fixed six months into a relationship.
9. What's included versus billed separately, and can I see a sample contract or SOW?
A proposal that arrives instantly, is perfectly formatted, and lands suspiciously close to your stated budget deserves a second look — proposals built to close a deal quickly are not always the same as proposals built to accurately estimate a real project's cost. Asking to see the actual contract language, not just a sales deck, surfaces exactly where scope, payment terms, IP ownership, and change-order handling really stand — because verbal reassurance on a sales call is not legally binding, and the contract is what will actually govern the relationship if something goes wrong.
10. Why should I choose you over a specialist versus a generalist for this specific need?
The honest answer to this question often isn't "you should always choose us" — a genuinely good partner will tell you plainly when your specific need is better served by a narrower specialist (a single-platform migration specialist, for instance) or, conversely, when it needs a broader partner because the pieces (data, design, ongoing growth) need to work together as one system rather than as separately contracted fragments.
How to actually ask these questions
The format of the conversation changes how honest the answers are. Three practical adjustments make the ten questions above far more revealing than dropping them into a single sales call:
- Separate the sales conversation from the working-session conversation. A sales call is optimized, by design, to make the agency look good — that's not dishonest, it's just what a sales process is for. Asking to speak with the actual delivery team in a working-style session (even a short one) before signing surfaces a different, less rehearsed register of answer.
- Ask "why" a second time on any answer that sounds rehearsed. A well-prepared agency has a smooth answer for "how do you handle scope changes." Asking a specific follow-up — "walk me through the last time that actually happened" — tests whether the process described is real or aspirational.
- Ask the same question of two people at the agency separately. A discrepancy between what a salesperson says about team composition and what a delivery lead says about it is itself useful information, regardless of which version turns out to be accurate.
None of this needs to feel adversarial — a genuinely confident, well-run agency generally welcomes this level of scrutiny, because it's the same diligence they'd want applied if the roles were reversed. An agency that treats direct questions as an inconvenience or an insult during evaluation is showing you, in miniature, how they'll likely treat pushback once the contract is signed and the leverage has shifted.
A red-flag scorecard
After all 10 conversations, this quick-scan table synthesizes the pattern worth watching for across the whole evaluation, not just any single question:
| Signal | What it usually means |
|---|---|
| Proposal within 24-48 hours, no discovery | Scope is a guess, likely to expand through billed or unbilled change orders later |
| Only sales/leadership visible pre-contract | Risk of a team bait-and-switch after signing |
| Vague or hedged answer on code/data ownership | Vendor lock-in risk — expensive or difficult to leave later |
| No described change-order process | Scope creep is likely to be handled reactively and unevenly, not fairly |
| Claims of a flawless project history | Either survivorship bias in what gets mentioned, or limited self-awareness about past failures |
| Reporting framed only around activity | Success may never get tied back to an outcome you actually care about |
One or two mild instances of the above don't automatically disqualify an agency — sales processes are imperfect, and a good agency can have an off day in an early call. A pattern across three or more, especially combined with evasiveness rather than a direct correction when you push back, is the signal worth acting on.
A note on where this advice comes from
In researching this piece, most of what's published online under titles like "agency red flags" or "how to spot a bad vendor" turned out to be written by agencies — often ones directly competing for the same category of client this article is written for. Several cited impressive-sounding statistics ("68% of failures trace to X," specific dollar figures on named incidents) with no disclosed methodology, no link to underlying data, and an obvious incentive to make the case that competitors fail in predictable ways their own agency doesn't.
We've tried to hold this piece to a different standard: the quantitative claims above — the 29-31% project success rate, the 52% scope creep rate, the 27% average cost overrun, the 78%/57% figures on unbilled scope creep — all trace to named, independent research organizations (the Standish Group, the Project Management Institute, and Ignition's own published survey) rather than to a single agency's self-reported anecdote. The 10 questions themselves, and the red-flag patterns attached to them, are qualitative synthesis based on widely-repeated, cross-source agreement about failure patterns — genuinely useful as judgment, but presented here as judgment, not disguised as data with a number attached to make it sound more rigorous than it is.
Vetting offshore and distributed teams specifically
Ecommerce agencies increasingly operate with distributed or offshore delivery teams, which isn't itself a reason for caution — some of the most capable, cost-effective engineering talent in the industry works this way, and geography alone says nothing about competence. What deserves specific attention is disclosure and continuity, not location: an agency should be upfront about where delivery actually happens and by whom, rather than presenting an onshore face during sales and revealing offshore delivery only after signing. The same continuity questions from earlier in this guide (who exactly will work on my project, what happens if they leave) apply with extra weight across distributed teams, where time zone handoffs and language/communication style differences can compound a documentation gap that would be merely inconvenient with a co-located team.
A fair, non-discriminatory way to evaluate this: ask for the same specifics regardless of team location — names, roles, communication cadence, and overlap hours with your own team — and judge the answer on its completeness and directness, not on where the answer happens to be geographically based. An agency dodging the location question entirely is a bigger signal than the location itself.
After signing: the questions don't stop mattering
Vetting isn't a one-time gate before a contract is signed — the same ten questions remain useful checkpoints throughout an active engagement, because answers can drift over time even when the initial vetting was thorough. A few practical checkpoints worth building into any ongoing agency relationship:
- Revisit the team-composition question at any major milestone. If the people doing the work have changed significantly since kickoff and nobody flagged it, that's worth a direct conversation, not a quiet assumption that it's fine.
- Track scope-change requests as they happen, on your side, independent of the agency's own tracking. A simple running log of "here's what we asked for beyond the original scope" gives you an independent check against the agency's own change-order records, and surfaces drift before it becomes a large, disputed invoice.
- Periodically confirm you still have working access to everything from question 4. Credentials get rotated, accounts get migrated, and an ownership arrangement that was correct at kickoff can quietly degrade if nobody checks it again. A yearly access audit — can you actually log into your domain registrar, hosting account, and code repository right now, without the agency's help — costs almost nothing and catches lock-in before it becomes a crisis.
The businesses that get burned by a bad agency relationship are rarely the ones who asked hard questions upfront and then verified nothing again for two years — they're more often the ones who never asked in the first place, or who asked once, got a good answer, and never checked whether it was still true.
What "good" looks like across all ten
Read back across the ten "good answer" callouts above and a consistent shape emerges, independent of any specific agency: directness over vagueness, documentation over verbal reassurance, willingness to say "we're not the right fit" when that's true, and transparency about past failure rather than a claim of a flawless record. None of that is unique or proprietary — it's simply what a mature, confident vendor relationship looks like when an agency has nothing to hide in its process, its team, or its contract terms. If a prospective partner's answers consistently match that shape across all ten questions, that's a stronger signal than any single portfolio piece or client logo.
It's also worth naming what this guide deliberately doesn't claim: that any single answer, good or bad, should make or break a decision on its own. Vetting an agency is closer to reading a pattern across many small signals than administering a pass/fail exam on any one question — a strong agency with one imperfect answer to a single question is still very possibly the right choice; a polished agency with evasive answers across several questions is a pattern worth taking seriously, however good the rest of the pitch felt.
When a specialist beats a generalist (and vice versa)
Question 10 deserves a fuller, standalone answer because it's the one most sales conversations get least honest about. A narrow specialist — a single-platform migration specialist, a specific integration expert — tends to have faster ramp-up time and deeper, more specific judgment for a well-bounded problem with a clear start and end. A broader, full-service or data-and-engineering-led partner tends to fit better when the actual need spans multiple disciplines that need to function as one coherent system: catalog data feeding pricing feeding personalization feeding support, for instance, where handing each piece to a different specialist creates exactly the fragmentation problem covered in our data engineering guidance. Neither is a universally correct choice — the honest question to ask yourself before evaluating any vendor is whether your actual problem is narrow and well-defined, or whether it's a system-level problem that a narrow specialist can only ever partially solve.
Ask us all ten questions above — we'll answer them the same way we've described a good answer looking like in this guide, including telling you honestly if we're not the right fit. Talk to a team that's done this for 17+ years.
Talk to the Team →Frequently asked questions
What questions should I ask before hiring an ecommerce agency?
At minimum: can they show a live production reference you can speak with directly; who exactly will work on your project; what their discovery process involves; who owns the code, data, and credentials after the engagement ends; how they handle scope changes; what happens if your point of contact leaves; how they've handled a past project that went wrong; how they measure success; what's included versus billed separately; and why they're the right fit for your specific need versus a generalist or a narrower specialist.
How often do agency or software projects actually fail?
The Standish Group's CHAOS research, one of the most widely cited studies on software project outcomes, has historically found only around 29-31% of projects are considered fully successful (on time, on budget, with the intended features), with the remainder either challenged or failed outright. Separately, the Project Management Institute's Pulse of the Profession research finds 52% of projects experience scope creep.
Who should own the code and data after an agency project ends?
The client should own all custom code, design files, content, domain registration, hosting/cloud accounts, and login credentials — registered in the client's own name and accounts from day one, not the agency's. If an agency retains control of any of these, switching providers later becomes difficult or costly, a pattern known as vendor lock-in.
Should I hire a specialist agency or a generalist for ecommerce work?
A specialist tends to have faster ramp-up time and deeper platform-specific judgment for a narrow, well-defined need (a specific migration, a specific platform). A generalist or full-service partner tends to fit better when the need spans multiple disciplines (data, design, marketing) that need to work together as one coherent system rather than as separately contracted pieces.