WordPress, Shopify or custom development: start with the business need
Updated on
WordPress, Shopify or a custom development project: discussions often start with the tools. Yet the decision depends first on what the business needs to achieve in the coming months and what it will have to manage afterwards. A familiar platform name does not define the scope of the project.
In the video, I describe a client who chose Shopify instead of a fully custom project. The price difference mentioned belongs to that particular situation. It is neither an Umbeli price list nor an estimate of what every business can save. The useful lesson is that the most elaborate solution is not automatically the one that best fits the need.
Contents
Start with the tasks the website must support
A business presenting a few services has different constraints from a retailer with several shipping rules. A portal giving employees and customers different permissions requires another set of decisions. Describe those uses before choosing the technical label attached to the project.
Write out the complete journey: who arrives, what information is required, what action takes place and what should happen inside the business afterwards. A form feeding a CRM already belongs to a wider system than a presentation page. Its usefulness depends on the handover as well as the visible interface.
List the people who will use the administration area. Can they manage the catalogue or change text without a developer? Do they need different permissions? Comfortable day-to-day management belongs in the technology comparison, because a site continues to require attention after the launch demonstration.
When an existing solution deserves consideration
A CMS such as WordPress is worth evaluating when the team needs to publish and maintain content. A commerce platform such as Shopify can enter the comparison when the business needs a store and the platform covers its essential requirements. These are starting points for investigation rather than universal recommendations.
Check the features actually available, their limits, the necessary extensions and their costs at the time of the project. A solution that initially looks simple can become complicated when every business rule requires another addition. Ask which capabilities are included in the proposal and which are still assumptions.
For an online store project, examine the catalogue, payments, deliveries, order management and connections to internal tools. The appearance of a theme cannot settle those questions. Try a representative transaction and examine what the team must do after the customer places it.
Clarify what custom development means
A distinctive visual identity does not require rewriting every function of a website. Conversely, a visually restrained site can contain complex business logic: quotation calculations, customer access or data synchronisation. The appearance alone tells you little about the implementation effort involved.
Separate three subjects: design, content management and specific functions. A combination may be appropriate. You might keep an established foundation and develop the missing part, where the interfaces and constraints allow it. That approach still needs a clear explanation of how the pieces work together.
A custom website should be justified by the requirements it addresses. Ask what needs customising and why. The answer should describe a use, a constraint or a meaningful difference for the business, rather than treating custom code as a quality label on its own.
Compare the cost of operating the site
The creation price is only part of the picture. Include hosting, subscriptions, extensions, maintenance and the work required for changes. Ask which expenses are fixed, which depend on usage and which need a separate estimate when the project evolves.
Also ask what happens if you change provider or platform. Which content and data can you recover? Who controls the accounts? How are connections to other systems documented? A future handover becomes much easier when these matters are addressed before the original team moves on.
A suitable solution needs a realistic path forward. That does not mean building every imaginable feature immediately. It means understanding the first version’s limits and the consequences of likely changes, with enough documentation for the business to make informed decisions later.
Comparison: WordPress, Shopify and custom development
Use this comparison to prepare a discussion, without declaring a universal winner. For each option, examine the project’s main activity, the team’s responsibilities and the most uncertain requirement that should be tested first.
WordPress for an ongoing publishing activity
Consider it for: a site where pages, articles and regular editing are central. WordPress includes publishing tools and supports themes and extensions. Clarify responsibility for: hosting, updates and compatibility in the proposed configuration. Decisive test: let the intended administrator modify a representative page. The official WordPress feature overview helps distinguish the foundation from requirements that need additional work or extensions.
Shopify for running a retail operation
Consider it for: a store whose requirements fit the platform and relevant applications. Shopify provides tools to present products and process sales. Clarify responsibility for: catalogue configuration, application choices and recurring fees. Decisive test: run through a representative order, including delivery and follow-up requirements. Verify the features available in the plan being evaluated using the official Shopify documentation, rather than assuming every advertised function is included.
Custom development for specific business rules
Consider it for: journeys, roles or data exchanges poorly covered by the options evaluated. Clarify responsibility for: maintaining the code, monitoring the service and documenting changes. Decisive test: demonstrate the most uncertain rule in a working proof of concept. Custom development offers design freedom, but it also creates software whose continuing operation must be organised. That responsibility should appear in the proposal from the beginning.
A combined approach may also deserve investigation: keep a platform for the catalogue or content and build a particular function around it. Verify the connection capabilities and division of responsibilities. An integration adds another part of the system that needs testing, monitoring and maintenance.
Put every option through the same scenario
Imagine a business selling products while receiving special requests from professional customers. Its standard catalogue may fit an existing store platform. Negotiated prices, internal approvals or synchronisation with management software could change the evaluation. Describe those exceptions before deciding that the whole platform needs custom development.
Prepare a scenario with representative products, one special request and the information expected in the internal system. Ask how each solution handles it. Record remaining manual steps, included functions, required additions and points that still need demonstration. This makes the trade-offs visible without depending on a sales presentation.
Then examine a plausible change: adding a category, modifying a rule or exporting data. A solution may meet launch requirements while making a predictable evolution difficult. The right decision is one whose compromises the team understands and whose operation it can realistically take responsibility for.
Questions to answer before choosing
Define the result expected from the first version and the features essential at launch. Identify who will operate the site, with which permissions, and which systems must send or receive information. Record the costs and responsibilities that continue after delivery. Finally, state what kind of change would require a substantial new project.
With those answers, the technical comparison becomes more useful. It helps create a project proportionate to the business need, instead of allowing the developer’s favourite tool to determine what the business receives and how it will have to work.
FAQ: choosing a website technology
Does WordPress necessarily mean a generic-looking website?
No. Choosing a CMS and choosing an art direction are different decisions. An existing foundation can support a design tailored to your brand. However, check the actual flexibility of the proposal: theme, component and budget choices can limit what will be personalised. Ask to see the intended approach applied to your own content.
Is custom development always better for SEO?
The technology’s name does not establish search quality. Examine content, links, crawlable access and implementation. Ask for checks on the site actually delivered. A custom architecture can be poorly implemented, while an existing platform can be configured carefully. The useful comparison concerns what the project does, not which label sounds more advanced.
How can we compare quotes with different inclusions?
Build a common scope covering content, design, functions, migration, training and operation. Separate optional work and recurring expenses. If one proposal includes a CRM connection while another leaves it unpriced, the totals do not yet describe the same project. Ask each provider to make that difference explicit before deciding which offer is suitable.
Should every future feature be anticipated now?
Identify likely developments without building them all immediately. A hypothetical feature alone does not justify a complex architecture. A connection planned for the near future does deserve a feasibility check. Scoping a custom website should clarify what is delivered now, what can evolve and what would require a separate development project.