E-commerce websites with checkout that actually works

What e-commerce development actually means

E-commerce website development means building an online store that takes real money: a product catalogue a customer can navigate, a cart that survives a page refresh, a checkout that handles tax and shipping rules, and an order lifecycle that continues correctly even when the customer closes the browser mid-payment.

It is not a design job with a payment button added at the end. The catalogue model — what a product is, what varies, what changes the price — decides the architecture, and it is the one decision that is expensive to reverse. That is why it is the first thing I write down and the last thing I would let a client skip.

What you are hiring when you hire an e-commerce website developer, as opposed to a designer, is someone who owns that model and the payment lifecycle attached to it. Six of the fifteen sites I have shipped are online store development projects, and every one of them takes real card payments today.

Who this is for

• Retailers with a physical or digital product who currently take orders by phone, email or DM
• Businesses on a hosted platform that has hit a wall they cannot climb — usually a checkout rule the platform will not allow
• Resellers whose product configuration does not fit a normal variant dropdown
• Anyone whose current store loses orders when a payment succeeds but the browser does not come back
• Businesses that need to sell into more than one country with different tax treatment

Who it is not for

Saying this out loud costs me some enquiries and saves both of us the ones that would have gone wrong. If you are on this list, I will tell you in the first reply rather than after a deposit.

• Marketplaces with multiple independent vendors, payouts and disputes — that is a platform build, not a store
• Businesses that need an ERP or accounting system integrated end to end on day one
• Anyone whose catalogue is genuinely conventional and who would be served faster and cheaper by Shopify. I will tell you when that is the case
• Projects where nobody internally owns product content, because the build finishes and the store stays empty

The problems it solves

Orders lost at the payment step

Fulfilment is driven by the payment provider webhook rather than the browser redirect, so a closed tab cannot produce a charged customer with no order.

A catalogue nobody can administer

Configurations are modelled as first-class database rows rather than variants bolted onto a product, so the admin screen matches how the business actually thinks.

Prices that need a phone call

Rules and formulas are stored as data and editable, so made-to-measure or configured pricing shows a real number before the customer commits.

Confirmation emails in spam

Transactional mail sends from an authenticated domain with SPF, DKIM and DMARC aligned.

A store nobody can find

Crawlable category and product URLs, product schema matching the visible page, and a generated sitemap — done during the build rather than as a later project.

What you get

• Product catalogue with categories, search and filtering
• Cart and a checkout that handles tax, shipping and discount rules
• Stripe payment integration, tested against live card scenarios
• Automated order confirmation and admin notification email via PHPMailer
• Admin area for products, stock and orders
• Mobile-first responsive build — designed on a phone screen first
• Technical SEO baseline: schema, sitemap, meta, Core Web Vitals pass
• Deployment, domain and SSL configuration, plus a 30-day snag list

What is included in the starting price

Everything below is in the $150 figure. Nothing here is quoted as an extra once the build is underway, which is the point of publishing it.

• Catalogue model written down and signed off before any code
• Responsive front end, designed against a phone screen first
• Cart and checkout with tax, shipping and discount rules
• Payment integration tested against declines, 3D Secure and refunds — not only the happy path
• Automated order confirmation and admin alert email
• Admin area a non-technical person can run the business from
• Technical SEO baseline and Search Console setup at launch
• 30 days of snag fixes after go-live

What costs extra, and why

A quote that omits these is not cheaper — it is less honest. Each one is real work that someone has to do, and pretending otherwise is how a fixed price becomes a negotiation in week two.

Product content entry

Loading several hundred products by hand is real time. Quoted separately once we know the count.

Photography and copywriting

I build; I do not shoot product photography. I will tell you what is needed and what good looks like.

Third-party integrations

Accounting, dispatch, ERP or supplier feeds are each their own small project with their own failure modes.

Migration from an existing store

Products, customers, orders and a redirect map. Quoted on catalogue size, and the redirect map is not optional.

Multi-currency and multi-region tax

Worth doing properly when you genuinely sell across borders, and worth skipping when you do not.

How the work runs

1. Scope. We agree the catalogue size, payment flows and integrations in writing. You get a fixed quote — not an hourly estimate that drifts.
2. Build. I build on a staging URL you can open at any time, updated daily. No black box, and on a build this short there is no week where nothing visible happens.
3. Payments. Stripe goes in early and gets tested against real card scenarios — declines, refunds, 3D Secure — not just the happy path.
4. Launch. Deployment, SSL, redirects, analytics and Search Console. The site goes live indexed, not as a blank shell.
5. Aftercare. 30 days of snag fixes included. Then either you run it, or I maintain it monthly.

Day by day

7 days from the day scope is signed off. Published as a schedule rather than a promise of speed — you should be able to tell on day three whether a build is on track.

The technology

Deliberately boring, and that is the feature. A stack another developer can pick up is worth more to you than one that impresses other developers.

Application

PHP 8 with MySQL, or WordPress with WooCommerce where content publishing matters more than custom logic

Front end

Tailwind CSS with Alpine.js for interaction. No framework runtime unless the project genuinely needs one

Payments

Stripe Checkout, including subscriptions, with webhook-driven fulfilment

Email

PHPMailer over authenticated SMTP

Hosting

Whatever you already pay for, if it is adequate. Usually shared cPanel — I will say when it is not enough

What it integrates with

• Stripe — one-off orders, subscriptions, refunds and 3D Secure
• Local and alternative payment methods where your market expects them
• Shipping rate calculation by weight, zone and order value
• Transactional email through your own domain
• Accounting exports in a format your bookkeeper will accept
• Any documented REST API — supplier feeds, dispatch, inventory

What I need from you

Short list, and the first item matters most. Projects do not usually slip because the code was hard — they slip because a decision waited a week.

• A decision-maker who can answer questions within a day. On a 7-day build this matters more than anything else
• Product data: names, descriptions, prices, variants, stock. A spreadsheet is fine
• Product photography, or a decision to use what exists
• Your Stripe account — created in your business name, with your bank details
• Hosting and domain access, in your name, not mine

Content and photography

Product content is the single most common reason a build slips. The code is finished and the store has eleven products in it because nobody was assigned the other three hundred.

Manufacturer descriptions are the easy option and the weakest one — two hundred other stores published the same paragraph, which gives a search engine no reason to prefer yours. Rewriting the descriptions for the products that actually sell is the highest-return content work in most stores, and it is worth doing for twenty products rather than badly for two hundred.

Performance standards

Targets, not aspirations — measured before handover on a throttled mobile connection rather than on a fast laptop.

Accessibility standards

This site is built to the same standard it sells, and the accessibility statement lists what is conformant and what is not — which is the part most statements leave out.

Security practices

The SEO included in every build

Not an upsell. A site that launches unindexed is a shop with the shutters down, and the work below is cheap during a build and expensive afterwards because the fixes are structural.

Ownership and handover

You own everything: the domain registered to you, hosting in your account, code in a repository you control, and the payment provider account in your business name. Credentials are handed over as they are created rather than at the end.

A supplier who resists this is protecting recurring revenue rather than your interests. If you want the reasoning in full, including how to check your current site, there is a guide on it.

Aftercare and what happens after launch

Thirty days of snag fixes are included. A snag is something that does not work as scoped — not a new feature, and the difference is written down before launch rather than argued about after it.

You also get written handover documentation aimed at whoever maintains the site next, which may well not be me. That is deliberate: the test of a good handover is whether another developer could take over without calling me, and on my projects they can.

Ongoing maintenance

Optional, monthly, cancellable. Nothing here is required to keep what you paid for.

Payment terms

How this compares to the alternatives

Including the routes that do not involve me, because a comparison that only flatters the author is not a comparison.

What could go wrong, and how it is handled

Content is not ready on day one

Flagged at scope. The build proceeds with placeholders and the launch date moves — I would rather tell you in week one than in week three.

The catalogue turns out to be more complex than described

This is what day one exists to catch. If the model changes materially, the number is re-quoted before work continues, never silently absorbed.

Payment provider rejects the business type

Checked early. Some categories are restricted by Stripe and it is far cheaper to discover that before the build than after.

You want to leave

You can. The code is in your repository, hosting and payment accounts are in your name, and handover documentation is a deliverable rather than a favour.