Web app or WordPress? How to choose

“Can WordPress do this?” comes up a lot, and the answer is nearly always yes. With enough plugins and custom code, WordPress can run bookings, memberships, portals and dashboards. The better question is whether it should.

Here’s how we help clients choose, and why the answer is often “both”.

What WordPress is great at

WordPress is a content management system. It’s at its best when the heart of the job is publishing and presenting information:

• Company websites, service pages and landing pages
• Blogs, news sites and magazines
• Online shops of most sizes, with WooCommerce
• Sites where people without technical skills need to edit pages every week

It has an enormous ecosystem, an editor lots of people already know, and plenty of developers who can work on it. For those jobs, a custom-built alternative would cost more and give you less.

Where WordPress starts to strain

Problems appear when a site stops being mainly about content and becomes mainly about processes:

• Complex roles and permissions. Customers see only their own records, staff see their region, managers approve and finance exports. WordPress’s user roles can be extended, but deeply custom permissions get fragile.
• Data with lots of connections. Jobs linked to customers, locations, technicians, parts and invoices. WordPress stores most custom data in general-purpose tables designed for posts. It works, but queries get slow and messy as the data grows.
• Workflows with stages. A request moves from new, to quoted, to approved, to scheduled, to done, with rules at each step and a record of who changed what.
• Heavy integrations. Two-way syncing with accounting, payment, SMS or delivery systems, reliably, with retries when something fails.
• Lots of logged-in users at once. Page caching, which is what makes WordPress fast, does little for logged-in users, because every page they see is personal.

When a WordPress site is held together by a dozen plugins that each handle part of a workflow, and nobody is quite sure which one owns the data, that’s usually the sign.

What a custom web app gives you

A web app is software built around your specific process:

• A data model designed for your records, so searches and reports stay fast as the data grows
• Permissions that match how your business actually works
• Screens built for each task, not adapted from a blog editor
• An API, so your other systems, or a mobile app later on, can use the same data
• An audit trail on anything that changes money or status

The trade-offs are real. It costs more up front than configuring plugins, every feature has to be built rather than installed, and it needs good documentation and mainstream technology so other developers can maintain it later.

Five questions to ask

1. Is the main job publishing, or processing? Publishing points to WordPress. Processing points to an app.
2. Who logs in? If it’s mostly your own team editing content, WordPress. If it’s customers, partners or staff each doing different jobs with their own data, lean towards an app.
3. How much do the rules matter? If a mistake costs money, like a double booking, a wrong invoice or a missed approval, you want those rules in code built for them.
4. What does it need to connect to? One or two simple integrations are fine in WordPress. A system at the centre of several others is an app.
5. Where will it be in three years? If you expect it to grow in users, data and rules, build for that shape now.

The common answer: both

Plenty of businesses end up with a WordPress site and a web app side by side:

• yoursite.com runs on WordPress: marketing pages, the blog and help articles, edited by the team.
• app.yoursite.com is the custom app: customer logins, bookings, invoices and dashboards.

Each does what it’s good at. The marketing team keeps an editor they know, and the app isn’t slowed down or put at risk by plugins meant for the website. The two can share a design, so customers barely notice moving between them.

Mistakes to avoid

• Building an app for something a plugin already does well. If a mature, well-supported plugin covers most of the need, adapting it is usually wiser than starting from scratch.
• Stretching WordPress past its shape. Adding one more plugin to a workflow, year after year, until the whole thing is too fragile to change.
• Choosing technology nobody else can maintain. Whatever you build should run on mainstream tools you can hire people for.

Our web apps are built on mainstream technology (TypeScript, Node or PHP, and Postgres), so you’re never locked in to us. And when WordPress is the right answer, we’ll say so.