What I build
React & Next.js storefronts
Catalogue, variants, cart and checkout — built as a front end you own, not a theme you rent.
What this is
I build storefronts in React and Next.js: a catalogue a shopper can filter, product pages where size and colour actually change the line item, a cart that agrees with both, and the account and checkout screens that finish the journey. Four of them are live on this site — one on the Next.js App Router, three on React 19 — and a fifth, PLINTH, solves the same shop in Laravel. Every one opens in a new tab.
How it is built
Next.js App Router with React 19 and TypeScript, styled with Tailwind CSS 4. Pages are server-rendered and prerendered where the content allows, so the first paint is HTML rather than a spinner. Motion is GSAP or Motion, used on composited properties so it does not fight the scroll.
- One catalogue as the single source of truth, so the shop, the product page and the cart cannot disagree
- Variant state that resolves on the client — size, grind, colour — without a round trip per click
- Responsive from a phone up, built mobile-first rather than scaled down
- Deployed to your hosting account, on your domain, and handed over
Where the shop stops being a front end
A storefront that takes real money needs two things a front end cannot supply on its own: a payment provider account in your name, and somewhere the products and orders actually live. Both belong in the brief rather than being discovered late. The builds on this site deliberately stop short of that line — they complete the whole journey as interface work, with self-created products and no payment taken — which is exactly what they are labelled as on their case studies.
Server-rendered, if that suits the project better
Not every shop wants a React front end. PLINTH on this site is a Laravel build — server-rendered Blade templates with collection filters, product configurators, a bag and account screens — and the same work in that shape is on the table when a PHP host or an existing Laravel codebase is the constraint.
What you get
- Catalogue with filters and sorting
- Product pages with real variant selection and add-to-cart
- Cart, checkout flow and order confirmation screens
- Account and sign-in screens where the project needs them
- Share previews, metadata and a sitemap set up properly
- Deployed on your domain and handed over
What it does not include
- Payment capture needs a provider account in your name — I integrate it, you own it.
- Product data needs a home: a CMS, a commerce back end, or a catalogue in the codebase. Which one is a brief decision, not an afterthought.
- Product photography and copy are not included unless we agree them as part of the scope.
The work behind it
Shipped, live, and open in a new tab
- E-commerce · Specialty coffeeAsh & Orbit: Next.js StorefrontThe fullest journey of the five: roast filters, size and grind selectors that change the line item, a slide-out cart, an account area and a subscription section.Read the Ash & Orbit case study
- E-commerce · StreetwearFORM / AFTER: React StorefrontThe same problem solved in React 19 and Vite rather than Next.js, with a complete demo checkout.Read the FORM / AFTER case study
- E-commerce · Beauty & cosmeticsShynx Store: React Cart & WishlistA beauty catalogue with the shade and size variants that make product pages harder than they look.Read the Shynx Store case study
- E-commerce · HomewareHearth & Hollow: React Shop DemoA homeware range where the catalogue has to carry room sets and materials as well as products.Read the Hearth & Hollow case study
- E-commerce · JewelryPLINTH: Laravel Jewelry StoreThe server-rendered alternative: the same shop shape in Laravel and Blade.Read the PLINTH case study
Scope, timing and support
What you can expect, before you ask
Timing
- E-commerce Website
- quoted per project
The E-commerce Website tier is quoted per project rather than off a published timing: the number of products, the way they vary, and whether checkout has to settle real money drive most of the work.
After handover
30 days of bug fixes after handover
The same on every package — it does not scale with the tier.
Covered
- Anything inside the agreed scope that does not work the way it was agreed.
Not covered
- New features, content changes and design changes — those are new work, quoted separately.
- Anything that was never in the agreed scope.
- Breakage caused by third parties or by editing the delivered code yourself: hosting changes, expired services, dependency changes outside the build I handed over.
The 30 days run from handover. Ongoing support and maintenance are available separately.
Hosting, domains and paid services
Every account is in your name. You own the domain, the hosting and the data; I configure and deploy into them. Nothing is held on my accounts.
You pay third parties directly. Nothing is billed through me.
Many projects run comfortably on free tiers — Vercel, Cloudflare — and I will use them where they genuinely fit. A site with real traffic or heavier requirements may need a paid plan, and I will say so before we start rather than after.
- Domains always cost money. There is no free tier for a real domain.
- Paid APIs and services are pass-through, billed to your account.
- Licensed fonts and stock imagery are pass-through.
Send these six things and the quote means something
- What you sell, and who buys itTwo lines is enough. It decides nearly everything else.
- Roughly how many products, and how they varySize, colour, grind, bundles — variants are what make a product page harder than it looks.
- Whether checkout has to take real money yetA front end that completes the journey and a shop that settles card payments are two scopes, and the second needs a provider account in your name.
- Where the products and orders should liveA CMS, a commerce back end, or a catalogue in the codebase. That is a brief decision, not an afterthought.
- A shop whose feel you like, and what you like about itA reference plus a reason is worth more than a long description.
- Whether the product photography and copy exist yetContent is usually the thing that moves a date, so it is better known up front.
Also available
Other services
What happens next
Send the six answers above — two lines each is plenty. I reply with what I would build, how long it would take and what it would cost, usually within a day.