There is one risk that rarely gets discussed when a business decides to build its own online store.
It is not about the design. It is not about the hosting. It is not about the plugins. It is about dependency.
How the story usually starts
You may have seen a business website that still appears to be running, then suddenly breaks.
Once someone takes a closer look, the problem is not just a small bug.
The domain is about to expire. Nobody is sure who owns the hosting account. Plugin licenses are tied to the agency’s account. The code is undocumented. Server access was never handed over. Backups do not exist. The domain’s email service is also broken. The payment gateway is difficult to inspect. The website cannot be fixed because every access lives on the vendor’s side.
Then the bigger problem appears
The person who originally built the website cannot be reached.
The freelancer is gone. The agency does not respond. The phone number is no longer active. The accounts can no longer be opened. The client has no idea where to start.
At that point, the website is no longer an asset. The website has turned into a liability.
When the data gets locked too
It can get worse: customer data ends up locked inside a system the owner does not understand.
The products still exist. The brand still has momentum. Buyers are still looking. But the website cannot be used.
And the business looks unprofessional, simply because the technical foundation was never built properly from the start.
This is why it matters who you choose
Not just someone who can install a theme. Not just someone who can use a page builder. Not just someone who can ship a pretty layout. Not just someone who can ask an AI to build a website.
A healthy access structure for an online store
A healthy online store must have a clear access structure.
The domain registered under the business owner. Transparent hosting. Critical accounts held by the owner. License terms explained from the beginning. Backups in place. Documentation written. Code that can be maintained. A system that can be moved when needed.
And when something goes wrong, there is a sensible path to repair it.
A business website is not a design project - it is an operational asset
A business website is not just a design project.
A business website is an operational asset.
If, from day one, everything depends on a single person whose continuity is unclear, the risk is simply too high.
Today the website looks good. Tomorrow it can break. The day after, it can go dark.
And the moment every access lives on a side that cannot be reached, the owner finally realises what was actually purchased back then was not a digital asset.
It was a dependency.
A note: these are often just delivery model choices
Before going any further, one thing should be put on the table fairly.
Not every vendor who keeps hold of access does it to trap a business. Often it is simply a difference in delivery model, and the default behaviour from one vendor to the next is not the same.
For example:
- Some deliver only the finished website - the site runs, but the source code, theme, and plugins stay with the vendor.
- Some deliver the finished website together with the raw source code - usually much more expensive, because the buyer receives the full right to maintain or move it later.
- Some hand the website over but it still depends on an API or service running on the vendor’s own server - when that API is unreachable, the website stops with it.
- Some build the website with no dependency on any vendor-controlled service at all - fully self-contained and able to live on any hosting provider.
- Some keep premium plugin or theme licenses under the vendor’s account, so updates and support continue to flow through them.
- Some keep hosting, domain, email, and cloud accounts on the vendor’s side as part of a monthly retainer.
- Some build on proprietary page builders or platforms (Webflow, Wix, certain paid builders) where moving the site out means rebuilding it.
- Some include documentation, repository access, and operational runbooks; others do not.
- Some are structured as a SaaS subscription - you are renting features, not owning code.
- And there are still other variations that do not always get explained upfront - commercial rights, modification rights, customer data ownership, and the question of who actually pays for license renewal next year.
None of these models is automatically wrong. What is dangerous is not the model itself - it is when the model is never explained openly before the engagement begins.
So before agreeing to anything, ask directly:
- What exactly will I receive at handover - only the finished website, or also the source code, assets, and documentation?
- The domain, hosting, cloud accounts, email account, and payment gateway accounts - whose name is each one registered under?
- Premium plugin and theme licenses - under whose account, and what happens when the engagement ends?
- Does this website depend on any server, API, or external service controlled by the vendor? What happens if that service stops running?
- Can I move this website to a different vendor later? What does that look like, technically and financially?
- Will I receive technical documentation, repository access, and recovery instructions for an incident?
- Who is responsible for the customer data - and in what format can I export it out?
Defaults vary from one vendor to another. You have every right to know those defaults from the beginning - and to negotiate them before signing.
Because once the money has moved, your bargaining position is no longer the same.
Closing
So do not just look for someone who can build a website.
Look for someone who understands how to keep that website alive, safe, maintainable, and unable to hold your business hostage later.