If you run a business in the United Kingdom and the shop you want built will be built by a team somewhere else, the location matters far less than the brief. Remote builds go wrong for the same reasons local ones do: nobody agreed what "next-day delivery" actually promised, nobody decided whose name the payment account is in, and nobody asked how stock is counted today. Settle those and a developer four or five hours behind you is a scheduling question, not a risk. Below are the specifics worth pinning down before anyone writes code: the UK details that shop software gets wrong by default, how to organise the working week, which GDPR questions belong in the build, what ownership and handover should include, and what actually drives the size of the job.
Start with how you sell, not with a platform
The platform question is the second question. The first one is how an order moves through your business right now, in detail, including the parts you find embarrassing.
A tile supplier sells by the square metre but ships in boxes, so the basket has to round up and tell the customer why. A butcher sells by weight with a cut-off time that changes on Fridays. A brewery needs a case discount and an age check. A parts distributor takes half its orders by phone and needs those orders to appear in the same place as the online ones, on an account with agreed terms.
None of that is exotic, and none of it is what a stock template assumes. Templates assume one fixed price, one unit, one delivery promise, one type of customer. Write down the real sequence instead: who takes the order, what gets checked before it ships, what gets printed, and what gets typed into a second system by hand. That last item is usually where a custom store earns its money back, because it is the step that quietly costs you an hour a day.
The UK details that belong in the brief
Ask how each of these will be handled before the build starts, not during testing:
- VAT presentation: inclusive prices for consumers, exclusive for trade buyers, and whether you need both views. Zero-rated and reduced-rate lines need to be set per product, not shop-wide.
- GBP as the base currency, with rounding decided deliberately. If you also sell into the EU, decide whether other currencies are display-only or genuinely charged.
- Delivery zones: mainland, Highlands and Islands, Northern Ireland, BFPO addresses. Weight bands or basket bands. Click and collect. Courier cut-off times, and whether the site promises working days or calendar days.
- Shipping into the EU: whether you ship duties-paid or duties-unpaid, and exactly what the checkout tells the customer so there is no surprise on the doorstep.
- Returns: the window you offer, and whether the shop issues a label or simply sends an email with instructions.
- Address and phone input: postcode lookup, optional county field, numbers that accept both 07 and +44 formats.
- Payments and accounting: cards plus the wallets your customers actually use, Direct Debit or invoicing for trade accounts, and whether orders land in Xero, Sage or QuickBooks on their own.
A provider based elsewhere will not guess the Highlands surcharge or the zero-rated book. They will build it correctly if you tell them, and a good one will ask.
Working across time zones without losing a week
Time zones cost you days only when questions queue up. The pattern that works is simple: decide asynchronously by default, and keep a short daily overlap for the things that need voices.
Before you start, ask three questions. What hours overlap with UK working hours? What happens to a question sent at 16:00 your time? Is there a staging site that always reflects the latest build, so you can look at progress without arranging anything?
Then hold up your end. Batch feedback into one review a day rather than sending twelve messages. Keep a single running list of decisions with dates, so "we agreed to charge for Saturday delivery" does not get relitigated in week four. Record a two-minute screen capture when something is hard to describe in text, because watching someone try to place an order is worth a page of explanation. With a few hours of genuine overlap, a UK client and a developer abroad can run a build more tightly than two people in the same city who only meet on Thursdays.
The GDPR questions that belong in the build
This is not legal advice, and your own adviser should confirm what your business must do. But several GDPR-adjacent decisions are build decisions, and they are much cheaper to make at the start.
Ask where customer data is hosted and where backups are stored. Ask what your cookie banner actually blocks: analytics and advertising scripts should not load before consent, and plenty of sites have a banner that blocks nothing. Ask whether you can find, export and delete one customer's data from the admin yourself, without raising a ticket, because subject access requests arrive on their own schedule. Ask how long abandoned baskets and guest checkouts are kept, and whether marketing consent is recorded separately from the order.
You will also want a plain list of every third party the shop sends data to: payment provider, email service, hosting, analytics, review platform. Your privacy notice has to be accurate, and it cannot be accurate if nobody wrote down what the site talks to. Card details themselves should live with the payment provider, never in your own database.
Ownership, accounts and what handover means
The rule to hold firm on: the accounts are in your name from day one, and the developer is invited into them. Not the reverse. That covers the domain registrar, DNS and hosting, the payment gateway, the email sending service, analytics and the code repository. It is a five-minute decision at the start and a painful one to unpick later.
Get it in writing that you own the finished work, and ask what licences the site depends on so you know what renews. Then agree what handover looks like before you need it:
A recorded walkthrough of the admin. A short written document saying where everything lives and who the suppliers are. Instructions for the things you will genuinely do yourself: adding a product, changing delivery bands, running a discount, issuing a refund. And an answer to the awkward question of what happens if you stop working together, including who holds the keys and how quickly another developer could pick it up.
What makes the job bigger or smaller
Quotes vary widely, and anyone giving you a figure before understanding your catalogue is guessing. The things that move the number are fairly consistent, though.
Product complexity is the big one: variations, pricing rules, bundles and anything sold by measure. Next is how many systems have to talk to each other, since each integration is its own small project with its own edge cases. Then the state of your product data, because cleaning up a spreadsheet of 2,000 items with inconsistent names and missing weights is real work that someone has to do. Trade accounts with their own prices and credit terms add a second shop behind the first. Content and photography are often underestimated. And if you already have a site, migrating old URLs properly so your existing search rankings survive the move is not optional, even though it is invisible.
Your next step
Before you brief anyone, write one page describing how an order travels through your business today, from first enquiry to the point where the money is reconciled. Include the steps done by hand and the ones that go wrong. That page tells a developer more than a list of features ever will, and it tends to surface the decisions that cost money if they are made late.
When it is ready, send it to someone and ask what they would build. WebShift Studios is two developers, Anthony and Ryan, who build online stores, portals and integrations for clients remotely, so being in different countries is the normal arrangement rather than a workaround. You can see how we approach the work on our web development services page and get in touch from there, or email hello@webshiftstudios.com with your page and we will tell you what we would ask next.