When does an online shop need custom development?

Custom development is useful when it solves a defined requirement. It is not automatically better than a platform feature, a suitable extension or a simpler buying process.

For a new shop, the practical question is: what must the customer or administrator do that the selected setup does not already support well enough for this project?

Write the requirement without naming a plugin

Start with the behaviour. For example: “A customer chooses a service area before seeing the delivery options available for their order.” That describes a buying rule.

“Install a delivery plugin” describes a possible implementation. It does not establish whether the plugin can apply the right rule, what happens when the address changes or how the business maintains the information.

Use a concrete example order to explain the requirement. Include the information the customer provides, the decision the shop makes and what the administrator needs to see afterwards.

Consider configuration first

Check whether the chosen platform and approved components can meet the requirement through their supported settings. A configuration-based solution may be sufficient when the behaviour is already part of the setup.

The decision still needs testing. A setting that sounds relevant is not proof that the whole customer journey works as intended. Verify the representative product, order and customer cases before treating the requirement as resolved.

This is a project-level evaluation, not a claim that every WooCommerce or Shopware installation provides the same features.

Evaluate an extension against the workflow

An extension should be assessed against the actual requirement, the platform environment and its dependencies. Confirm how it will be configured, which account or licence it needs and what responsibility remains after launch.

A feature list can hide an important mismatch. The extension may support a similar workflow but not the precise decision your business needs. Make that difference explicit rather than assuming the client will adapt after purchase.

Do not buy software simply because the wording resembles the brief. The owner should approve any cost after the fit and conditions are understood.

Use custom development for the defined gap

A custom component can be appropriate when the project needs a specific step, rule or connection not provided by the agreed setup. Examples might include a specialised product-selection flow, an internal approval before fulfilment or a documented integration with another business system.

These are illustrative scopes, not features every shop needs. The custom work should have a clear boundary: what it receives, what it changes and what it leaves to the existing platform.

Avoid rebuilding ordinary platform behaviour merely to make the project sound more sophisticated. More code also means more project-specific behaviour for someone to understand later.

Decide what happens outside the ideal path

What if the customer changes an option, payment does not complete or the external system rejects an order? Can the administrator see the problem? Can the operation be retried without creating duplicate records?

The relevant exceptions belong in the acceptance criteria. Otherwise, the first successful demonstration can conceal the work needed for a usable release.

Keep the commercial responsibilities visible

Themes, extensions, payment services, hosting and external systems have their own accounts and conditions. Development fees and third-party costs should be distinguishable in the proposal.

The handover should identify custom components and their dependencies, together with the configuration and release responsibilities included in the project. Future platform changes or new business rules may require a separately planned update.

A useful decision record

Before commissioning the feature, write down the business requirement, an example order, the options considered, the selected approach and why it fits. Add the acceptance test, dependencies and the person responsible for ongoing business configuration.

This record does not need to be long. Its purpose is to prevent “we need custom development” from becoming a substitute for describing what the shop needs to do.

Explore e-commerce development, WooCommerce or Shopware. To discuss a new build, send the commerce brief.