WordPress, Shopify or custom: choosing without regretting it
The wrong choice is rarely obvious at launch. It becomes obvious the first time you need the platform to do something it was not shaped for.
Nobody regrets this decision in the first month. Every option looks fine when the site is new, the content is small and nothing unusual has been asked of it yet. The regret arrives later, the first time the platform is asked to do something it was not shaped for, and by then the cost of moving is much higher than the cost of choosing correctly would have been.
Here is how I would actually make the call.
Start from what the site has to do, not what it has to look like
Any of these three can be made to look like anything. Design is not the deciding factor and treating it as one is how people end up on the wrong platform with a beautiful theme.
The deciding factors are: who edits the content, how the money moves, and whether the site has to know things about the person using it.
WordPress is right when content is the product
If the site is largely pages and articles, edited regularly by someone who is not a developer, WordPress is a sensible default and its reputation problem is mostly undeserved. It is not insecure by nature. It is insecure by neglect, because it is easy to install, easy to extend with plugins nobody audits, and easy to abandon.
Choose it when: several people publish content, you want them editing without a deployment, and the functionality is broadly standard.
Be honest about the maintenance it implies. Core updates, plugin updates, a real backup, and someone who notices when an author account has not been used in eight months. That is a recurring commitment, not a launch task. If nobody is going to own it, you are choosing a liability.
Keep the plugin count low. Every plugin is code from a stranger running with full access to your database, and the number of plugins is a better predictor of future trouble than almost anything else about a WordPress site.
Shopify is right when you are selling and want the hard parts handled
Payments, tax, fraud checks, PCI scope, inventory and the checkout itself are genuinely difficult, tedious and high-consequence to build. Shopify does them, keeps doing them, and takes the compliance burden off you entirely. For most people selling physical products that trade is obviously correct.
Choose it when: you are selling, the products fit a reasonably conventional model, and you would rather spend your attention on the storefront and the marketing than on the payment stack.
Where it strains: deeply unusual pricing logic, complex B2B rules, or a business where the store is a small part of a larger application. The checkout in particular is the part you have least control over, which is a feature until the day it is the problem.
A custom build is right when the logic is the product
If the thing you are building has users, roles, permissions and workflows, then it is an application, and dressing it up as a content site with plugins is a decision you will pay for repeatedly.
Choose it when: the application does something specific to your business that no plugin models, or you have multiple customer organisations whose data must stay separated, or you need real control over data and integrations.
The honest cost: it is more expensive to build, it does not maintain itself, and it needs somewhere to run and someone to run it. What you get is that the platform never becomes the reason you cannot do something.
The multi-tenant question decides it on its own
If two of your customers will ever log into the same system and must not see each other's data, build the application. Do not do this with a content management system and access-control plugins.
I say that with more confidence than anything else here. Tenant isolation is a property you have to design in and test deliberately, and bolting it onto a system that was built to serve public pages produces exactly the class of finding that ends up on a report: change an identifier in a request, receive somebody else's record.
A quick way to decide
- Content edited by non-developers, standard functionality: WordPress
- Selling physical products, conventional checkout: Shopify
- Selling with genuinely unusual pricing or B2B logic: custom, or Shopify plus a custom app
- Users, roles and permissions: custom
- More than one customer organisation sharing the system: custom, without hesitation
Whatever you pick, decide these at the start
Three things are cheap to arrange on day one and expensive to retrofit.
Who can log in. Every platform accumulates accounts: the developer who built it, the agency before them, the contractor who did one job. Decide now that account access is reviewed on a schedule, because the account nobody remembers is the one that gets used.
Where the backups go and whether they restore. Not whether they run. Whether a restore has been performed and timed.
How the site is deployed. Editing files on the server through a control panel works until two people do it, and then nobody knows what is running.
We build on all three, and I would rather talk you out of the wrong one at the start than migrate you off it later. Website and store delivery has published starting prices, and a scope request comes back with a written recommendation.