Key Takeaways
If you are close to signature, these are the points that deserve hard answers in writing.
- Ownership must be explicit. Confirm who owns code, repositories, hosting, design files, credentials, documentation and any third-party accounts, and when handover happens.
- Scope needs a real control process. Ask what is included, excluded and assumption-based, then check how change requests affect cost, timing and approvals.
- Integration accountability matters more than integration promises. Make sure one party owns fault isolation when payment, ERP, CMS or inventory connections fail.
- QA, UAT and launch risk should not drift back to you by default. Clarify testing coverage, sign-off points, defect handling and rollback support.
- Support terms need detail, not reassurance. Warranty cover, SLA response times and post-launch team ownership should all be written into the agreement.
Most eCommerce failures are not build failures at first. They are contract failures with better branding.
Before signing with an eCommerce development agency, ask five sets of questions.
- Who owns the source code and handover assets.
- What is explicitly in scope and how change requests are controlled.
- Who is doing the work and who stays accountable if outsourced delivery slips.
- Who owns QA, UAT, and launch-day liability.
- What the post-launch warranty covers and what SLA governs ongoing support. Those are the five areas where most contract-stage risk lives.
The proposal looks tidy, the demo behaves, everyone sounds confident – and then the real costs show up later: unclear ownership, soft scope, vague QA, blurred integration accountability, and support that vanishes the week after launch. One missing question in any of those areas can cost months.
If you are about to sign with an ecommerce website development company, this is the point where you need sharper questions, not warmer reassurance. If you are comparing eCommerce development in London, focus less on sales polish and more on what the contract says about control, delivery risk, and what happens when edge cases arrive. That is where expensive surprises usually start.
Ask who owns the build, the code, and the handover assets
This sounds basic until it goes wrong. You assume you are buying a build, while the agency assumes you are buying access to a build they still partly control.
Ask who owns the source code, the repository, the hosting or platform accounts, design files, documentation, admin credentials, and staging environment. Ask whether handover is included in the quoted work or treated as a separate paid phase – because that detail has a habit of appearing late.
Watch for dependency risk: if part of the solution relies on agency-owned tooling, paid licences in their name, or proprietary modules they will not fully transfer, you need to know before signature. A strong answer is specific: named assets, named access levels, and a clear handover point. A weak answer sounds like “we will make sure you have what you need.” Treat that as a warning sign.
- Ask for repository ownership and access from day one.
- Check whether staging access is available throughout the build, not only near launch.
- Confirm whether documentation, credentials, and third-party account ownership are included in handover.
- Ask whether any reusable components remain agency property.
Pin down scope, timeline, and how change requests are controlled
A proposal can look detailed and still be loose where it matters. That is usually where change-request revenue starts.
Ask what is explicitly included, what is excluded, and what assumptions the timeline depends on. Ask who is responsible if content arrives late, approvals drift, or a third-party dependency blocks progress. Do not assume “estimated timeline” means the same thing as a committed delivery plan.
Here is a common scenario: halfway through the build, someone realises the checkout UX needs an additional step, or the CMS integration has to handle more content types than originally scoped. If change control is solid, the agency can show you exactly how that gets logged, priced, approved, and re-planned. If the answer is vague, that is not flexibility – it is budget exposure.
What good change control looks like in practice
A clear change-control process has four components: a written scope baseline signed off before build starts, a formal change-request document for anything outside it, a named impact assessment covering cost and timeline, and a named approval on both sides before work proceeds.
The part most buyers miss is the assumptions log. Before build starts, a well-run agency will document every assumption the timeline depends on – content readiness, third-party API access, platform licence availability, approval turnaround. Ask to see that document. If it does not exist, you are not looking at a committed delivery plan; you are looking at an optimistic estimate with your budget backstopping it.
If you want to pressure-test what should already be nailed down, reviewing the scope checklist before signing any eCommerce quote is a useful next step. And if the proposal is still broad, a project discovery workshop in London before you commit is significantly cheaper than finding the missing detail in sprint three.
Not sure where the proposal still leaves delivery risk exposed
We can review the scope, ownership, QA, support terms and change control before you sign, and flag where the contract still leaves cost, access or accountability unclear.
Useful before contract sign-off or final supplier selection
Find out who is doing the work and who owns integration risk
Pretty demos hide ugly failure modes. Whether you are building on Shopify, WooCommerce, Magento, or a headless commerce architecture, integrations – payment gateways, inventory sync, CMS integration, ERP connections – are usually where the real complexity surfaces.
Ask who your project lead is, who owns technical decisions, who runs QA, and who is present at launch. Ask what work is outsourced or subcontracted, then ask the more important question: who remains accountable if that external work slips, breaks, or disappears. If the answer is “it depends,” keep pushing.
Then get specific on integrations. Do not accept a model where the agency blames the third party, the third party blames the platform, and you fund the confusion. Responsibility and accountability need to sit with the same named person.
In my experience reviewing proposals at this stage, buyers spot this gap too late – the agency sounds capable in the room, but the contract assigns no single owner to integration failure. If you are still unsure how to assess whether the agency is actually the right fit for a complex build, check the delivery model as hard as you check the proposal.
Check how QA, UAT, security, and launch liability are split
This is where contracts quietly dump risk back on the client. You need to know what the agency tests, what you test, what counts as done, and who signs off each stage.
Ask what QA covers before UAT starts, how defects are logged and prioritised, and what happens if serious issues appear late. Ask who owns UAT sign-off on your side and what the agency will still fix without turning every defect into a commercial debate.
The pattern that shows up most consistently in quote and proposal reviews is this: unclear QA ownership gets written off as a process detail, UAT sign-off is left undefined, and launch responsibility stays soft – long before any code is shipped. By the time those gaps surface in a live build, the leverage is gone.
Security and launch: ask how PCI and GDPR responsibilities are split, especially around payment flows, customer data, and hosting decisions. This is a delivery check, not a request for legal advice. If you need a neutral reference point, the PCI Security Standards Council sets out what should not be treated casually. You also need to ask about rollback planning, launch-day support, and liability for avoidable launch issues inside agreed scope.
Pre-signing due diligence checklist
| Area | What you should ask | Strong answer sounds like | Red flag |
|---|---|---|---|
| Commercial | What is in scope, out of scope, and assumption-based? | Clear deliverables, exclusions, and change process | Broad wording with no approval path |
| Technical | Who owns code, access, environments, and third-party accounts? | Named ownership and handover plan | Agency-controlled dependencies stay vague |
| Delivery | Who owns QA, UAT, launch support, and integration fault isolation? | Named roles and decision points | Shared responsibility with no clear owner |
| Support | What does warranty cover, and what SLA applies after launch? | Defined cover, response times, and support boundaries | Support starts only after a separate discussion |
Do not sign until support, warranty, and next-step terms are clear
Post-launch is where weak contracts become operational overhead. You do not want to discover that warranty means almost nothing and support means someone reads the ticket on Monday.
Ask how long the warranty lasts, what it covers, and what sits outside it. Ask for SLA detail: response times, severity levels, fix expectations, monitoring, and whether the same team that built the store will support it. If you are planning for growth, you also need to know what ongoing Website maintenance service in London looks like once the launch team moves on.
- Treat “we will support you” as a red flag if there is no written SLA.
- Watch for warranty language that excludes integrations, performance, or third-party issues by default.
- Be wary if handover is promised but not itemised.
- Slow down if support is owned by a different team that has not seen the build.
If the proposal still leaves ownership, scope, QA, or support open to interpretation, do not sign and hope the details sort themselves out. They usually turn into delay, rework, and awkward invoices. Get the scope and delivery model reviewed before you commit – especially if the build involves Shopify, WooCommerce, Magento, headless commerce, payment gateways, or inventory sync. That is exactly where a sober scoping review saves you from buying technical debt with nicer formatting.
Questions buyers ask before signing with an eCommerce development agency
These answers focus on the contract details that usually decide whether a build stays controlled or becomes expensive later.
1. What should I ask an eCommerce development agency before signing a contract?
Ask about ownership, scope, change control, integrations, QA, UAT, launch support, warranty and SLA terms. The key is not just hearing confident answers but getting clear written accountability. If any of those areas stay vague, the risk usually appears later as delays, rework, disputed invoices or operational dependency on the agency.
2. Who should own the code and project assets in an eCommerce build?
The client should usually own the codebase, repository access, environments, credentials, documentation and core project assets unless the contract clearly states otherwise. What matters most is that ownership and handover are named in writing. If the agency keeps control through licences, tooling or proprietary modules, you need to understand that dependency before signing.
3. Why is change control so important in an eCommerce development contract?
Change control matters because eCommerce scope nearly always shifts once real build detail appears. A usable process should show the original scope baseline, the requested change, the cost and timeline impact, and who approves it. Without that structure, normal project changes turn into budget exposure and avoidable arguments about what was included.
4. How do I check who is accountable for integrations?
Check who owns setup, testing and fault isolation for each integration. That includes payment gateways, ERP links, inventory sync and CMS connections. The important point is accountability, not just involvement. If the contract allows the agency, platform and third party to blame each other when data stops moving, you are the one left funding the confusion.
5. What should be defined around QA and UAT before launch?
QA and UAT should be split clearly before the build starts. You need to know what the agency tests, what your team tests, how defects are logged, what counts as done and who signs off each stage. If those boundaries are soft, serious issues discovered late can quickly become commercial disputes instead of straightforward fixes.
6. What does a strong post-launch support agreement look like?
A strong support agreement defines warranty length, what the warranty covers, SLA response times, severity levels, support boundaries and who actually handles tickets after launch. It should also clarify whether the build team stays involved. If support is promised only in general terms, expect slower resolution and more room for disagreement once the site is live.
Conclusion
The safest time to challenge an eCommerce development contract is before anyone starts building. Once scope is moving, integrations are live and launch pressure is rising, vague wording stops being a paperwork issue and starts becoming cost, delay and blame.
If an agency cannot state ownership, accountability, QA boundaries and support terms clearly in writing, treat that as delivery risk, not a communication style. A good contract should make the working relationship easier under pressure, not leave you arguing about what was meant after the fact.
Need a clearer delivery model before you commit to an agency
If the proposal still feels broad, a structured discovery workshop can define scope, integrations, responsibilities and delivery assumptions before they become contract-stage problems.
View discovery workshopStill comparing options first
