Websites
The storefront is the visible half of an e-commerce build and the easier one. What decides whether the business enjoys running it is everything between somebody paying and somebody receiving a parcel. The list we work through before a store opens.

The storefront is the visible half of an e-commerce project and the easier one. What decides whether the business enjoys running the store is everything that happens between somebody paying and somebody receiving a parcel, and almost none of it is on the screen the customer sees.
This is the list we work through before a store opens.
Write down what happens after the payment
The order is recorded with a reference the customer can quote on the phone.
The customer receives a confirmation showing what they bought, what it cost and when it should arrive.
Somebody is told there is an order to pack, in a way that does not depend on a person refreshing a page.
Stock comes down, in whichever system holds the real count.
The parcel goes out with a tracking reference, and the customer is told it has.
Delivery is recorded, so a dispute two weeks later has an answer.
Each line is a decision about who does it and what they use to do it. A store that opens before those answers exist runs on a chat group for its first month, and the first disputed order is the day everybody finds out that nothing was written down.
Payments: trust the server, never the browser
Take card payments through a gateway with an account registered to the business. The important part is what marks an order as paid. The confirmation must reach your server from the gateway, not from the page the customer is looking at, because a success page can be opened by anybody who knows the address.
// The gateway posts here once it has taken the money. Check the signature before
// anything is marked paid: this address is public and anybody can post to it.
const expected = crypto
.createHmac("sha512", process.env.PAYSTACK_SECRET_KEY)
.update(rawBody)
.digest("hex");
if (expected !== request.headers["x-paystack-signature"]) {
return new Response("Ignored", { status: 401 });
}Bank transfer is still how a large share of orders are paid here, and it needs the same discipline in a manual form. An order stays unpaid until somebody has matched it against the account statement. A screenshot is not a match, and the person packing parcels should not be the person deciding what counts as proof.
Delivery, priced before launch
Zones and prices agreed with the courier you will actually use, before the checkout is asked to quote them.
Collection as an option. A meaningful number of buyers will come to you if you let them, and it is the cheapest delivery there is.
A rule for the parcel nobody collects: how long it waits, who is chased, and who carries the cost.
Delivery times written as a range in working days per zone, chosen so you can keep it in a bad week rather than a good one.
Stock that matches the shelf
One count, in one place. If the shop counter and the website each keep their own number, the website will oversell something within a month, and the apology costs more than the sale was worth.
Decide which system holds the truth and make the other read from it. If that connection is not possible yet, hold a buffer: mark an item unavailable while the count is still above zero, so the last few on the shelf are sold in person where the count can be seen.
Write the policies before you need them
How long a customer has to return something, and in what condition.
Who pays for return delivery, and whether that differs when the fault is yours.
How a refund is made and how long it takes to appear.
What happens to a parcel that arrives damaged, and what evidence you ask for.
Whether an order can be cancelled before dispatch, and how.
These pages are read by buyers deciding whether to trust a store they have never used, so plain wording is worth more than legal padding. A returns page that a person can understand in thirty seconds sells more than a page of clauses copied from somewhere else.
Product pages that can be found
One page per product, with its own address, its own title and its own description. Products that exist only behind a search box with no address of their own cannot be found by anybody who is not already on your site.
Several real photographs, including one that shows scale. A single supplier image is the same picture your competitors are using.
Descriptions written in the words a buyer would type, including the local name for the thing where there is one.
Product structured data, so availability and the price shown in a search result match the page.
Then buy something from yourself
Before launch, place a real order with a real card, from a phone, on mobile data, and take it the whole way: confirmation, packing, dispatch, delivery, then a refund. Every store we launch has had at least one order placed by the person who owns it, because the first person to find the broken step should not be a customer.
A store is not finished when it can take an order. It is finished when somebody in the building knows exactly what to do with one.
What a store build includes is set out on the web development page, and there are finished projects on the portfolio. If you are planning one, tell us what you sell and how it reaches people and we will tell you which parts of this list are already decided for you.
Filed under
Get the next one by email
What we have built, what we learned building it, and news from the Event Space. A few times a month, and one click to stop.

