What an e-commerce scope must cover before you sign

You're sitting down with a web developer who's showing you mockups and talking about templates and integrations. They send over a proposal. It looks professional, but you're not sure what you're actually paying for—or worse, what's being left out. Before you sign anything, you need to understand what an e-commerce scope document must include so you don't discover halfway through that your store can't do what you promised your customers.

What a scope actually protects you from

A scope of work is your contract's backbone. It lists exactly what the developer will deliver, what they won't, and what happens if requirements change. Without one, you end up with conversations like "I thought you were adding product filters" or "You never said you'd handle the email templates." Those conversations cost time, money, and trust. A tight scope prevents scope creep—where the project keeps expanding without timeline or fee adjustment—and it gives you something to point to if the final store doesn't match what you expected.

The developer should write or co-write the scope with you, not hand you boilerplate. If they treat it like a checkbox, that's a warning sign.

The core elements your scope must name

Start with the basics. What platform or technology stack is being used? Shopify, WooCommerce, a custom build—it should be explicit. How many product categories and how many individual products are you launching with? Will the store support multiple currencies or languages from day one? Many developers assume single-language, single-currency; if you need both, that must be in scope.

Payment methods matter enormously. Will the store accept card payments, bank transfers, EFT, payment plans? Which payment gateway? Integration costs and regulatory requirements vary wildly. Delivery is equally critical: will the developer set up shipping calculators, integrate with courier APIs, or just provide a basic flat-rate option? Do they include linking to your selected logistics partner? This is where many stores fail—the payment and delivery infrastructure isn't properly connected to your backend.

User account functionality should be specified. Will customers be able to register, save addresses, view order history, and receive status emails? Or is checkout guest-only? Each option has build implications.

Areas developers often skip (so ask directly)

Make sure the scope covers:

• Search and filtering. Can customers search by keyword, price, colour, size, or brand? Is this basic text search or faceted navigation?
• Admin dashboard. Can you manage stock levels, process orders, generate reports? Or will you need custom training or separate tools?
• Email automation. Who sets up order confirmation emails, shipping notifications, abandoned-cart reminders? Is the developer building these or instructing you on platform templates?
• SEO basics. Will the developer optimise product page structure, URLs, and meta tags, or hand you an unsearchable store you have to fix later?
• Mobile responsiveness. Assumed for any new build, but confirm it's tested and not an afterthought.
• Support and training. How many hours of post-launch support are included? Will the developer train you or a team member to manage the store, or leave you stranded?
• Third-party integrations. Accounting software, CRM, inventory management, marketing tools—does the scope name which ones and who's responsible for setup?

What should be outside the scope

This matters as much as what's in. A scope should explicitly state that it does *not* include ongoing support beyond an agreed training or handover period, copywriting for products, photography, digital marketing, or payment processing fees. If you're unclear on what comes after launch—who owns updates, who patches security issues—you'll have arguments later.

The developer should also clarify revision rounds. Most include two to three rounds of feedback on the overall design; beyond that, it's a change order. The same applies to feature requests mid-build.

Before you sign

Read the scope aloud to the developer. Ask them to explain any jargon. If something doesn't make sense, ask "what does that mean in practice?" If they get impatient, that's a signal. A professional developer expects these questions and answers them clearly.

Check that timelines and milestones are realistic and that both payment terms and the final delivery expectation are crystal clear. Then compare the scope against what you actually need your store to do on day one and month six. If the scope doesn't cover it, now is the time to negotiate, not after work has started.

Once you're confident the scope reflects your business, you can shop with conviction. When you're ready, verified e-commerce developers on Strove can walk you through their scope documents and answer these exact questions before you commit.