Online store technical specification: what to define before development

Start with the sales rules

Describe what the company sells and to whom. A retail purchase at a public price, a business order under a contract and custom manufacturing require different actions. Include regions served, settlement currency, collection and delivery options, and restrictions on selling particular goods.

Then define the first release’s scope. For example, a buyer may order without an account but only receive purchase history after registering. Alternatively, a manager calculates delivery and the site initially accepts an enquiry. Both can be deliberate choices when the interface clearly shows the next step and payment terms.

Put deferred features in a separate section. If a loyalty programme is being discussed for the future, it should not quietly become mandatory for launch. The developer still needs to understand which confirmed future rules could affect product or order storage now.

Describe products as they are bought and accounted for

Each product group needs fields, variants and a unit of sale. A T-shirt may have shared copy but different SKUs for sizes; a bundle may consist of separate stock items. Without this definition, the storefront catalogue and inventory records can become incompatible.

Specify where the SKU, price and stock originate. If accounting or inventory software is the source, determine which fields a manager may edit on the site and whether the next import overwrites those changes. This rule prevents two employees from changing the same price in different places.

Attach an anonymised data example: a product row, a set of variants, an image and a category. If the source file is incomplete, record who fills the gaps and what marks preparation as finished. “Upload the catalogue” needs to reflect exactly what the client supplies.

Turn checkout into verifiable states

Describe what happens before payment, after confirmation, on cancellation and when the waiting period expires. For each state, specify what the customer sees and which action an employee can take. A list of statuses without transition rules leaves too many trading decisions to the programmer.

For example, YooKassa’s incoming notification documentation describes how payment changes are received. The specification therefore needs to connect a confirmed payment state to a particular order, rather than stop at a “Thank you for your purchase” page. Another provider will have its own details.

The following is a fragment to discuss, rather than a complete universal specification:

The order persists after the page is closed

The final scenario shows why states matter: an order continues to exist independently of the customer’s open page. Notification fields, verification and recovery procedures need to be defined against the chosen integration’s documentation.

Give external data exchanges clear boundaries

For integrations, specify which data each system receives, who changes it and how an error is detected. Expand “send the order to the CRM” with a field list, transfer timing and a retry rule. If the connection breaks, an employee needs a clear way to discover that the order has not been transferred.

Describe the expected result for an operation that may be repeated. For example, YooKassa documents request idempotency: a repeat with the same data and key returns the original request’s result within 24 hours of the first request. After that, the repeat is treated as a new request, so the application needs its own operation records. The specification can state the business requirement—repeating a request must not create an extra operation—and require an agreed implementation within the provider’s contract.

Assign responsibility for access and connection setup. A developer cannot test an exchange with accounting software if its administrator has not provided a test environment. Record that dependency beside the requirement so both sides understand the cause of a delay.

Define search, access and recovery requirements

Replace “SEO included” with manageable deliverables: product and category URLs, titles, a sitemap, filter rules and redirects during migration. Google’s ecommerce URL guide explains the problems with duplicate and unstable URLs. Define the page structure in the specification; a promise of search positions does not belong in development acceptance criteria.

Describe staff permissions by action. Who edits prices, issues refunds and creates other users? A “manager” role without a permission list does not answer those questions. Discuss access to financial operations separately from access to product descriptions.

For operation, identify who owns backups, what data is saved and how recovery is verified. If a particular load is specified, name the testable scenario, environment and agreed limits. “Works quickly” does not give client and contractor a shared criterion.

Agree on the document without endless detail

The specification can be refined during investigation. It needs a version, the parties who approved it and a process for accepting changes. An unknown warehouse configuration or unconfirmed export format needs investigation; a written assumption should not silently turn into a promise.

Before approval, walk through the future order with the person who will pick and dispatch it. Ask them to show where they see payment, change the contents and record a cancellation. This connects requirements with the company’s actual work.

Once requirements are agreed, they make it easier to compare developers’ estimates for the same scope.

If all you have is a business description and a sample catalogue, that is already enough to start discussing online store development. At pommeDeTerre, you can examine the future order journey and identify the decisions needed to prepare a technical specification and estimate the first release.