You need a new site, or an old one rebuilt. One vendor tells you WordPress is enough and it will be ready in three weeks. Another tells you WordPress is “for amateurs” and that you need something written specifically for you, in six months. Both are right in certain situations. Neither has asked you yet how you work.
The discussion usually starts from technology, when it should start from the process. It does not matter which platform is “better”. What matters is how standard what you do is, and how much it will change over the next few years. A store with ordinary products and one courier needs something different from a company that ships from three warehouses, with multi-level approvals.
Below you will find when WordPress is enough, when custom software is justified, what hidden costs each one has, the middle path, and the list of questions that gets you to an answer before you sign anything.
The right question: how standard is your process
WordPress, together with WooCommerce, is a collection of solutions to problems that millions of sites share: pages, articles, products, cart, payment, shipping, forms. If your problem looks like theirs, you get a ready-made answer at a low cost. Custom software builds exactly your process: nothing extra, but nothing ready-made either.
This is where the real criterion comes from. If what you do on the site can be found in any store or presentation site, you have a standard process and WordPress covers it. If what you do is different, and that difference is the reason customers choose you, the process is your product and deserves its own code. Most companies are somewhere in between: mostly standard, with one specific piece. For them, what matters is how you handle that piece.
When WordPress is the right answer
WordPress is the right choice when most of the situations below apply to you:
- A presentation site: who you are, what you do, contact details, a few service pages.
- A blog or an articles section that you update often.
- A store with standard products, fixed prices, one courier and payment by card or cash on delivery.
- Contact, quote request and sign-up forms.
- Simple bookings, of the “pick a day and a time” kind.
- Limited budget and time: you need something working in weeks, not months.
- A team that wants to edit texts, images and products on its own, without a developer.
The advantages are real: low initial cost, content that anyone can edit from the dashboard, a plugin for almost anything, cheap hosting. And if you part ways with your vendor, you find another one quickly, because a lot of people know WordPress. For a presentation site or an ordinary store, that is all that matters.
What you actually pay in year two
Problems appear when every “small” request has been solved with yet another plugin. A plugin is not just a feature. It is a separate vendor, with its own updates, its own annual license and its own decisions. Two plugin authors do not coordinate with each other, so conflicts appear: after an update, the cart no longer calculates shipping. At 30-40 plugins, the site becomes hard to maintain and slow, and every update is a small gamble. Licenses add up too, a few dozen euros a year each, until you count them all.
Page builders, the visual editors that let you make changes without a developer, generate a lot of code, loaded on every page, even where it is not used. On an ordinary phone you feel it directly in the loading time. The attack surface grows as well: most security problems come from outdated plugins and themes, and every extension is one more door to keep locked.
And the quietest loss: customizations made “on the side”. Someone edited the theme files directly to solve a request. At the next update the change disappears and nobody knows why it stopped working. Proper customizations go into a plugin of your own or a child theme, which survive updates.
When custom software is justified
Custom software makes sense when your process does not fit the patterns above. The usual signs:
- Order flows of your own: several suppliers, separate parcels from different warehouses, returns with their own rules.
- Multi-level approval: an agent enters the order, a manager approves it, a third person confirms delivery.
- Complex price calculations: per customer, per volume, per configuration, with rules that change.
- Integrations with an ERP, an invoicing system or an internal program that is the source of truth for stock and prices.
- A high volume of orders, users or data, or specific performance and security requirements.
- Portals for customers or partners: each one sees their own orders, documents and status.
- A process that is the company’s actual product: the way you work is the reason you get chosen.
The advantages: exactly what you need, no ballast, predictable performance, code that is yours and that anyone can continue. When you want a new feature, you do not search for whether “there is a plugin”, you describe it and it gets written. You can see what such a project looks like at custom software.
What nobody tells you at the quoting stage
Development takes longer. What gets installed in an hour in WordPress is designed, written and tested here. The first working version arrives in months.
You depend on the team that wrote it. If you have no documentation and the code is not in your repository, you bought a relationship, not a product. The simple test: can someone else start the application on a new server without calling the author?
Every new feature is developed, not installed. A new form, a new report: each one is a day or a week of work, more expensive than a plugin at 50 euros a year.
Without maintenance it ages just like WordPress. The language, the libraries and the server have versions that go out of support. An application left untouched for two years ends up on a PHP or a Node without security updates. The monthly maintenance budget does not disappear, it moves from licenses to developer hours.
The middle path, often the best one
For companies with a mostly standard process and one specific piece, choosing between the extremes is usually wrong. Two hybrid setups work well.
WordPress as the base, your own code for what is specific
The site, the content, the products and the cart stay in WordPress and WooCommerce. The specific part is written as a single plugin of your own, with the code in your repository, not as 15 plugins glued together. One example: a store with products from several suppliers, each with its own warehouse. WooCommerce does everything standard, and a custom plugin splits the order by supplier, generates a shipping label (an AWB, as Romanian couriers call it) for each parcel and sends the customer a single notification. Another example: a configurator with its own pricing rules, which calculates the quote on the spot and sends it to invoicing.
WordPress for content, a separate application for the process
When the specific part is large, you keep it separate. WordPress holds the pages, the blog and everything marketing edits. The process (a customer portal, a catalog with thousands of products and its own import rules, a booking system with resources and availability) lives in an application written for it, on a subdomain. The two talk through an API and each part can be replaced separately.
The practical rule for a hybrid: if a feature exists as a good plugin and you use it the way it was designed, install it. If you have to modify it to fit your process, or you need three plugins wired together to get one flow, write it.
The decision criteria, as a list of questions
Answer each one honestly, in writing.
- How standard is the process? Can you describe it in the words of any ordinary store, or does it need explaining?
- How much will it change in the next two years? A stable process can live with a plugin. One that changes every quarter needs code you control.
- Who edits the content? If the team wants to change texts and products on its own, WordPress stays, at least for the content.
- What integrations do you have? ERP, invoicing, couriers, CRM. The more there are and the more specific they get, the more weight your own code carries.
- What volume? Dozens of orders a day or thousands? Hundreds of products or hundreds of thousands?
- What monthly maintenance budget do you accept? Not the initial one, the monthly one. Licenses and updates on one side, developer hours on the other.
- Who owns the code and the data? Do you have access to the repository, the database, the server? Can you take them and leave?
- What happens if the vendor disappears? With WordPress, you find another vendor easily. With your own code, it depends on the documentation and on how common the technologies are.
Put side by side, the criteria look roughly like this, as tendencies from practice, not absolute rules.
| Criterion | WordPress | Custom software | Hybrid |
|---|---|---|---|
| Initial cost | Low | High | Medium |
| Monthly cost | Plugin licenses, hosting, updates | Developer hours, hosting | Both, but fewer licenses |
| Time to launch | Weeks | Months | Weeks for the site, months for the specific part |
| Flexibility | High for standard, low for specific | Total, but every change is developed | Standard from plugins, specific from code |
| Maintenance | Frequent updates, conflicts between plugins | Language and library versions, less often but more technical | Both, in smaller volume |
| Vendor dependence | Low, many people know WordPress | High, if you do not have the code and documentation | Low for the site, medium for the code |
| Performance | Depends on the number of plugins and on the theme | Predictable, as far as you designed it | Good if the specific part is separate |
Signs that you chose wrong
You have an overloaded WordPress if you pay monthly for plugins you only half use, if every small request turns into a week of work, or if the site breaks on updates and you have stopped doing them.
You chose wrong in the other direction if you have a custom-built application for something that was, in fact, a blog with a form. Every new page goes through a developer, and the budget goes on things WordPress does from the dashboard.
Most often, the mistake is not the platform but the way the customization was done. A WordPress with one well-written custom plugin lasts for years. One with edits made directly in the theme and 40 extensions breaks at the first major update. Before you change the platform, check whether only the way of working needs to change.
Checklist
- Write down your process from customer to delivery, step by step, on one page.
- Mark the steps that can be found in any ordinary store or site.
- Mark separately the steps that are only yours, and why they matter to customers.
- Note the integrations: invoicing, couriers, ERP, CRM, internal systems.
- Estimate today’s volume and the volume in two years: orders, products, users.
- Decide who edits the content and how often.
- Decide the monthly maintenance budget you accept, not just the launch budget.
- Ask every vendor for: code in your repository, documentation, access to the server and the data.
- For WordPress, ask for customizations to live in a custom plugin or a child theme.
- Ask what happens if the vendor disappears and get the answer in writing.
Write your process on one page, from the first contact with the customer to delivery, as a list of simple steps. Then mark the steps that cannot be found in any ordinary store or site. If you marked nothing, WordPress is the answer. If you marked half of them, you need your own code. If you marked two or three steps, you have found exactly the part worth writing, and the rest stays standard.