Suppose your new online store looks ready. The product pages are tidy, the buy button works, and a test payment goes through. You start sending customers to it.
Then two shoppers buy the last item at almost the same time. Both pay successfully. Another customer has been charged, but their order still says unpaid. The person who built the store asks an AI assistant for a fix and applies code they cannot fully explain.
This is an illustrative situation, not a client case study. A finished interface is easy to recognise. The quality behind it becomes clearer when the store handles money, customer records, and events that do not happen in the expected order.
When choosing an online store development service, ask who understands the system, checks the work, and takes responsibility when something goes wrong. AI can help an experienced engineer build a store. Trusting its output without that expertise leaves the business owner carrying risks a polished demonstration may never reveal.
Do you need your own online store or a marketplace?
People sometimes ask for marketplace development when they mean a website that sells their own products. The distinction matters because it changes both the scope and the cost.
A store for one business usually needs a catalogue, checkout, payments, shipping, and order management. A multi-vendor marketplace connects several sellers with buyers. It may also need seller onboarding, commissions, settlement arrangements, and dispute handling.
If your goal is an independent online shop under your business domain, begin with the sales process you actually need. Building a marketplace before you need one can add avoidable complexity. If multiple sellers really are part of the plan, the architecture and commercial arrangements need to reflect that from the beginning.
You can also keep using existing sales channels while building your own store. I discuss that decision in my article on leaving a marketplace.
A flagship AI model still needs its work checked
A capable model can help explore solutions, write code, and investigate errors. But its position in a model range tells you very little about whether your particular checkout is correct. That requires examining the implementation against your requirements, the software versions involved, and the environment where it will run.
GitHub's own guidance explains that Copilot suggestions can be inaccurate, miss context, or introduce security risks. Developers need to review and test the output. Its responsible-use documentation illustrates a real limitation of coding assistants; it does not establish an error rate for every AI model.
For a store owner, the practical concerns include:
- A convincing explanation built on a wrong assumption. An integration might use an API operation or behaviour that does not match the version in use.
- A local fix with wider consequences. Changing discount logic can affect shipping calculations or refunds elsewhere in the system.
- Tests that repeat the same mistake. If both the implementation and its tests assume customers never compete for the last item, passing tests will not settle that question.
- Business decisions made by guesswork. When should stock be reserved? What happens after a payment expires? Those rules need agreement with the owner.
An engineer's job includes challenging the proposed solution, checking documentation, and testing how it fails. Asking another model to review the answer can help, but agreement between models still needs to be checked against evidence.
Customer data needs protection beyond the login screen
Names, phone numbers, delivery addresses, order histories, and administrator credentials deserve careful handling. A mistake in access controls could expose one customer's order to another, or allow a staff account to perform actions reserved for the owner.
The OWASP Top 10:2025 includes failures involving access controls, security configuration, authentication, and the software supply chain. These categories help identify areas to investigate. They are not a diagnosis of any particular store.
You can ask useful questions without reading the code. Can each person access only the records they are entitled to see? Where are payment-service credentials stored? Are backups protected too? HTTPS helps protect data in transit; it cannot correct an application that grants the wrong person access.
The development process deserves the same care. Real customer records, passwords, and secret keys should not be pasted casually into AI conversations. Use appropriate sample data, restrict development-tool access, and check how the chosen provider handles information.
Additional risks arise when an AI agent can access a server, or a store's chatbot can take actions. Malicious instructions in material the model reads can influence its behaviour: OWASP calls this prompt injection. Software-enforced permissions need to limit what it can do. This risk depends on the AI integration actually in use; it is not automatically present in every store built with AI assistance.
Malware can become a customer-service problem
A compromise can start with a vulnerable component, a stolen account, an unsafe configuration, or a malicious upload. Knowing that a site is custom-built, or that AI helped write it, is not enough to judge its security.
Recovery may require finding the entry point, removing malicious files, closing the vulnerability, replacing credentials, checking data integrity, and testing the store again. Restoring a backup without addressing the cause can leave the door open. The cost depends on what happened and how far the damage extends; a single universal repair price would be misleading.
The disruption can reach beyond the technical work. An unavailable store interrupts purchases and after-sales support. A compromised website used to display deceptive content may trigger browser warnings, as explained in Google's security documentation. Customers who see suspicious behaviour may understandably hesitate to buy.
Ask who will respond to an incident and what their support covers. A claim that the site is secure should lead to a concrete discussion about responsibilities after launch.
Small bugs can affect payments, stock, and margin
Real customers do not follow a demonstration script. Someone taps the payment button twice. A connection drops after payment. A shipping service responds late. Two people order the last item simultaneously.
Payment notifications also require deliberate handling. For example, Stripe's webhook documentation explains that events may arrive more than once and are not guaranteed to arrive in the order they were generated. An integration needs to verify notifications and avoid repeating their effects. The documentation for your actual payment provider must guide its implementation.
For the business, that means one payment must not trigger fulfilment twice. An order's paid status needs proper verification, rather than trust in a success page shown in the customer's browser. Prices, discounts, shipping charges, and stock must be checked on the server, where transaction rules are enforced.
You do not need to inspect every line of code to ask for a meaningful demonstration. Have the developer show a few relevant failure scenarios and explain what the store should do. That gives you more useful information than a general assurance that everything has been tested.
A low build price can hide expensive operating choices
Costs can rise when the plan leaves important questions unanswered: too many paid services, oversized servers compensating for inefficient code, changing integrations, or a foundation that needs reworking every time a feature is added.
Poor maintainability also costs time. A future engineer may need to investigate undocumented behaviour before making even a modest change. If one supplier holds all the access, technical uncertainty becomes a dependency problem as well.
Using AI to write code does not automatically create an ongoing AI token bill. That cost becomes relevant when the running store uses a paid model service, such as a chatbot. Keep domain, hosting, licences, payment-processing fees, support, and optional features separate in the proposal so you can compare them properly.
Look at everyday usability too. Can customers complete an order on a phone, correct an address easily, and understand what happens after a cancellation or refund request? A technically functioning store can still make buying unnecessarily difficult.
Is WordPress or WooCommerce a safer choice?
WordPress has a substantial ecosystem, many available developers, and a wide range of existing features. Those are genuine advantages when they fit the project. Widely deployed components can also attract attackers looking for a weakness they can exploit across many sites.
One concrete example is the Modular Connector incident reported in January 2026. Its developer described a routing flaw in the plugin that could expose administrator access. The case shows how an additional component can expand a site's risk. It does not mean every WordPress installation had that vulnerability.
A store running an affected, unpatched plugin is more exposed to that particular flaw than one where it has been addressed. Component quality, account controls, hosting, and maintenance all matter. The official WordPress hardening guide describes security as reducing risk through several layers of protection.
A custom application gives you more freedom to select its functions and avoid unnecessary components. It can still contain mistakes, depend on vulnerable libraries, or suffer from neglect. Its maintenance responsibilities do not disappear. The sensible choice depends on your requirements and the support you can sustain, rather than a blanket promise about either technology.
Owning the domain name is not enough if someone else controls the account
Your business name may appear on the website while the supplier retains effective control. The domain could sit in their registrar account, recovery messages could go to their email address, and the only backup could remain on their server.
Discuss management access, account recovery, billing, backups, and transfers before the project starts. Make sure you know how product and order data can be retrieved. I cover this further in the risks of a vendor-locked website.
One distinction deserves particular attention: full domain and hosting access is different from receiving the application's complete source code. You can control the infrastructure accounts while still needing the original developer to change application features under a ready-to-use agreement. That boundary should be explained before you choose a package.
What I offer when we build your store together
My website and online store development service starts with the business: what you sell, how payment and delivery work, who manages orders, and which parts need room to grow.
My online store offering includes:
- Full domain access and a choice of full-access or managed hosting, so you can choose the level of direct server control and management support that suits you.
- Delivery through to a store that is ready to access, including the initial migration agreed as part of the project. Initial migration and setup are included in that scope, rather than appearing later as unexpected extras. The proposal sets out the work involved.
- Free bug fixes for 30 days. Correcting faults in agreed functionality is distinguished from requests for new features, so both sides understand the commitment.
- A malware-removal warranty of 1–6 months, or as agreed in your proposal, with the applicable duration and coverage made clear from the outset. This is a commitment to provide removal assistance within the warranty, not a claim that infection is impossible.
- Renewal arrangements that fit your hosting choice. You can renew your domain yourself or ask for help. With full-access hosting, you can also renew the server directly with the provider without a management charge from me. Managed hosting follows the server-management and renewal terms agreed in your proposal.
- Initial optimisation for SEO, speed, ease of use, and basic security during development. Actual search visibility and performance also depend on content, devices, networks, connected services, and ongoing maintenance.
The SEO foundation should make pages accessible to search engines, present clear information, and use structured data that matches the visible content. That also helps machines understand the page. No schema, sitemap, or AI-facing file can guarantee first-place rankings or recommendations from every AI assistant.
Full-access or managed hosting: choose how you want to run it
Full-access hosting suits owners who want direct control of their server. You have full access to your own server and can manage it yourself or appoint an engineer of your choice. This gives you flexibility over the provider, capacity, and renewals, with the corresponding responsibility for arranging its management.
Managed hosting suits owners who would rather focus on the business and have me manage the server. Your website runs on infrastructure I manage: either a separate server or one shared with other websites using isolated shared hosting, depending on the requirements and proposal. This option does not include direct server access. That access boundary is part of the managed service; you still retain access to your domain.
Managed hosting also leaves a path to full server access if you later decide to end our management arrangement. The website would move to a new server: you would need to rent one with sufficient capacity and cover all costs required for the migration, setup, and supporting services. The requirements and costs are agreed before the move, so you can plan the budget clearly. This is separate from the initial migration already included within the store-development proposal.
Both options can work well. Full access gives you direct control; managed hosting gives you the convenience of having the server looked after. This choice is also separate from the source-code delivery option: moving to a server with full access does not automatically include the application's full source code.
Ready-to-use store or a package with the full source code?
For an owner who wants to start selling while keeping the initial investment manageable, the ready-to-use option is usually the more economical starting point. You buy the finished store for the agreed purpose. Its foundation still needs careful implementation and review; a lower price is not a reason to neglect transactions or basic security.
The full-source-code option is more appropriate when you expect another engineering team to continue development independently. It costs substantially more. The extra value is that development freedom, rather than an automatic increase in security.
| What you are comparing | Ready-to-use — lower initial cost | Full source code included |
|---|---|---|
| What you receive | A finished store for use within the agreed project scope | The finished store plus source code within the agreed handover scope |
| Initial investment | Significantly lower, leaving more budget for operations and sales | Significantly higher; appropriate when access to the code serves a clear need |
| Foundation and basic security | Carefully built and still requires maintenance | Carefully built and still requires maintenance |
| Domain access | Full access | Full access |
| Hosting | Choose full access or managed; managed excludes direct server access | Choose full access or managed; managed excludes direct server access |
| Application code changes | May require my help because the complete source code is not included | Another engineer can continue development after understanding the system and its licensing terms |
| Domain and hosting renewals | Renew the domain yourself or with help; server renewals follow the hosting option | Renew the domain yourself or with help; server renewals follow the hosting option |
| Future migration and development | Application changes may require my help; leaving managed hosting requires a new server and related costs | Another engineer can develop the code; leaving managed hosting still requires a new server and related costs |
| Best suited to | Businesses that want a functioning store with a lighter initial investment | Businesses with a technical team or a clear independent development plan |
Warranty and support follow the written proposal for either option. For a source-code package, clarify what is handed over, how the application is run, and the rights attached to third-party components. Having the code increases control, but does not remove maintenance or the cost of a future engineer's work.
Choose evidence you can understand
When comparing ecommerce website development services, ask for evidence connected to your actual business: a transaction demonstration, an explanation of data access, a breakdown of recurring costs, and a clear handover. Someone who understands the work should be able to explain their decisions in language you can follow, including what has not yet been tested.
You do not need to arrive with a detailed technical specification. Tell me what you sell, how you take orders today, what consumes too much time, and what you hope to change over the next few months.
Let's discuss the online store you need. We can assess whether a more affordable ready-to-use store, a source-code handover for independent development, or improvements to your existing store make the most sense. You should understand what you are buying, who controls the access, and what help remains available once customers start using it.
