Questions to ask before an e-commerce build

You're about to spend money and time on an e-commerce build. The difference between a store that works and one that stalls often comes down to the clarity of your conversation with the developer before you start. The questions you ask now—and how carefully you listen to the answers—are your best safeguard.

What questions reveal a developer who thinks past launch

Start with this one: "Walk me through what happens on day one after you hand over the store." A vague answer—"you'll have a working store" or "just log in and add products"—is a warning. A good answer explains the handover process itself. They should talk about training you on the admin panel, showing you how to update inventory, explaining which settings you can safely change and which ones you shouldn't touch. They might mention setting up your email for order notifications or pointing you to documentation they'll give you.

A developer thinking ahead also answers: "What happens when something breaks after launch?" This separates developers who build and disappear from those who set up a relationship. They should clarify whether they offer post-launch support, for how long, and whether it costs extra. They should explain what kinds of issues are covered—plugin updates, security patches, broken payment gateways—and what fall outside their scope (like if you accidentally delete essential database files). If they say "you can always call me," ask them to put that in writing with response time expectations.

Another one: "How will you make sure the store is ready before we go live?" Here you're listening for a testing plan. A solid developer talks about testing on a staging site first—a hidden copy where you both check that products upload correctly, payment processing works, checkout flows smoothly, and the site loads fast. They test on multiple devices and browsers. They check that search works, filters work, and the customer journey from browsing to order confirmation is seamless. If they skip to "we'll launch and fix issues as they come up," that's a red flag.

Questions that expose misaligned expectations

"How many revisions are included?" matters more than you might think. A developer who says "unlimited revisions until you're happy" sounds generous but often means scope creep—the project stretches indefinitely, and they're unhappy about it. A clearer answer is something like: "The quote covers three rounds of feedback on design, then we move to development. Once we're building, we'll track change requests separately because they affect timelines and budget." This honesty protects you both.

Ask: "If I change my mind about a feature halfway through, what happens?" You'll discover whether they work from a locked scope or allow flexibility. Neither is wrong, but you need to know which it is. If the scope is fixed, changing your mind costs more and takes longer. If they're flexible, ask how they manage that—do they track changes, adjust the timeline, or renegotiate cost? Get a sense of how painful or straightforward it is.

"What happens if I disagree with your recommendation?" reveals whether they listen or insist they know better. A developer confident enough to say "I still think that's a mistake, but if that's what you want, we can do it" is mature. Someone defensive or who doubles down without hearing you out may be hard to work with.

Questions that show you what you're actually getting

"Can you show me three stores you've built recently and introduce me to the owners?" This is powerful because the owner's honest opinion—whether they love the store, find it hard to manage, or regret choices—tells you more than a portfolio ever will. If the developer hesitates or says those stores are confidential, that's unusual and worth probing. Most happy clients are willing to vouch for work.

Finally: "What would I have done differently if I'd known what you know now?" This is the question that cuts through sales-speak. A developer answering honestly often reveals where they see clients stumble—poor product photography, inadequate inventory management setup, underestimating shipping complexity, or launching without email marketing systems in place. Their answer shows whether they've learned from real stores.

You don't need a developer who promises perfection. You need one who thinks through the hard parts, communicates clearly when expectations clash, and proves they've actually delivered working stores. The conversation itself is the test. Pay attention to whether they're answering your questions or delivering a pitch. When you're ready to move forward with a developer who can articulate their process, Strove's verified e-commerce developers have track records you can check with their past clients.