Executive summary
- Situation: the store build can start, but launch depends on information the client hasn’t finalised.
- Proposed response: separate build work from launch dependencies, and track each dependency with an owner.
- Build approach: product structure and checkout built on staging, with written test cases for every checkout path.
- What is not claimed: no sales figures, conversion rates, timeline or client identity.
Challenge
The agency is running marketing for a retail client launching an online store. The agency wants a production partner to build the store while it focuses on the launch campaign.
Several inputs aren’t ready:
- The product catalogue is still being finalised, including variations such as size and colour.
- Shipping zones and rates haven’t been agreed.
- The client’s payment gateway account is still being approved.
- Order and customer email content hasn’t been written.
The risk is that the store looks finished on staging but can’t launch, while the campaign date stays fixed.
Proposed approach
Discovery focused on dependencies
The first conversation identifies what the store needs to sell: product types, variations, stock handling, taxes, shipping, payments, coupons and notification emails. Each item is marked as decided, pending or unknown.
A dependency log with owners
Every pending item gets an owner on the agency or client side and a date by which it is needed to protect the launch. The agency sees which decisions are blocking which parts of the build.
Build what doesn’t depend on pending decisions
Theme templates, product page layouts, category structure and the cart can progress with representative product data while the rest is finalised.
Implementation considerations
- Product structure: categories, attributes and variations are agreed with sample products before a full import, so data problems surface early.
- Import format: a product spreadsheet template is shared with the client, with required fields clearly marked.
- Shipping and tax: configured only from written rules the client has approved, since these affect what customers pay.
- Payments: configured in the gateway’s test or sandbox mode on staging. Live credentials are entered only at launch, by the appropriate person.
- Emails: order confirmation and status emails reviewed with final wording and branding.
QA and handoff
Checkout testing is written as test cases before it is run, so the agency can see exactly what was checked:
- Simple and variable products added, changed and removed from the cart
- Each shipping zone and rate, including any free-shipping threshold
- Coupon behaviour, including invalid and expired codes
- Successful, declined and abandoned payments in test mode
- Order emails received by customer and store owner
- Checkout on mobile, and by keyboard
Launch readiness is a short list the agency signs off: dependencies resolved, test cases passed, live payment configured and a test order placed and refunded.
Expected benefits (not measured)
This scenario is illustrative, so no outcomes have been measured. The approach is intended to:
- Make launch risks visible early, while there is still time to act on them.
- Give the agency a clear view of which client decisions are holding up the store.
- Reduce the chance of checkout problems appearing after launch.
How success would be measured
- Dependencies resolved by their agreed dates.
- Checkout test cases passed before launch, and any defects found after it.
- Whether the store launched on the agreed date, and which dependency caused any delay.
- After launch, the agency and client could monitor completed versus abandoned checkouts using their own analytics.
Constraints and lessons to consider
- Payment gateway approval is outside the production team’s control and can decide the launch date.
- Product data quality affects the whole store. A small sample import catches most problems.
- Tax and shipping rules should come from the client in writing, not be inferred.
