Revision: rebuilt around a single-merchant store example, a budget structure and practical launch checks.
The cost of building an online store depends on the catalogue, operating rules and connections behind the storefront. Start with what a customer can buy and how an order reaches dispatch. Then compare platform configuration, extensions and custom development against that same scope.
This guide covers one business selling its own physical goods. A platform serving independent sellers needs additional seller, payment and operational workflows; see our marketplace website cost guide. Wholesale procurement and supplier coordination are covered separately in our B2B marketplace guide.
Define a first release that can be estimated
Consider a hypothetical homeware retailer with one warehouse, one selling currency and one language. It sells through this website only. The first release has 60 product pages: 40 single-SKU products and 20 products with six variants each. That is 40 + (20 × 6) = 160 sellable SKUs, not 60 stock records. These are invented scope inputs, not a client case study.
The store uses a configured theme, guest checkout, one payment provider and two domestic shipping zones with agreed flat rates. Staff maintain stock in the store and dispatch orders manually. Subscriptions, independent sellers, international delivery, an ERP connection and a mobile app are outside this release.
| Area | Included in this example | Acceptance evidence |
|---|---|---|
| Catalogue | 60 product pages, 160 SKUs, agreed categories, images and descriptions. | Counts reconcile to the approved source; variant choice shows the correct image, price and availability. |
| Shopping | Category browsing, search, cart and guest checkout. | A customer can locate a named item, choose a variant and complete the purchase on the agreed mobile and desktop browsers. |
| Payment | One approved provider with its supported payment methods. | Success, rejection and interrupted checkout produce the agreed order states without duplicate fulfillment. |
| Stock | The store holds sellable quantities; backorders are disabled. | Competing checkouts cannot allocate the last unit twice; failed or expired reservations release it according to the agreed rule. |
| Delivery | Two defined zones, flat rates and manual dispatch updates. | Representative addresses receive the correct option; unsupported addresses cannot complete an order for delivery. |
| After purchase | Order emails, staff order management and the agreed refund workflow. | Staff can trace payment, dispatch and refund status; stock changes follow the approved return decision. |
Assign an owner to product data, prices, payment onboarding, delivery rules and final acceptance. “The developer will sort it out” is not a decision about what a customer should see or what warehouse staff should do.
Choose between configuring, extending and building
Configure a hosted platform when its standard catalogue, checkout and order administration support the workflow. For this example, a Shopify evaluation should use real sample products and the intended payment and delivery settings. Confirm the required features in the selected subscription and apps before accepting a proposal. A successful theme demo does not establish operational fit.
Configure or extend WooCommerce when a WordPress store and its extensions suit the requirements. WooCommerce is an open-source platform for WordPress; the implementation still needs hosting, updates, compatible extensions, backups and someone responsible for recovery. Put those responsibilities into the budget, including any managed service that takes them on.
Build a custom application or integration when a valuable, required workflow remains unsuitable after testing existing options. Identify the specific gap: an unusual product configurator, stock allocation rule or connection to another system. Custom work adds design, testing and maintenance obligations. A distinctive brand or a small catalogue alone does not require replacing a commerce platform.
Test the hardest representative order first. If it requires several apps and manual corrections, compare that complete operating process with the alternatives. Count the ongoing work as well as the initial implementation.
For a Shopify project, our implementation guide separates theme, app and integration work, while the Shopify developer hiring guide helps assess the relevant skills. If the store uses BigCommerce, the API integration guide shows how to define data ownership and synchronization checks.
Prepare catalogue content and rehearse migration
For every SKU, prepare a stable identifier, variant values, selling price, starting quantity and the shipping data your method needs. For each product, approve the title, description, category, images and relevant specifications. Record who owns image rights and who signs off content accuracy.
A catalogue import is not a complete store migration. Customer accounts, historical orders, discount rules and URL redirects need separate decisions. Decide which records must move, which remain in an archive and how staff will retrieve that archive. Avoid promising that existing customer passwords will transfer unchanged.
Import a representative sample before the full catalogue: a simple item, a product with variants, an unavailable item and one with several images. Shopify's product CSV documentation explains dependencies between variant fields and distinguishes product information from inventory data. Use the target platform's current format; a source spreadsheet is not automatically import-ready.
Reconcile product and SKU counts, prices, quantities and image associations after a rehearsal. Keep a record of rejected rows and the unchanged source export. Before launch, agree when source edits stop and how final changes are copied. Map useful old product URLs to their replacements, then test the redirects and destination pages.
Settle stock, payment, shipping and tax configuration
In this example the store owns sellable stock. Staff record receipts and adjustments there. Define when checkout reserves a unit, when payment deducts it and when an abandoned or canceled order releases it. A refund and a physical return are different events; damaged goods should not automatically become available again.
If another warehouse or point-of-sale system is introduced later, name the source of stock quantities, expected update delay and response to a failed synchronization. That is additional scope, not just another admin login.
For payments, establish supported countries and currency, merchant-account approval, capture timing and the refund process. Define what staff do when the browser reports a timeout but the provider has accepted payment. Payment status must be reconciled before repeating a charge or dispatching an order.
For shipping, write down zone boundaries, exclusions, rates and the dispatch promise displayed to customers. Test border cases. In WooCommerce's shipping-zone model, the first matching zone determines the available methods, so the order of overlapping zones matters.
Have the merchant approve the applicable tax inputs and expected example totals. The implementation brief should specify price entry and display, product classifications, shipping treatment, address basis and rounding. WooCommerce's tax settings expose these as separate configuration choices. Test the approved examples in the product page, cart, checkout and order record.
Build a budget from deliverables and operating costs
Ask each supplier to price the same scope and identify exclusions. A proposal for theme setup is not directly comparable with one that includes photography, data cleanup, migration and staff training.
| Budget group | What belongs here | What to clarify |
|---|---|---|
| Initial delivery | Discovery, configuration, design changes, integrations, verification and handover. | Deliverables, estimated effort, agreed rates or fixed fee, and change approval. |
| Content and migration | Product copy, photography, data cleanup, imports and redirects. | Who supplies usable inputs and how much corrective work is included. |
| Recurring operations | Platform or hosting, apps, domain renewal, maintenance and support. | Billing period, renewal conditions, included work and named account owner. |
| Variable costs | Payment processing, applicable platform transaction fees, usage charges, packaging and delivery. | The actual provider terms and the order volumes used in the model. |
| Business launch | Inventory purchases, merchandising, customer support and customer acquisition. | Funding and responsibility separate from the website implementation. |
For time-based work, calculate each task's estimated hours multiplied by its agreed rate, then add applicable fixed charges. Keep allowances for unresolved work visible and state what they cover. For a fixed fee, attach the same acceptance scope and change rules.
Model the first year separately: launch spending plus recurring charges for the relevant months, expected variable costs and a maintenance allowance. Avoid counting bundled hosting twice. Increasing sales can increase processing, shipping and support costs even when the software subscription stays the same. Revenue is not profit.
Distinguish development effort from elapsed time
An effort estimate counts work; a launch date also depends on availability, review cycles and external approvals. Payment onboarding, missing photographs or an unresolved delivery contract can block a completed storefront. Adding developers does not remove those dependencies.
Plan milestones around evidence: approved scope and sample catalogue; configured shopping flow; successful migration rehearsal; tested order-to-refund workflow; merchant acceptance and cutover. Give each milestone its inputs, owner and exit conditions. Update the forecast when an input changes instead of preserving a date whose assumptions no longer hold.
Launch only when the operating workflow is ready
Run checkout tests with the chosen provider's supported test mode. Shopify documents test-order options, and WooCommerce explains testing orders, including effects such as order emails and analytics. A simulated payment does not establish that live merchant activation and payout settings are ready.
Verify mobile variant selection, totals, failure messages, order emails, stock changes, refunds and staff permissions. Agree a representative catalogue and traffic profile for performance checks. Test administrative exports and the recovery procedure appropriate to the platform. Remove test data and confirm production payment configuration before accepting customers.
Name the person who handles failed payments, stock mismatches, returns and integration errors after launch. Document account ownership, renewal dates, support contacts and update responsibilities. Track completed orders, payment failures and customer support issues so the first improvements address observed problems.
Use our software requirements template to record the brief and acceptance conditions. Our e-commerce development page provides context for discussing a store's scope, platform choice and delivery needs.