When choosing between a website constructor, WordPress, Shopify or custom development, the main factor should be the business case. And it needs to be evaluated long term as well.
Start from the business case
If a business wants a representation page with minimal functions, I would normally go for either an online constructor or a clean HTML5 website with custom design. There is not much point in building complicated infrastructure if the website mostly needs to explain what the company does, show its services and allow people to contact it.
If the website is meant to communicate with users in different ways and different languages, but without actual shopping, I would start looking at a WordPress type of system. It gives relatively easy infrastructure for things like accounts, translations, content management and integrations without developing all of this from zero. E-commerce is a slightly different case.
For a new ecommerce project, Shopify can make a lot of sense
One of the clearest cases where I would recommend Shopify or a similar product is a new ecommerce project. Before going fully into custom development, it makes sense to test the online strategy and see if the shop actually has growth potential. There are still a lot of things that need to be proven:
If standard Shopify functionality covers the business case at the starting point, I don’t see a reason to make the project more complicated just because custom development is possible. Switching to custom development becomes useful once the business reaches certain revenue points and the proof of concept is there. If the project starts earning money, it’s all right to spend on migration — scaling your own investments based on actual income is a synonym of growth.
The tool shouldn’t define the strategy
One of the main mistakes entrepreneurs make is choosing the strategy based on what features the tools provide. A business owner can decide to go with Shopify, WordPress, Wix or another constructor because it’s cheaper, but the tool might not necessarily support the actual business model.
Apply both answers to the growth strategy. If the difference is small, there is probably no reason to go custom right away. If the difference includes something important to how the company actually makes money, operates or competes, then it’s worth looking deeper.
WordPress and WooCommerce can be a very good starting point
WordPress and WooCommerce are good systems for getting started, and they can also be perfectly fine for maintaining a relatively minimalistic business model. The question is what the long-term plan looks like.
If the goals include various database integrations, custom configurators, a separate but integrated B2B platform, special user interfaces or complicated international operations, I would already keep in mind that the architecture of those custom parts may need to go separate at one point.
That doesn’t necessarily mean replacing WordPress or WooCommerce immediately. You can keep the basic system where it does its job and gradually separate the parts where the business requires something more specific.
Before assuming custom software is required, investigate what the platform can actually do. If somebody asks for a custom feature on Shopify, my first answer wouldn’t automatically be that we need custom development. I would check the documentation, then research other people’s experience implementing it and understand the practical limitations. That gives the business owner an overview so they can decide whether those limitations are actually red flags for their business. Technology changes too quickly to base these decisions only on assumptions. Sometimes the standard solution already does what is needed — in that case, just use it.
Too many plugins — is that a problem?
One of the things worth checking with an existing WordPress system is how many separate plugins and integrations are required to make the business process work. If the answer is something like 25, the number might just be too high. A lot of plugins have a relatively short lifespan and can stop updating at some point.
There can also be cases where five or ten separate integrations could be combined into one system without continuously sharing client data between different third parties. At that point you’re not necessarily saving money anymore just because every individual plugin was cheap. From an investment standpoint, maintaining such a structure may actually cost more than scaling into custom software.
A “simple feature” request can actually become a business system
One real request: “We need to change the language and prices depending on the user’s home location.” At first it sounds like a feature. But then you start asking questions.
No-code doesn’t mean there is no code
I’m skeptical about the idea that no-code platforms can simply build anything. To me, “no-code” is mostly a marketing term for selling standard instruments in a more accessible way. Those instruments can be very useful. For some people they will be enough. For many others they probably won’t.
Each one of those instruments still needs to be coded by somebody, and nobody can possibly code every single option for every single business case. The question is whether the components it provides match this particular business.
Developers can recommend custom development when it isn’t actually justified. Without a business analytics or product ownership angle, the focus lands on by-the-book technical solutions without taking the business case, budgets, numbers and macro picture into consideration.
A technically cleaner system is not automatically a better business decision. If it’s possible to do relatively simple work without sacrificing future scaling possibilities, it might be better for the business to take those low hanging fruits and start building up revenue from them.
Maintenance cost versus the money the system makes
In the macro picture, I would always look at how much the system costs to maintain versus how much money it makes or supports.
Workflow optimization belongs in the same calculation. If we can see that the business will save more money by going custom than the custom system costs itself, the choice becomes easier.
Think about the next two or three years, not forever
It’s not always realistic to design a system around the idea that the same people and vendors will work together forever. In an ideal world, long-term relationships are the best. But people in the chain can change. Personal relationships can change. Teams and motives can change as well.
So both client and vendor priorities should come from roughly a two-to-three-year working perspective, while taking into account the risks of separation, changing teams and future ownership. You don’t necessarily need to build the final architecture today. But it helps to know approximately where the business may be going.
Sometimes the answer is a website constructor, sometimes HTML5 with a custom design, sometimes a custom application. And sometimes you start with one of them and gradually build custom systems around it.
Send us the business case — what the system needs to do, and where the business is heading. We’ll tell you honestly whether standard tools cover it.
Discuss your case →