Website with shopping cart: architecture + SEO + payments + shipping — minimum requirements before paying for development

A website with a shopping cart requires defining the catalog, prices, payments, shipping, SEO, security, and measurement before starting development.

Before approving a proposal, translate business needs into verifiable rules and deliverables. This allows the team to clearly define what needs to be built and what will be considered complete; business decisions aren't left until scheduling.

An online store combines a catalog and a purchase flow. If you're defining the site's format, you can also review the types of web pages and distinguish a store from an informational or corporate site.

Requirements for a website with a shopping cart: define the scope in writing

A useful specification explains what the business sells, to whom, in which markets, and under what rules. It's not enough to simply order a shopping cart, a gateway, or a product section: the team needs to know how each component will behave and who will approve its operation.

To document each requirement, make four points clear:

• The rule of business: Which condition applies? For example, if a product has variations, indicate whether each option changes the price or availability.
• The expected behavior: what the buyer should see or be able to do in that situation.
• The data and those responsible: Where the information, images, prices, and updates come from, and who delivers them.
• The acceptance test: How will it be verified that the development complies with the rule, both in a normal case and in a relevant exception?.

It also defines what the proposal includes and excludes: product uploads or migrations, template design, integrations, content, technical SEO, analytics, testing, and access delivery. General expressions like "store ready" do not, on their own, explain the scope or approval criteria.

When a decision depends on the industry, sales markets, or business operations, record it as a condition to be confirmed. The developer can implement an agreed-upon rule, but shouldn't have to create commercial or tax policies.

Operational checklist: catalog, shopping cart, payments, shipping, and policies

This section of the scope describes what is offered, how to purchase it, and what happens after the order is placed. Document the use cases that apply to your business and clearly outline any exceptions that the team must test.

Catalog, categories and variations

Taxonomy is the way to organize products into categories, subcategories, and attributes. Define the names and groupings that both the team and buyers will use; don't leave the catalog structure to an impromptu decision during product uploads.

• List categories and subcategories, and indicate which products belong to each one.
• Specify what attributes or variations each product has and which ones should appear on the product sheet.
• Define the information that each record needs, who submits it, and who can update it.
• Describe the rules for pricing, discounts, and availability, including examples when there are variations or promotions.

A single rule can change the experience across multiple screens. If a change modifies the price, for example, agree on where that price will be displayed and what value should be retained in the shopping cart and order confirmation. If the store will connect to another inventory or management system, confirm the data source and the scope of the integration. Don't assume compatibility; it must be verified for the chosen platform and systems.

Shopping cart and checkout process

Describe the process from when a person adds a product until the order is confirmed. In this context, checkout is the step where the information is entered and the purchase is finalized.

• Indicate what actions the buyer will have: modify quantities, remove products, or return to the store.
• Define what information will be requested and what data will appear before confirming the order.
• Specifies when shipping costs and other applicable business charges will be displayed.
• Describe what response the buyer will see regarding an approved, pending, rejected, or canceled payment.

In addition to the standard delivery process, agree on what should happen in cases such as an out-of-coverage address, an unavailable product, or an unsuccessful payment attempt. Including these scenarios in testing helps validate the agreed-upon process without assuming that all orders follow the same path.

Payment methods

List the payment methods you want to offer and the countries or currencies included in the project, if applicable. Before contracting an integration, confirm the compatibility of the platform and the selected provider. Don't assume a payment method is available simply because it's mentioned in a proposal or because the store uses a specific platform.

Clearly define who configures the integration, who manages the accounts, and how each payment status is verified. The agreed-upon tests should cover, at a minimum, the expected path for an approved transaction and any error or pending scenarios relevant to your operations.

Shipping, exchanges, returns and taxes

Define the areas where the store will sell, the delivery options it will offer, and how costs and estimated delivery times will be communicated. Clarify who maintains this information and how orders that do not meet the coverage requirements will be handled.

It also documents how changes, returns, cancellations, and order inquiries will be handled. Agreeing on what information the buyer will see and who will respond to each request prevents post-purchase operations from being out of reach. For further reading on after-sales follow-up and support, see the article from Agencia Roco on [topic missing]. order management in an online store.

Taxes and legal policies vary depending on the country, sales destinations, and business characteristics. For suppliers or retailers located in Colombia offering products electronically, Article 50 of Law 1480 of 2011, in its consolidated text, requires reporting payment methods, delivery time, right of withdrawal, and total price including taxes, costs, and expenses. This example is limited to this specific scenario: do not extrapolate it to other countries or use it to independently determine applicable tax treatment or exceptions. Verify the terms of your transaction with legal and tax advice.

Technical SEO for ecommerce: categories, filters and indexing control

Technical SEO should be part of the initial architecture, not a list of adjustments to be improvised after launch. The scope should define which pages the store will have, how the catalog will be organized, and how the site's filters and generated URLs will behave.

A clear architecture for categories and cards

Define the map of categories and subcategories and the product pages that make up the catalog. Agreeing on names, relationships, and responsibilities before building helps the team know which templates to develop and what content is still pending.

For categories, specify what useful information they will provide in addition to the product listing: for example, what types of products they encompass, what features help in comparing them, or what guidance the buyer needs to choose. Avoid treating the content as generic, repetitive text without considering the differences between categories.

The scope includes a review of the page structure and how the pages connect. For a broader overview, you can consult Agencia Roco's article on... Technical SEO for ecommerce.

Filters and index bloat

Filters can generate different URLs depending on the selected attributes. Before development, make a list of the filters the store needs and ask for examples of the URLs each relevant combination would generate. The goal is to decide which filters have clear utility for the shopping experience and which should be considered in the indexing strategy.

The term index bloat This is used to describe uncontrolled growth in the number of pages that could become available for indexing. It doesn't mean that all filters should be blocked or that all their combinations should be indexed: there's no one-size-fits-all rule. Document what should happen in the defined cases and ask the developer to explain how that decision will be implemented on the chosen platform.

Structured data and category content

Include in the scope the evaluation of structured data for product pages, if applicable to the project. Request that you specify which pages will be marked up, where the data will come from, and how the implementation will be tested. Product markup can make a page eligible for certain Google Commerce experiences, but it doesn't guarantee that it will appear in them.

The content of each category should also have a defined purpose: to guide the buyer and reflect the real differences between product groups. Agreeing on the page map, filters, and content before building allows these decisions to be discussed alongside the design team, rather than leaving them for later adjustments.

Performance, safety and measurement: baseline requirements and kick-off checklist

Performance and safety are fundamental requirements, not optional upgrades for later. Include them in the project definition, specifying responsibilities, acceptance criteria, and an agreed-upon method for verifying them before approving the site.

Performance as an acceptance criterion

Don't settle for a general promise that the store will be fast. Agree on which pages will be reviewed—for example, category, product, cart, and checkout—under what conditions they will be tested, and what metrics or thresholds will be used to accept the work. These criteria must be defined for the project; don't assume there's a single number that's right for all platforms and operations.

Ask what the work includes in addressing performance, who verifies the results, and what happens if a page doesn't meet the agreed-upon criteria. This way, performance becomes part of the delivery and isn't left as an unverifiable expectation.

Safety and responsibilities

The proposal should describe how access will be managed and who will be responsible for each account, component, and maintenance task. It should also define how updates, backups, and data recovery will be handled, based on the chosen scope and platform.

During the payment process, ask what the provider's service covers and which tasks fall under the responsibility of the business or development team. Clearly define responsibilities regarding access and customer data, and validate any required policies with expert advice. Avoid accepting phrases like "security included" without a description of what will be done and how it will be delivered.

Ecommerce measurement and action tracking

Before installing any tools, agree on what the business needs to understand. Examples of actions that could be measured include viewing a product, adding it to the cart, initiating checkout, and confirming a purchase. These are examples to help you design your measurement, not a universal list or a guarantee that a tool will automatically record them.

Define which tool will be used, who will have access to the accounts, what will be considered a conversion, and how the journey will be tested. It's important to specify what outcome distinguishes a confirmed purchase from a pending or incomplete payment attempt; the way to implement this depends on the chosen platform and measurement solution.

Keep the scopes separate: development implements the store; SEO handles organic presence and architecture; Google Ads corresponds to paid campaigns; and the CRM, if integrated, supports sales management. They can share information, but each service, responsibility, and integration should be described separately.

Checklist for the initial meeting

Before the kick-off —the initial project meeting— gather and confirm the following inputs:

• Product catalog, categories, attributes, variations, and those responsible for updating the information.
• Pricing, discount and availability rules, with examples to test them.
• Purchase flow, planned payment methods, and agreed test cases.
• Shipping zones, costs, delivery times, and after-sales service process.
• Revised commercial, legal and tax policies for the markets where the business will operate.
• Category and product page map, filter decisions, content and structured data evaluation.
• Acceptance criteria for performance, safety and measurement, with responsible parties and validation method.
• Tools and accounts required, access that will be provided, integrations included, and those responsible for approving each delivery.

Questions you should ask the developer before paying

The answers should be reflected in the proposal or project specification, not just in a conversation:

• Which pages, features, integrations, and tests are included, and which are excluded?
• How will the categories, cards, variations, and pricing rules defined by the business be implemented?
• How will the platform's compatibility with the chosen payment methods be validated, and what cases will be tested?
• How will shipping, coverage exceptions, and exchange or return information be configured?
• What will the filters and the addresses they generate behave like, and who will approve the indexing decisions?
• What tests and criteria will be used to accept performance and safety?
• What ecommerce actions will be measured, how will they be verified, and who will manage the accounts?
• Who will own the accounts, access, and information, and how will the handover take place upon completion of the project?

A well-defined development plan allows the business and technical teams to evaluate the same deliverable. If any rules remain open, document them as decisions pending confirmation rather than letting them become assumptions during development.