E-commerce Website Requirements: The Checklist Before You Hire
In this article10 sections
Writing down your ecommerce website requirements before you hire anyone is the single best way to get accurate quotes, a realistic timeline and a store that does what your business needs. A requirements document does not have to be technical. It lists what you sell, who buys, how orders flow, which systems must connect and what "done" looks like. Agencies can then price the same scope, and you can compare their answers fairly.
Key takeaways
- Describe your business and your customers first; features come second.
- Split every requirement into must-have, should-have and nice-to-have.
- Integrations, data migration and content are the parts most often left out of quotes.
- Include non-functional needs: speed, security, accessibility and who maintains the store.
- Send the same document to every supplier so their quotes can be compared like for like.
Why a requirements document saves money
When agencies quote from a short email, each one fills the gaps with its own assumptions. One assumes you need ten pages; another assumes fifty. One includes data migration; another does not mention it. You end up comparing prices for different projects.
A clear requirements document fixes that. It also:
- forces your own team to agree on priorities before money is spent;
- reduces change requests during the build, which are a common cause of overruns;
- gives you something to test against at the end;
- makes it easier to switch suppliers later, because the scope is written down.
It does not need to be long. Ten to fifteen pages, written in plain language, is plenty for most stores. Use the sections below as your outline.
Business goals and customers
Start with the context. A developer who understands your business makes better decisions on the hundreds of small details you will never think to specify.
- What the business does, in a paragraph.
- Goals for the store over the next one to three years, such as entering a new market, moving wholesale orders online or replacing an outdated platform.
- Who your customers are: consumers, trade buyers or both; age range; devices they use; countries they buy from.
- Current numbers, if you have them: monthly visitors, orders per day, average order value and peak periods.
- What is wrong today, if you are replacing an existing store. This often reveals the real priorities.
- Stores you admire, with notes on what you like about each one.
Catalogue and product requirements
Product data shapes the whole build, so describe it carefully.
| Question | Why it matters |
|---|---|
| How many products, and how many variants? | Affects platform choice, hosting and import tools |
| What options do products have (size, colour, material, personalisation)? | Decides product types and how the page works |
| Are there bundles, kits or made-to-order items? | Often needs custom work |
| Where does product data come from today? | Spreadsheet, ERP or supplier feed changes the integration |
| How often do prices and stock change? | Determines whether sync must be real-time or daily |
| Do different customers see different prices? | Customer groups, trade pricing and tiered discounts |
| Which filters do shoppers need? | Shapes attributes and navigation |
Attach a sample of real product data, including your most complicated product. It tells a developer more than any description.
Checkout, payments and delivery
This is where revenue is won or lost, so be specific.
Checkout
- Guest checkout, account checkout or both.
- Fields you must collect, such as a tax ID for business buyers or a delivery note.
- Discount codes, gift cards, store credit and loyalty points.
- Minimum order values or quantity rules.
Payments
- The payment gateways or providers you already use or prefer.
- The methods your customers expect: cards, wallets, bank transfer, buy now pay later, cash on delivery, invoice terms for trade accounts.
- Currencies you need to accept.
Delivery
- Carriers you use, and whether rates are flat, weight-based, location-based or live from the carrier.
- Click-and-collect, local delivery or international shipping.
- Delivery date estimates and cut-off times.
Our guide to reducing cart abandonment explains why these details deserve so much attention.
Integrations and data migration
Integrations are the most underestimated part of most store builds. List every system the store must exchange data with, and say which direction the data flows.
- Accounting: orders, invoices, refunds and tax.
- ERP or inventory: products, prices and stock levels.
- Warehouse or fulfilment: orders out, tracking numbers back.
- Shipping: labels, rates and tracking.
- CRM and email marketing: customers, consent and purchase history.
- Marketplaces: product listings and orders from other channels.
- Point of sale: shared stock and customers with physical shops.
For each one, note the system name and version, whether it has an API, and who at your company owns it.
Data migration
If you are moving from an existing store, say what must come across: products, customers, order history, reviews, blog posts and URL redirects. Customer passwords often cannot be migrated directly, so plan how customers will reset them. Our team covers this in detail on our data migration page.
Content, design and SEO
Content
- Which pages you need: home, about, contact, delivery, returns, FAQs, legal pages, blog.
- Who writes the copy and who supplies photographs. If the answer is "the agency", say so, because it changes the quote.
- Languages, and who will translate.
Design
- Brand guidelines, logo files and fonts.
- Whether you want a custom design or an adapted theme.
- Any accessibility standard you must meet. The WCAG guidelines are the common reference.
SEO
- Control over titles, descriptions, URLs and redirects.
- XML sitemap, structured data and canonical tags.
- A redirect plan if URLs will change.
Ecommerce website requirements beyond features
Some of the most important requirements are not features at all. They describe how well the store must work and who looks after it.
- Speed: target load times on a mobile connection, and the busiest day the store must handle.
- Security: HTTPS, regular patching, secure admin access, backups and who is responsible for each.
- Privacy and legal: cookie consent, data protection and the countries whose rules apply.
- Hosting: who provides it, where it is located and how it is monitored.
- Admin users: how many staff need access, and what each role can do.
- Reporting: the sales, stock and customer reports your team needs.
- Support after launch: response times, monthly maintenance hours and how upgrades are handled.
- Ownership: confirm you will own the code, design and data.
Budget, timeline and decision-making
Many store owners leave the budget out of the brief, hoping to see what agencies suggest. In practice, sharing a realistic range helps you more than it helps the supplier. It lets each agency propose the best solution for that money, instead of guessing whether you want a basic theme or a fully custom build.
Give a budget range
State the range you are prepared to spend on the initial build, and separately what you expect to spend each year on hosting, licences, extensions and maintenance. If you are unsure, say what you spend on the current store and what return you expect from the new one. A supplier can then tell you honestly what is realistic.
Set a realistic timeline
Work backwards from any fixed date, such as a seasonal peak or the end of a contract with your current platform. Leave room for testing and for your own team's tasks, which are easy to underestimate. Writing product copy, supplying photographs, checking migrated data and training staff all take time.
Name the decision-makers
Say who approves designs, who signs off each phase and who answers day-to-day questions. Projects slow down when feedback has to pass through several people, or when a senior stakeholder appears late and asks for changes. One named product owner with the authority to decide keeps the build moving.
Define what "done" means
Finish this section with your acceptance criteria. List the key journeys that must work before launch, such as placing an order with each payment method, processing a refund or syncing stock from the ERP. These become the test plan at the end of the project, and they remove any argument about whether the work is complete.
How to share the checklist and compare quotes
Once the document is ready, send the same version to every supplier you are considering. Ask each one to:
- confirm which requirements are included, and flag any they would handle differently;
- break the price down by phase, such as discovery, design, build, integrations, migration and testing;
- state assumptions clearly, especially about content and integrations;
- give a timeline with milestones and what they need from you at each one;
- describe their support and maintenance terms after launch.
Be cautious of any quote that is much lower than the rest without explaining why. It usually means something is missing. A good supplier will ask questions about your document rather than simply accept it. If you are still deciding on the platform, read our guide to choosing an ecommerce platform before you send the brief.
A one-page summary to start from
| Section | Include |
|---|---|
| Business | Goals, customers, current numbers, problems today |
| Catalogue | Products, variants, pricing rules, sample data |
| Checkout | Guest or account, discounts, special fields |
| Payments | Gateways, methods, currencies |
| Delivery | Carriers, rates, collection, international |
| Integrations | Every connected system and data direction |
| Migration | Data to move, redirects, passwords |
| Content and design | Pages, copy, photos, brand, languages |
| SEO | Controls needed, redirect plan |
| Non-functional | Speed, security, legal, hosting, support |
Frequently asked questions
Do I need technical knowledge to write requirements?
No. Describe what you need in business terms, such as "trade customers see their own prices", and let the developer work out how. Clear business language is more useful than half-correct technical terms.
How detailed should the document be?
Detailed enough that two agencies would quote for the same project. Focus detail on the areas that are unusual for your business, such as complex products or integrations, and keep standard features brief.
Should I pay for a discovery phase?
For larger or complex stores, a paid discovery phase is often worth it. The agency turns your requirements into a detailed specification, which reduces risk for both sides and makes the build quote far more reliable.
What if my requirements change during the build?
Some change is normal. Agree a simple change process at the start: each change is written down, priced and approved before work begins, so the budget never drifts without your knowledge.
Have a draft brief ready? Send it to us and we will tell you honestly what is missing, what it is likely to cost, and how long it should take.
Want an expert to look at your store?
Tell us what you are working on. A senior e-commerce consultant will reply within one working day with honest, practical advice. No obligation and no sales script.
- Reply within one working day
- Advice even if we are not the right fit
- Your details are never shared