Technology
WordPress or a custom-built site? How a small business should decide
An honest comparison: when WordPress with a ready-made theme is the right call, and when a custom Laravel build saves you money and headaches long-term — maintenance, security, integrations, code ownership.
The short answer: it comes down to three things
If you want a quick, affordable solution for a blog or a simple presentation site that you'll edit yourself every week, WordPress with a ready-made theme is a reasonable choice. If your site needs to do real work for your business — take bookings, issue e-invoices, connect to a POS or payment system, or simply stay fast and secure for years without you thinking about it — a custom-built site on a modern framework like Laravel almost always wins over the long run.
The answer doesn't hinge on WordPress being a "bad" tool — it isn't; millions of sites run on it without issue. It comes down to three things: how often you change content yourself, whether the site needs to do something specific to your business, and how much it costs you in headaches when something breaks on a Monday morning and you're not the one who knows why.
When WordPress is a good option for a small business
There are situations where I'd honestly recommend WordPress, even as someone who builds every site from scratch in Laravel. If you run a blog you update every week, if your budget is tight and you need a site fast, or if you already have someone who knows how to manage WordPress and that relationship works for you — a ready-made theme with a few adjustments can be enough. I don't push the same solution on every client; if WordPress genuinely suits you better, I can work with it too.
WordPress also makes sense when the site is a static showcase with no transactions, integrations, or booking systems — a simple presentation of opening hours, services, and contact details. For that case, an expensive custom build would be over-investing in more than the site actually needs to do.
When a custom-built site makes more sense
The moment a site stops being a showcase, the math changes. A web shop that, from 1 January 2026, has to fiscalize every invoice it issues to an end customer — regardless of whether they pay by card, bank transfer, or cash on delivery — and, if it sells to other VAT-registered businesses, has to send e-invoices, needs a data flow that works reliably every single day. Not a plugin someone else maintains and that can stop working after the next WordPress update. The same goes for booking systems, client portals, or anything that connects to your POS or accounting software.
A custom build also makes sense when page speed and Google ranking matter to you — a WordPress site with a dozen plugins rarely hits the same performance as a site written from scratch for exactly what it does, with no extra code loading "just in case." And it makes sense when you want the code to be yours, built on technology any other developer can pick up, instead of locked into one platform's ecosystem and someone else's plugins.
Maintenance and security: the hidden cost of plugins
What rarely comes up at the start of a WordPress project is how much work it demands after launch. Every plugin is a separate piece of software someone else maintains — or doesn't. According to Patchstack's State of WordPress Security report, 11,334 new vulnerabilities were reported across the WordPress ecosystem in 2025 — 91% of them in plugins, 9% in themes, and just six in WordPress core itself. A site with ten plugins carries ten separate risks someone has to track and patch, month after month.
That doesn't mean every WordPress site is vulnerable — it means security becomes an ongoing job, not a one-time cost settled at launch. A custom-built site has a smaller attack surface simply because it doesn't carry dozens of third-party plugins someone else controls and changes without warning; the code that exists is code I wrote and understand in full.
A vulnerable system in practice: the Stela Apartmani case
This isn't an abstract story about security. When I took over Stela Apartmani, a family business that's hosted guests near Šibenik for 30 years, their old site wasn't even running on WordPress — it ran on its own CMS dating back to the PHP 7.2 era. An independent security audit found nine critical vulnerabilities: a database password stored in plaintext, SQL injection in dozens of places, admin passwords with no hashing at all, and the entire admin panel sitting exposed directly in a web-accessible directory.
I bring this case up in a piece about WordPress because the risk pattern is the same for any old, neglected system — a homegrown CMS, an outdated WordPress install with dozens of unpatched plugins, it doesn't matter which. I replaced the old site entirely with a new one on Laravel, kept all six languages, and set up 301 redirects from every old address, so the Google ranking wasn't lost even on migration day. The owner still edits the apartments, gallery, and blog himself, from a single dashboard, with no need to touch code.
Ownership of code, data, and continuity
With a custom-built site, the code is yours. I build on a modern, mainstream stack (Laravel, Livewire, Tailwind) that any other developer can pick up tomorrow and continue — you're never locked in to just me. With WordPress, ownership is murkier: you often license the theme and plugins rather than fully own them, and changing developers means someone else has to reverse-engineer another person's configuration of dozens of plugins and guess why something was set up that way.
Data tells a similar story. A custom admin application means I shape the database and content structure around your business — apartments, orders, bookings — rather than around the generic "post" and "page" model WordPress offers everyone equally, which then has to be bent into shape with plugins to fit your case.
Hosting and costs you don't see up front
A WordPress site usually comes with a tangle of subscriptions too: hosting, a premium theme, a handful of premium plugins, a security plugin, a caching plugin to claw back the speed lost to all the others. Each of those subscriptions needs renewing, and each is a point that can lapse at the wrong moment. A custom-built site of mine runs on isolated VPS infrastructure dedicated solely to your project, with updates and backups that I manage — one cost, one point of contact, instead of a pile of small subscriptions someone has to keep track of.
Integrations that WordPress plugins rarely handle well
For a simple presentation site, integrations rarely matter. The moment real business logic shows up — e-invoicing under Fiskalizacija 2.0, connecting to a POS system, a booking system that has to check availability in real time — WordPress plugins usually do the job "well enough" until an edge case appears that the plugin's author never planned for. Then the fix waits on the plugin's next update, which neither you nor I control.
A custom-built site builds that logic directly, tested for your actual use case rather than for the average plugin user. If e-invoicing, your POS, or a booking system has to work without fail every single day, that's a strong signal you're investing in the foundation, not in a plugin standing in for one.
Migration runs both ways
Migration isn't a one-way street. If you currently run a WordPress site that loads slowly or fills you with dread every time an update notice arrives, its content can move to a custom build without losing your Google ranking — I ran that same redirect process for a site that wasn't even on WordPress, Stela Apartmani, where every old address now redirects to a new one. The reverse is also true: if a custom application outgrows what you actually need and you'd rather have a cheaper, simpler blog, that content can be exported elsewhere. The decision isn't permanent, but it's easier to start on the right foot than to migrate later under pressure. In practice that decision comes down to traffic and enquiry volume, not mood on the day — the numbers show whether switching platforms actually makes sense.
How I approach the decision
I don't open a client conversation by asking "WordPress or Laravel?" I open it by asking what the site needs to do for your business — does it take orders, does it issue invoices, does someone other than me need to edit content. The technology follows from that, not the other way round. If the answer is a simple presentation site you rarely change, I'm not going to sell you a pricier custom build you don't need. If the answer is that the site has to carry your business every day, I'll tell you honestly why a WordPress plugin isn't the right long-term investment.
Technology is a tool, not an identity. I choose it based on what your site needs to do for your business — not on what's faster for me to write.
If you're not sure which side your case falls on, take a look at the overview on the web development page or describe your project — you'll get an honest answer within 24 hours, not a pre-decided solution.