01 / CONSTRAINT
The platform has become the constraint
The store is being shaped around theme limitations, app boundaries or platform policy rather than around the product, customer journey and operating model that actually matter.
BUILD / CUSTOM COMMERCE
Bespoke commerce builds when off-the-shelf can't do what your business needs — B2B, marketplace, subscription, restricted-vertical.
WHEN A CUSTOM BUILD IS JUSTIFIED
COMMERCIAL CONSTRAINT / NOT CUSTOM FOR ITS OWN SAKECustom ecommerce development is not a synonym for a more expensive website. It is the right path when the way a merchant sells, operates or stays compliant can no longer be expressed cleanly through a standard platform configuration. The useful question is not whether a storefront can be made to look bespoke. It is whether the current stack is forcing the business into workarounds that affect the customer experience, commercial control or ability to keep trading.
That can show up in a catalogue with real B2B rules, subscriptions, complex product relationships or marketplace behaviour. It can be an integration that has become too important to leave in a fragile app connection. It can be a payment or compliance path that needs to be part of the architecture. It can be a team that needs to own data, releases and operational decisions rather than rent access to an opaque boundary.
Not every constraint earns a rebuild. Sometimes the correct answer is a focused implementation, better ownership of the existing store through ecommerce management, or an honest decision to stay where you are. When a platform decision is still open, start with the ecommerce migration assessment rather than choosing a stack in advance.
01 / CONSTRAINT
The store is being shaped around theme limitations, app boundaries or platform policy rather than around the product, customer journey and operating model that actually matter.
02 / CONSTRAINT
B2B rules, complex product relationships, subscriptions, marketplace behaviour or trading logic need an intentional model, not another workaround layered onto a standard setup.
03 / CONSTRAINT
ERP, fulfilment, pricing, customer, content, payment or operational systems need dependable boundaries and ownership. A brittle connector is not a strategy.
04 / CONSTRAINT
The storefront needs a faster, more deliberate delivery model because the current implementation cannot support the journeys, content or commercial experience the merchant needs.
05 / CONSTRAINT
The merchant needs control over data, integrations, releases, payments or compliance conditions rather than accepting a platform boundary as a permanent operating rule.
QUALIFICATION BEFORE A PROPOSAL
CLEAR FIT / CLEAR NON-FITThe project floor is deliberate. First BUILD projects are typically £30k–£50k, subject to scope and complexity. That is not a generic website price list; it is the minimum level at which an assessment, architecture, implementation, data, integration and release responsibility can be handled without hiding essential work in an under-scoped promise.
If the need is a standard ecommerce storefront, a contained theme improvement, or a lower-budget site, custom architecture is likely to be the wrong purchase. We would rather make that clear in a fit call than sell a bespoke build that cannot carry its own delivery and operating requirements. The right answer may be to use the existing platform more effectively, delay the project, or take a more contained route.
FIT / WORTH ASSESSING
NOT A FIT / DO NOT OVERBUY
WHAT THE BUILD CAN COVER
DISCOVERY / STOREFRONT / COMMERCE CORE / RUNCustom does not mean every layer must be rebuilt. A good architecture keeps standard capabilities standard where they are genuinely adequate and invests custom effort where the merchant has a specific commercial advantage to protect. The work can span the storefront and the commerce core, but it starts by defining the interfaces, data and operating decisions that need to be owned.
For merchants whose need is an owned, extensible commerce core, Medusa development explains the platform and operating model in more detail. For merchants whose constraint is payment continuity, eligibility or regulation, the restricted-commerce approach explains why those requirements need to be treated as architecture. The broader build page remains deliberately platform-led by the problem, not by a preselected technology.
DISCOVERY
We separate the real constraint from the requested technology. The work maps business rules, customer journeys, data, integrations, operating ownership and release risk before a solution is selected.
STOREFRONT
A headless frontend is designed around the actual catalogue, content and conversion journeys when a conventional theme is not enough. It is not chosen as a styling exercise.
COMMERCE CORE
Commerce logic, data flows, integrations, search, admin workflows, payments and compliance are treated as one system with named responsibilities, not as a series of disconnected additions.
RUN
The build has to be usable by the people who run it. Handover, release controls, prioritisation and the next improvement decisions are considered during delivery, with ongoing ownership available where it is a fit.
HOW THE WORK BECOMES A BUILD
AUDIT / ARCHITECT / BUILD / OPTIMISE / RUN01 / PROCESS
Name the commercial constraint, inspect the current stack and identify the data, search, payment, compliance and operating risks that shape the decision.
02 / PROCESS
Turn the relevant constraints into a clear target model: what is custom, what stays standard, which integrations matter and who owns each operating boundary.
03 / PROCESS
Implement in testable slices, with the storefront, commerce core, data and integrations connected to the same acceptance standard.
04 / PROCESS
Use staged checks, route and data validation, release controls and a rollback path to make the transition accountable rather than optimistic.
05 / PROCESS
Leave the merchant with a stack and operating model that can be owned, improved and released deliberately after the build team steps back.
ENTRY OFFER / RISK BEFORE BUILD
The entry offer is a free 20–30 minute fit call, followed by a paid migration/platform risk assessment credited against a build. The assessment gives both sides a way to test the constraint, map the dependencies and decide whether the project should proceed before implementation is priced as certainty.
Book a platform fit call ↗WHAT A RESPONSIBLE QUOTE ANSWERS
COST / PROCESS / ACCOUNTABILITYCost transparency should not mean inventing a fixed number before the conditions are known. First BUILD projects are typically £30k–£50k, subject to scope and complexity. That published floor qualifies the conversation. The actual proposal then follows the risks that make the work custom: what has to be built, what data and integrations are involved, what must be protected during transition, and what operating capability is needed after the release.
We do not publish a generic delivery time or a catalogue of headline features because neither makes a custom project safer. A credible scope tells the merchant what is standard, what is bespoke, what is dependent on third parties, what needs validation, where the release risk sits and which decisions are still open. If those answers cannot be made clear, the build should not be sold yet.
QUESTIONS BEFORE YOU BUY CUSTOM
FAQ / CUSTOM ECOMMERCE DEVELOPMENTCustom ecommerce development is the design and implementation of commerce software around a merchant's actual operating model. It can include storefront behaviour, commerce logic, integrations, data flows, admin workflows, search and release controls when an off-the-shelf configuration cannot meet the requirement cleanly.
First BUILD projects are typically £30k–£50k, subject to scope and complexity. A credible cost follows a fit call and paid migration/platform risk assessment, which is credited against the build if the project proceeds.
The delivery path depends on the current platform, data condition, catalogue, integrations, payment and compliance requirements, content model and release risk. Hollow Point establishes those dependencies in the assessment before committing to a delivery plan rather than publishing a generic timeline.
It is appropriate when platform limits, accumulated workarounds, complex B2B or catalogue requirements, critical integrations, compliance requirements or a need to own the stack are changing the commercial outcome. A standard store that is well served by native features and a conventional theme should not take on custom architecture just for its own sake.
The stack follows the constraint. Hollow Point can assess a custom storefront and integrations around an owned commerce core such as Medusa, or recommend a contained approach where a full replatform is not justified. The architecture is not chosen before the operating, data, payment and ownership requirements are understood.
These are examples of the requirements that can justify custom work. The decision depends on the specific catalogue, workflow, integration, payment and compliance constraints, not the category label alone. Restricted merchants can also review the dedicated restricted-commerce approach before a fit call.
The process starts with a free 20–30 minute fit call. If there is a credible case, the next step is a paid migration/platform risk assessment that maps the constraint, dependencies and risk and is credited against a build if the project proceeds.