Questions to ask an ecommerce developer before you sign

Get ownership in writing. The contract must state that source code, Figma files, database schema and copy become yours on final payment, and any part under the developer’s licence must be named.

Ask where the code lives. A private GitHub or GitLab repository under your organisation is good, while a zip file on a freelancer’s laptop is not, and you should say so plainly.

Ask about every paid theme, plugin and font, then ask who renews each licence when the year ends and the card on file has expired. Lapsed licences break sites.

Ask who opens the hosting account and whose card pays the invoice, because admin access must be yours from day one even when the developer manages the server. Ask how nightly backups run, how long they are kept, and which person has actually restored one from a copy to a working site.

Ask about the gateway separately. The merchant account must carry your business name and bank, so a developer who routes takings through their own Stripe or PayPal account is holding your cash.

Warning signs sound friendly, such as we handle all that, you do not need the login, and it is simpler if the account stays in our name.

Get a test plan before development starts. It should list test orders for each payment method, a declined card, a refund, a discount code, a split shipment and a guest checkout. Without expected results, a test proves nothing. Ask for a screen recording of each test order from basket to confirmation email, so you can see the discount code and the tax line applied.

Insist on a staging site. Place those orders yourself, and walk through checkout on a phone with a weak signal, since many buyers will arrive that way.

Ask how they test order emails, tax rules and shipping rates and the stock count after each order, then ask who signs the launch note. The answer should be you.

A proper handover is a package. It holds admin logins, repository access, a deployment runbook and environment variables kept in a password vault, so nothing depends on one person’s memory or inbox. Add a list of integrations with their API keys, and a short recorded walkthrough of the admin panel for whoever joins your team later.

Test it. Could another developer take over from that package alone, without phoning the original builder for a password or a missing step? If yours hesitates, one head holds everything.

Make the documentation a deliverable. Attach a payment milestone to it, so the final instalment is released only after the handover package has been checked by someone other than its author.

Define the terms. A bug is a fault in the delivered work, fixed at no charge for a stated period, while a change request is new work billed separately. Ask for response times, support hours and a phone number that works for a checkout outage on a Sunday night, when nobody is in the office to notice.

Ask what the first month includes. Who watches the error log and the order queue, and how are security patches for the platform and its plugins applied, and how often?

Email them before signing. File the replies with the contract, because a written answer gives you a record to point to when a dispute starts, and a sales call never does.