What should a custom e-shop cost when it fits your sales process?

A starting range of 20 to 50 hours at €40 per hour including VAT covers a proportionate catalogue, cart, checkout, payment and launch setup. Unique templates, product imports, complex variants, languages, B2B pricing, subscriptions and integrations can extend it. I record assumptions in the estimate so it is clear what the interval represents. When a new requirement appears, you see its hour impact before implementation. The budget is therefore neither an arbitrary package price nor an unlimited account. It is a model that can be updated when facts change.

• Typical range of 20 to 50 hours
• €40 hourly rate including VAT
• Written scope assumptions

WooCommerce is a sensible base for many retailers because it handles products, orders and managed content. The value comes from configuring and extending it around the actual selling model. I select only justified plugins and put distinctive business rules in a separate custom plugin, preventing a theme redesign from disabling fulfilment or pricing logic. On an existing store I inspect conflicts, performance, database behaviour and update status first. A slow shop does not automatically require a different platform. Removing the cause and clarifying plugin responsibilities is often the safer investment.

• A controlled plugin footprint
• Business logic outside the theme
• Evidence-based repair of existing shops

Checkout should ask only for information needed to complete the sale. Shipping options must respond predictably to country, weight, value or product rules, and payment feedback must be unambiguous. I test the normal journey as well as return from the payment provider, repeated submission and temporary service failure. Sensitive steps retain suitable diagnostic context for support. A well-designed checkout does more than improve visual polish. It reduces abandoned purchases and prevents the operations team from repeatedly reconstructing what happened from incomplete emails.

• Relevant checkout fields
• Predictable delivery rules
• Safe payment result handling

Orders often continue into a warehouse, accounting product, courier service or marketing platform. Each connection needs a source of truth, a field mapping and a defined response to failure. Retrying an operation must not generate a second invoice or parcel. An administrator should be able to see what transferred and what needs attention. I account for API limits, queued work and secure credential storage. Automation then removes repetitive effort instead of hiding errors in a system nobody watches. The same principles apply to product imports and outgoing comparison feeds.

• Stock and accounting systems
• Couriers and product feeds
• Controlled retries and visible failures

Before release I verify mobile layouts, product availability, tax settings, delivery, payments, messages and the analytical events the project needs. We agree on test orders and who confirms their downstream results. After launch, real customer questions and operational friction become evidence for the next change. Iteration can focus on behaviour rather than copying a list of retail trends. Ongoing care may cover updates, backups, monitoring and an agreed monthly development block. This protects the working sales path while still allowing the store to evolve.

• End-to-end test orders
• Measurement of important actions
• Maintenance and improvement after launch