Free template

E-commerce project checklist

A store: catalogue, payments, tax, shipping and fulfilment. 181 items across 8 stages, 40 of them needed from the client.

For: The whole delivery team

01Before we start

Signed proposal or contractKeyFrom client
Countersigned, not "verbally agreed". Work started on a promise is work that may not be paid for.
Deposit or first invoice paidKeyFrom client
The payment condition in the contract, met. This is the line the sales SOP will not let a project pass.
Decision-maker confirmed by nameKeyFrom client
Who signs things off, and who can say no. A project approved by a committee is a project approved by nobody.
Day-to-day contact named, and their working hoursFrom client
Including timezone. Half of "they are slow to respond" is a five-hour offset nobody wrote down.
Billing contact and PO or reference number, if they need oneFrom client
Ask now. An invoice rejected in month three for a missing PO number delays payment by a month.
Sales-to-delivery handoff completedKeySales
Call notes, proposal versions, commitments, risks and stakeholders - everything promised during the sale, in writing, where delivery can read it.
Scope, exclusions and assumptions restated in our own wordsPM
Written by the people delivering it, not copied from the proposal. Rewriting it is how you find what the proposal left ambiguous.
Project workspace, folders and client portal set upPM
Client invited and confirmed able to sign in - not "invitation sent".
Team assigned with named owners per disciplinePM
One name per discipline. "The design team" is not an owner.
Commercials checked against capacity before any date is promisedPM
The PM SOP puts this before assignment on purpose: a timeline agreed without checking the calendar is a timeline that will be missed.
NDA or data-handling requirements identifiedPM
If they handle health, financial or children’s data, that changes where things may be stored - and it is cheaper to know now.

02Kick-off

Review turnaround agreed in working daysKeyFrom client
How long feedback takes. Every date in the plan is built on this number, so it is agreed rather than assumed.
Feedback consolidated through one personFrom client
Contradictory feedback from three stakeholders is the single most common cause of rework.
Client team introduced, including anyone who can vetoFrom client
The person who appears in week eight to reject everything was always going to appear. Better in week one.
Holidays, launches and blackout dates on both sidesFrom client
Their trade show and our public holidays, on the plan before it is signed off.
Kick-off call held with the decision-maker presentKeyPM
Whole delivery team plus whoever signs off. A kick-off without the decision-maker has to be repeated.
Milestones and delivery dates agreed in writingKeyPM
With internal review dates set before each client-facing date, never on the same day.
Kick-off notes circulated with decisions, owners and next actionsPM
Within 24 hours, while people still agree on what was said.
Communication channel and update cadence agreedPM
Where we talk, how often we report, and what counts as urgent. Written down, so "I messaged you on WhatsApp" is not a delivery method.
Escalation path agreed both waysPM
Who to call when something is going wrong, on their side and on ours, before it is going wrong.
Change-request process explained and acceptedPM
How a new request gets costed and scheduled. Explaining it at the kick-off is a conversation; explaining it in week seven is a confrontation.
Risks and dependencies logged with ownersPM
The PM SOP asks for risks raised early with a proposed solution, not only the problem.
QA present at the internal kick-offQA
QA that joins after the build has already missed the requirements it is meant to test against.

03Discovery

Brand assetsKeyFrom client
Logo in vector, fonts with their licences, colour values, existing guidelines. "We will send the logo" usually means a PNG off the website.
Copy supplied, or a decision that we write itKeyFrom client
The single most common cause of a stalled design project. Designing around copy that has not been written means designing twice.
Domain registrar access, or a named person who can change DNSKeyFrom client
Find this out in week one. Discovering on launch day that nobody knows the registrar password is a launch that slips.
Product catalogue in an importable formatKeyFrom client
Names, descriptions, prices, SKUs, variants, stock. A spreadsheet we can import, not a PDF.
Payment gateway account, in the client’s nameKeyFrom client
Their merchant account, their bank details. Money must never route through us.
Acceptance criteria agreedKeyFrom client
What "done" means, written before testing rather than argued after it.
Business goal for this project, in a numberFrom client
More leads, fewer support tickets, faster checkout. Without a number, "did it work" is a matter of opinion.
Who the audience is, and what we want them to doFrom client
Competitors you actually lose toFrom client
Not the biggest names in the category - the ones that come up in your deals.
What must not changeFrom client
The thing their customers recognise, or the integration that cannot break. Cheaper to hear now than to rebuild later.
Examples of work you like - and work you do notFrom client
Three of each is plenty. The dislikes are more useful than the likes, and faster to act on.
Photography and video supplied, or approval to licence stockFrom client
Sitemap or screen list signed offFrom client
The thing that turns "a website" into a countable amount of work.
Hosting account, or a decision that we provide itFrom client
Third-party accounts and API keysFrom client
Analytics, email, CRM, payments, chat - whatever the build touches. Sent through the vault, never in a chat message.
Existing site and CMS access, if we are replacing somethingFrom client
So content can be migrated rather than retyped, and so old URLs can be redirected rather than lost.
Content ready, or a signed-off placeholder planFrom client
Legal pages supplied or approvedFrom client
Privacy, terms, cookies. Their lawyer’s wording, not ours - we are not the ones who carry it.
Product photography, consistent in crop and backgroundFrom client
Tax rules and the regions you sell toFrom client
Including whether prices are shown with or without tax, which changes every price on the site.
Shipping rates, zones, carriers and free-shipping thresholdsFrom client
Returns, refunds and cancellation policyFrom client
Who fulfils orders, where they are notified, and what they need to seeFrom client
Test accounts, sample data and any sandbox credentialsFrom client
Devices and browsers that matter to their usersFrom client
Their real analytics beats our assumptions, and usually shortens the matrix.
Requirements written down and confirmed back to the clientKeyPM
In their words and ours. The confirmation is the point: it is where a misunderstanding surfaces while it is still free.
Accessibility target set before design startsKeyDesign
WCAG 2.2 AA is the default expectation for commercial work now. Contrast and text sizing are cheap to design in and expensive to retrofit.
Browser and device support agreed and written downKeyDev
Including what is out of scope, so a request in week eight has an answer that is not an argument.
Test plan written: scope, environments, device matrix, risk areasKeyQA
Plus the severity classification - critical, high, medium, low - agreed before the first bug is raised, so severity is a fact rather than a negotiation.
Existing material reviewed before asking for morePM
Their analytics, support tickets and sales objections are research that is already written down and already paid for.
Dependencies mapped between content, design, build and approvalsPM
Which piece cannot start until which other piece finishes, and who is holding each one.
Missing information listed and requested as one batchPM
One clear request beats eleven emails over three weeks, and gives the client something they can actually work through.
Task breakdown created with owners, reviewers and internal deadlinesPM
Design review rounds agreed, and what happens after themDesign
How many are included, and what an extra round costs. Agreed now, not during round four.
Performance budget setDev
A target before anything is built: LCP under 2.5s, INP under 200ms, CLS under 0.1 on the pages that matter.
Technical approach agreed and the reasons recordedDev
Stack, CMS, integrations. Written down because in a year the reasons are what make the next change cheap.
Test cases written: module, scenario, steps, expected result, priorityQA
The tracker format from the QA SOP. Test cases written after testing are a description, not a plan.

04Build

Staging environment live and shared with the clientKeyDev
Password-protected and excluded from search engines. A staging site that gets indexed competes with the real one.
Environment variables and secrets stored in the vaultKeyDev
Not in the repository, not in a chat message, not in a spreadsheet called passwords.
Backups running, and a restore actually testedKeyDev
A backup nobody has restored from is a belief, not a backup.
Art direction or moodboard shared and agreedDesign
Agreeing direction before pixels is what stops round two being a restart.
Wireframes for the key templatesDesign
Structure agreed while it is still cheap to move.
Design system started: type scale, spacing, colour and componentsDesign
Built as styles and variables, not hand-typed values - which is how a design system quietly stops being one.
Every screen designed at mobile as well as desktopDesign
Designed, not "it will reflow". Reflowing is a decision somebody makes; if it is not the designer, it is the developer, at 6pm.
Interaction states designed: hover, focus, active, disabled, loadingDesign
Focus especially. It is the state that keyboard users live in and the one that is skipped most.
Empty, error and success states designedDesign
The three states every design skips and every user eventually meets.
Forms designed with labels, validation, error wording and long-value behaviourDesign
Including what a field looks like with a 60-character value in it.
Content extremes testedDesign
The longest product name, the shortest bio, eleven nav items. Designs break at the edges, never in the middle.
Repository created, access granted, branching agreedDev
Built from the design system rather than from screenshotsDev
Tokens and components, so a colour change is one change.
Responsive behaviour implemented at the agreed breakpointsDev
375, 768, 1024 and 1440 as the baseline, plus whatever their analytics actually shows.
Forms wired end to end, including where a submission lands and who is toldDev
A form that validates beautifully and emails nobody is the most common launch bug there is.
Content editable by the client where it was promised to beDev
If they were told they could change it themselves, check that they can, on their own login.
Error and empty states built, not just the happy pathDev
Analytics and error reporting installed and firingDev
Rollback plan written for launch dayDev
What we do if it goes wrong, decided while nobody is panicking.
Redirect map built from the old URLs, if replacing a siteDev
Every indexed URL either resolves or redirects. This is where migrations lose traffic.
Store built and catalogue imported, with variants and stock correctDev
Tax and shipping calculations verified against the rules givenDev
Test one order per zone. Tax that is wrong by 2% is wrong on every order.
Order, shipping, refund and failure emails configured and testedDev
Stock behaviour decided for out-of-stock and oversold itemsDev
Abandoned-cart and back-in-stock flows set up, where in scopeMarketing
E-commerce analytics and conversion tracking installedMarketing
Purchase value and items, not just a thank-you page view.
Environment readiness confirmedQA
Staging opens on every device, logins work, permissions are right, and test payments and dummy data are enabled.

05Internal review

Internal review complete before anything reaches the clientKeyPM
The PM SOP is blunt about this: no drafts, no unreviewed work, no outdated versions sent to a client.
Developer handover walkthrough heldKeyDesign
Walk the build team through the deliverables, show where assets live, and answer questions in the room rather than over three days of messages.
Admin routes and private data confirmed protectedKeyDev
Log out and try to reach them. Security by nobody-knowing-the-URL is not security.
Checkout tested with a real low-value live transactionKeyQA
Then refunded. Sandbox passing and live failing is common enough to be expected.
Responsive pass at 375, 768, 1024 and 1440KeyQA
No overflow, menus behave, tap targets at least 48px, forms scroll and submit.
Browser pass on at least three: Chrome, Safari, and Firefox or EdgeKeyQA
Safari on real iOS, not an emulator - it is where the differences actually live.
Regression pass after fixesKeyQA
Re-test every resolved issue and re-walk the key flows. Fixes break things; that is what regression testing is for.
Reviewed against the scope, not just against "does it work"PM
Every requested item, every feedback point, every agreed state present.
No placeholders, lorem ipsum, or test content left anywherePM
Version and file naming correct, and the client is getting the right onePM
Sending v3 when v4 exists costs a review cycle and some credibility.
Colour contrast measured, not eyeballedDesign
4.5:1 for body text, 3:1 for large text and interface elements.
Spacing, alignment and type scale consistent across every screenDesign
The QA SOP calls this out for a reason: it is what separates finished work from nearly finished work.
Only design-system styles used - no manually entered colours or one-off sizesDesign
A hand-typed hex is how a design system starts drifting, one screen at a time.
File organised and named for someone who did not build itDesign
Pages, layers and components named. Handing over a file only its author can navigate is not handing it over.
Design decisions annotated where the reason is not visibleDesign
The annotation answers the developer question you would otherwise answer in a call.
Code reviewed by someone who did not write itDev
No console errors on any page, including during interactionsDev
Images optimised and served in a modern formatDev
Nothing over 100KB without a reason, and nothing scaled down in the browser.
Unused libraries, dead code and commented-out blocks removedDev
No references to staging, test accounts or local URLs anywhereDev
Including in image paths, canonical tags and structured data.
A failed payment tested, and the message a customer seesQA
Guest checkout and account checkout both walked end to endQA
Functional pass: navigation, buttons, forms, links, sliders, popupsQA
Every module, against the test cases, not by wandering around the site.
Login, logout and session behaviour testedQA
Including what happens when a session expires mid-form.
Cart and checkout tested end to end, where applicableQA
Role-based access tested from each role, including logged outQA
The test that finds the data leak. Try to reach the thing you should not be able to reach.
Visual QA against the design fileQA
Font sizes and weights, radius, padding, margins, icon placement, white space, alignment.
At least one test on a real physical deviceQA
Emulators do not reproduce touch, keyboards, or a slow connection on a train.
Accessibility pass: contrast, alt text, focus order, labels, ARIAQA
WCAG 2.2 AA, checked with a tool and with the keyboard. Tab through the whole thing without touching the mouse.
Performance measured against the budgetQA
Lighthouse above 80 on mobile and 90 on desktop, Core Web Vitals within thresholds, network tab checked for oversized payloads.
SEO and metadata verifiedQA
Unique titles and descriptions, one H1 per page, Open Graph tags, favicon, alt text, sitemap and robots.
Broken links, redirect chains and the 404 page checkedQA
Forms, payments and integrations tested end to end with real submissionsQA
Follow the data to where it lands. A form is not tested until someone has received one.
Every bug logged with evidenceQA
Screenshot or recording, OS and browser, severity, steps to reproduce, and an assigned developer. A bug report without steps is a conversation.
Reopened bugs tracked rather than quietly re-closedQA

06Client review and sign-off

Written sign-off recordedKeyFrom client
In the portal or in writing. Per the MSA a portal approval is binding, which is exactly why it is worth having.
Feedback collected in one placeFrom client
One thread, one document. Feedback spread across email, calls and messages is feedback that will be missed.
QA sign-off given, with known issues stated honestlyKeyQA
Total cases, bugs by severity, what is deferred, and device coverage. Sign-off with a hidden known issue is not sign-off.
Walkthrough delivered rather than a link dropped in a chatPM
Ten minutes of context turns "I do not like it" into specific, actionable feedback.
Every feedback point converted into a tracked item and closedPM
Tracked by version, so "we told you about that" has an answer either way.
Anything out of scope identified, costed and agreed - not absorbed silentlyPM
Quietly absorbing scope teaches a client that scope is free, and the next request will be bigger.
Deferred low-priority bugs listed and accepted, not forgottenQA
Written down and agreed, so they are a decision rather than a discovery.

07Launch

Payment gateway switched from test mode to live, and confirmedKeyDev
The single most expensive thing to forget: a store that takes orders and no money.
Post-go-live smoke test on the live domainKeyQA
Forms, popups, carts, logins, CTAs - on production, on mobile and desktop. Staging passing is not production passing.
Launch date and window agreed, and who is available during itKeyPM
Not a Friday afternoon. Not the day before a holiday. Somebody on call for the hours after.
Pre-launch backup of everything being replacedKeyDev
Files and database, taken and verified before the switch, not after.
DNS and domain pointing confirmed, including www and the apexKeyDev
Both hosts resolve, and one redirects to the other. Sessions and SEO both depend on picking one.
HTTPS valid across every URL, with no mixed contentKeyDev
Search engine blocking removed from productionKeyDev
The staging robots rule that follows a site to production is the classic launch mistake - and it is invisible until traffic never arrives.
Analytics, GA4 and any pixels confirmed firing on productionQA
Real-time events on the real domain, before any paid traffic is pointed at it.
Lighthouse re-run on the live siteQA
Production is where the CDN, the real images and the third-party scripts finally all show up together.
Redirects live and spot-checked against the old URL listDev
Sitemap submitted and the property verified in Search ConsoleDev
Transactional email tested from productionDev
Enquiry, receipt, password reset. Check it arrives and does not land in spam - which is a different question from whether it sends.
Monitoring and uptime alerts pointed at the live domainDev
Client told it is live, and what to watch for in the first 48 hoursPM
First-week check-in booked before leaving launch dayPM
Launch is a window, not a button. Most of what a launch breaks shows up in the following week.

08Handover and close

Someone named as the owner on their sideKeyFrom client
A handover to a company is a handover to nobody. It needs a person with a name.
Final sign-off recordedKeyFrom client
Access confirmed working from their sideFrom client
Tested with them on the call - not "we have sent the details".
Testimonial or case-study permission, in writing, if they are happyFrom client
Ask at the moment they are happiest. Written permission, because the sales SOP does not allow publishing client work without it.
All credentials transferred to the client’s own accountsKeyDev
Nothing important should remain only in our name. This is the item that decides whether they are a client or a captive.
Domain, hosting and DNS ownership confirmed as theirsKeyDev
Billing for any service in our name transferred or cancelledKeyPM
Hosting, plugins, licences, mail. So nothing stops working the day our card expires.
Outstanding items and known issues written down honestlyKeyPM
Everything unfinished, deferred or broken. A handover that hides a known issue is found out, and it is found out by the client.
Repository access transferred or grantedDev
Analytics, Search Console and ad account ownership moved to the clientMarketing
Our access removed or reduced, and the client told what we keptPM
If we keep a login for support, say so in writing rather than leaving it quietly in place.
Documentation written for whoever maintains it nextPM
Written for a person who was not here, which is the only audience that matters.
Training session delivered and recordedPM
The recording is the deliverable. The person trained will leave.
Final files, source files and meeting records stored in the client folderPM
Final invoice raisedPM
Project archived here, with files and notes kept in the vaultPM
Archived, never purged - the knowledge is what makes the next project with them cheap.
Internal retrospective: what to do differently next timePM
Fifteen minutes. The PM SOP asks for one practical process improvement, not a document.
Final designs for every agreed screen, desktop and mobileDeliverableDesign
Source files handed over, organised and namedDeliverableDesign
Figma access or the working files. Access that expires is not a handover.
Component library or design system documentedDeliverableDesign
Assets exported in the formats needed, at the densities neededDeliverableDesign
Brand or usage guidelines, where in scopeDeliverableDesign
Working site or application on productionDeliverableDev
Source code in a repository the client owns or can accessDeliverableDev
Deployment and environment documentationDeliverableDev
How to build it, where it runs, what it depends on, and how to put a change live.
Admin or CMS access, with a walkthroughDeliverableDev
Warranty or support period stated in writingDeliverablePM
What is covered, for how long, and what counts as new work.
Live store taking real ordersDeliverablePM
Admin training on products, stock and orders, recordedDeliverablePM
Written process for refunds, cancellations and failed paymentsDeliverablePM
QA summary reportDeliverableQA
Cases run, bugs found and their status, deferred items, device and browser coverage, sign-off note.
Final test case sheet with resultsDeliverableQA
Bug log archived with evidence attachedDeliverableQA
Kept for the support window, so a question in month two has a record behind it.
Handover pack with every credential and where it livesDeliverablePM
Maintenance or support arrangement agreed, or explicitly declinedDeliverablePM
Explicitly declined is a real outcome, and better than an assumption on either side.
Recording and notes from the training sessionDeliverablePM
Written summary of what was built and what was decidedDeliverablePM
The reasons, not just the result. It is what makes the next change cheap.

All templates

Run this checklist with your client.

It is built into WorkTogethr - add it to a project, and your client sees what they owe you.

Start free

Try the demo Book a walkthrough