Building an E-commerce Site: Hosted Platform, Open-Source Package, or Custom Build
“We want to build an e-commerce site” hides three completely different routes underneath it: renting a ready-made hosted platform, installing an open-source package yourself, or building something custom from scratch.
None of the three is better than the others. There is only which one fits. The penalty for choosing wrongly is asymmetric, too — go too light and you hit a wall as you grow; go too heavy and you burn the budget before the market has told you anything.
What actually separates the three routes
Hosted platforms (SaaS) mean renting a shop somebody else has built. You are paying for the right to use it; the platform handles hosting, security, system updates, and feature development, while you handle listing products and running the business. Fastest to launch, lightest technical burden.
Open-source packages mean taking a publicly available e-commerce application and installing it on hosting you arrange. The software itself carries no license fee, but hosting, installation and configuration, version upgrades, and security patching all fall to you or your vendor. Flexibility sits between the other two, which suits businesses with established processes that do not want to develop from nothing.
Custom development means building around your business process. Everything from the data structure to the checkout logic can follow your rules; the trade-off is the highest investment, the longest timeline, and a need for long-term maintenance arrangements.
What deserves comparison is not which option has more features, but the four dimensions below.
Four dimensions that decide it
| Dimension | Hosted platform | Open-source package | Custom build |
|---|---|---|---|
| Cost structure | Mainly recurring, may include transaction fees | One-time build plus ongoing operations | Highest one-time build plus ongoing operations |
| Flexibility | Limited to what the platform exposes | Code can be changed, within the package’s architecture | Effectively unconstrained |
| Lock-in risk | High; layout and functionality rebuilt on exit | Medium; depends on the package ecosystem | Low; the code is yours |
| Data ownership | Exportable, with scope set by the platform | Complete | Complete |
| Time to launch | Fastest | Moderate | Slowest |
| Technical burden | Lowest | Medium to high (updates and patching are yours) | High (needs a maintenance team or vendor) |
Cost structure is more revealing than the total. Platforms spread the cost into a recurring charge; a custom build is front-loaded and lighter afterwards, though never zero. Which works out better depends on how many years you plan to operate and how fast revenue grows. The full logic of how these costs break down is in how website costs are calculated.
Lock-in risk is the most underestimated line. Before deciding, ask yourself one question: if I leave in three years, what can I take? If the answer is only “product data and order history”, then accept that the layout, the processes, and every integration setting will have to be rebuilt.
What scale, and what signals, mean it is time to switch
The trigger for changing route is not revenue. It is whether the limitations have started causing real losses. When the following signals appear, a serious evaluation is worthwhile.
The promotion logic cannot be built. The bundles, segmented pricing, or membership tiers you want can only be approximated, so every campaign ends up being patched manually.
Somebody is moving data by hand every day. Orders copied into a fulfillment system, stock reconciled across two places, customer records scattered across different tools. This usually means what you need is system integration and API work, not necessarily a whole new website.
Growth is constrained by add-on fees and transaction charges. When the spending that comes with growth rises faster than the revenue that caused it, the structure needs re-examining.
You cannot reach your own data. You want behavioral analysis, or to feed customer records into your own membership system, but only the platform’s fixed reports are available.
Service and returns processes cannot reflect how you actually work. These gaps tend to be the most expensive, because they occur every single day.
The reverse also holds. If your current pain is insufficient traffic, weak product photography, or not enough people answering customers, changing systems will not solve it — it only spends resources in the wrong place.
What to watch when integrating payments and logistics
This is where e-commerce projects most often overrun, and the reason is not technical difficulty. It is that the other party’s process is not under your control.
Applications and approvals take time. Payment services generally require company documentation to be reviewed, and invoicing and logistics providers each have their own application process. That time belongs in the schedule; it cannot start after development finishes.
Test environments differ from production. Most services offer a test mode, but passing in test does not guarantee production behaves the same. Before launch, run one complete low-value verification under real conditions.
The exception cases are the real work. Payment succeeded but no notification arrived, duplicate payments, refunds, partial refunds, store pickups never collected, canceled shipping labels — the handling logic for these usually takes longer than the happy path, and they are exactly what acceptance testing should focus on.
Reconciliation is a long-term cost. The system has to let you line up settlements from the payment provider against invoices and order status. If that is not designed in from the start, somebody will be reconciling manually every month thereafter.
Specifications change. The integration specifications and fee structures of third-party services get revised, so treat each provider’s own latest documentation as authoritative, and agree in the contract who is responsible for maintenance when a revision lands — one of the items a website maintenance contract should spell out.
Speed and search performance: e-commerce feels both more acutely
An e-commerce site has far more pages than a corporate site, which magnifies every problem.
Product images are the single biggest speed variable. E-commerce pages are almost entirely images, and product photography that has not been compressed and sized properly will drag loading times down directly, more visibly on mobile.
Tracking scripts accumulate. Advertising, analytics, live chat, surveys, and recommendation engines each add their own script. None looks heavy alone; the total is noticeable. After launch it is worth reviewing periodically which ones are still in use.
URL structure for categories and filters. If every filter combination generates its own URL, you end up with large numbers of near-identical pages. Decide at the planning stage which ones search engines should index and which they should not.
Every checkout step is part of a funnel. Forced registration, too many fields, and shipping costs or totals that are not visible all push away people who had already decided to buy.
Out-of-stock and discontinued products. Deleting the URL when a product is withdrawn loses the search traffic and the existing links at the same time. The better approach is to keep the page and guide visitors to related products, or set up an appropriate redirect. If a full site redesign is coming, the steps are in the website redesign SEO checklist.
The admin side determines your operating cost more than the storefront
When evaluating an e-commerce system, most attention goes to how the storefront looks — but the part your team uses every day is the admin. The following are worth trying hands-on before you choose.
How many steps a dispatch takes. From seeing an order to printing a shipping note: how many clicks, how many page changes, and whether batch processing is possible. In peak season those steps get multiplied by the hundreds.
How efficiently products can be listed. Whether bulk import exists, how variants and options are managed, and whether a seasonal price change has to be made product by product.
Returns, exchanges, and partial refunds. The most commonly overlooked process and the one most likely to create accounting confusion. Confirm that the system can record a partial refund and tie it back to the original order and invoice.
Permission tiers. Customer service, warehouse, and marketing should not see the same things. An admin with no permission tiers becomes a risk as soon as the team grows.
Whether reports can be exported. Whether you can obtain the underlying detail rather than only the charts the system chooses to draw. This determines whether you can analyze the business your own way.
These details belong in the requirements discovery stage, item by item, which is why NETVANA’s software development process puts requirements discovery in the first phase — when the admin workflows are not properly understood, the system that results looks good and is painful to use.
A practical way to phase it
You do not have to decide the endgame in one go. Most growing brands follow this order.
Phase one: sell something. Start taking orders through whatever launches fastest, with the goal of proving that the products, the pricing, and the fulfillment process work. The objective at this stage is real data, not a perfect system. The reasoning is the same as building an MVP for a new product.
Phase two: fix the part that hurts. Identify from actual operations where the most staff time goes, and deal with that first. Often the answer is integration rather than rebuilding.
Phase three: invest in custom work where you know you will stay. By this point you know what your processes look like, which is what makes a specification writable.
The most important preparation for moving between phases is to keep hold of your own data from day one: export orders and member records regularly, store product assets in your own space, and open analytics tools under your own account. These habits cost nothing and determine how free you are to change route later.
NETVANA works in two-week sprints and delivers a usable version at the end of each cycle, precisely so that phased decisions can be adjusted against real usage rather than guessed at on a specification document.
Choosing an e-commerce system is fundamentally a decision about which things you want to control. The more you control, the more flexibility you have and the more responsibility you carry. While the shape of the business is still uncertain, leaving flexibility for the future and prioritizing speed now is usually the safer order.
If you are weighing whether to stay on your current platform or invest in your own build, talk to NETVANA about your e-commerce requirements. We start by understanding your current operations and where they are getting stuck, then discuss the technical options; software services are quoted after a consultation, and what each service includes and delivers is set out in the software services overview.
Further reading: for how the costs are composed, see how website costs are calculated. To connect orders, stock, and member records, see the guide to system integration and API development. And for the arrangements after launch, see what website maintenance actually covers. For comparing packaged, open source, headless, and custom CMS options, see How to Choose a CMS; and for choosing payment methods and handling reconciliation, see Payment Gateway Integration in Taiwan; and for the speed metrics that decide e-commerce conversion, see Website Speed Optimization. For the invoicing requirement no Taiwan store escapes, see Integrating the Taiwan E-Invoice System; and for pickup and delivery status callbacks that shape support load, see Logistics Integration in Taiwan; and for selling courses instead of goods, and what changes, see The Online Course Platform Development Guide. An accurate stock count is what keeps an online store from overselling; see Inventory Management System Development. A two-sided marketplace builds on the same foundations as an e-commerce site; see Marketplace Platform Development.
