"What would you recommend — WordPress, or something built from scratch?"

I get this in about half of first conversations, and it usually arrives with a certain fatigue. By then the person has read that WordPress is the best thing on the internet, and separately heard from a friend in IT that it's rubbish.

I work with both. The answer I give most often is a boring one: for most of the companies who write to me, WordPress is a sensible first choice. But it has a fairly clear limit, past which it stops paying for itself — and it's worth knowing where that limit sits before you commit to it.

A note on figures: everything below is in Polish złoty, since that's what I quote in. Divide by roughly four for a rough figure in euros.

What actually separates the two

WordPress is an off-the-shelf content management system. You install it on hosting, add a theme and some plugins, and you get an admin panel where you can write copy, swap photos and add pages without touching code.

A custom site is code written for one company. It has no features you'll never use, because nobody wrote them.

The analogy that usually lands: WordPress is a house from a catalogue. A custom site is a project with an architect. The catalogue house isn't the worse option — it's predictable, cheaper, and it's finished sooner. You go to an architect when the plot or the way you live doesn't fit the catalogue.

When WordPress is the right call

Over 40% of the web runs on WordPress, and that isn't an accident.

The entry cost is low. A brochure site on a good theme sits at the bottom of the 1,000–8,000 PLN band. For a company still finding out whether a website brings them customers at all, that's a sensible number to start with.

It launches fast. Four to six weeks and it's live. If you're opening premises in spring, the difference between "next month" and "next quarter" is a real one.

You can run it yourself. This is the advantage people discount most often and the one that decides most often. After a fortnight of getting used to the panel, a client is adding posts, updating the price list and uploading photos from the last job. They don't have to write to me about every typo — and, more to the point, they don't have to pay for one.

Plugins cover most ordinary needs. Bookings, forms, newsletters, a shop, an accounting integration. Rarely the best possible solution, almost always a sufficient one, and available today.

Search optimisation works fine. Contrary to what you sometimes hear, WordPress doesn't get in the way of ranking. Titles, descriptions, heading structure, sitemap — all within reach.

Concretely: a hotel or guesthouse that needs to show rooms, prices and take bookings. A clinic, a workshop, an accountancy practice. A shop with a few dozen products. In every one of those cases I'll suggest WordPress without hesitation.

Where the limit sits

There are a few signals that WordPress has turned from a saving into a cost. They usually show up together.

The plugin count climbs. An install with fifteen plugins is fifteen separate projects, each with its own release cycle, its own author, and its own chance of being abandoned. Each one adds database queries and tens of kilobytes to every page. You see the result in load time.

Performance stops responding to fixes. Up to a point, caching, image optimisation and better hosting all help. After that the only lever left is removing features, and nobody wants that.

The attack surface grows. WordPress is popular, so it gets studied — by some people to patch it, by others to break it. Essentially every compromise I've been called to went in through an un-updated plugin rather than the core system. That's manageable, but it requires somebody to be managing it. More on this below, because it's the crux.

You want something that isn't in the catalogue. An unusual ordering process, an integration nobody else uses, your own pricing logic. At that point you're hiring a developer anyway — except now they're writing code inside somebody else's constraints. You pay custom rates and get template flexibility.

Fixed costs creep up quietly. The pro tier of the SEO plugin, the backup plugin, the caching plugin, the security plugin. Each a few hundred złoty a year. Plus heavier hosting, because the install got heavy. Individually these are small sums — the problem is that they grow quietly and nobody adds them up.

When a custom build pays for itself

A site written for one company is an 8,000–20,000 PLN investment for a typical business site, and 20,000 PLN upward once there's real commercial logic, integrations and a larger catalogue involved.

What that buys:

  • Speed that doesn't degrade. There are no plugins eating it.
  • A smaller attack surface. There's no third-party code sitting un-updated.
  • A data model shaped like the business actually works — rather than bending blog posts into a product catalogue.
  • Ownership. The code is yours, documented, and another developer can pick it up.

Concretely: a shop with thousands of products, a portal with user accounts, a booking system taking payments, a site serving several locations with separate price lists. Anything where the website isn't describing the business so much as forming part of how it runs.

The five-year arithmetic

Comparing build costs alone is misleading, because it ignores what happens afterwards.

WordPress, brochure site:

  • build: 3,000–8,000 PLN
  • hosting: 200–600 PLN a year (an install with plugins needs more than a static site)
  • paid plugin tiers: 200–800 PLN a year
  • maintenance and updates: 1,200–6,000 PLN a year
  • occasional emergency fixes: unpredictable, but real

Custom, business site:

  • build: 8,000–20,000 PLN
  • hosting: 100–300 PLN a year (a lighter site asks less of the server)
  • maintenance: lower, because there are no plugins to watch

After five years the gap is noticeably smaller than the first invoice suggests. That doesn't mean custom always wins — it means comparing 5,000 to 15,000 without the rest of the arithmetic leads to a bad decision.

A simple test

WordPress makes sense if:

  • you need the site within weeks
  • the build budget is a few thousand złoty
  • the site is reasonably ordinary: services, past work, blog, contact
  • you want to edit content yourself
  • you accept that somebody has to look after it regularly

A custom build makes sense if:

  • the business is growing and the site has to grow with it
  • performance translates directly into revenue
  • you have requirements no template covers
  • you handle customer data and security is a real subject
  • you're looking at a five-year horizon rather than a one-year one

The middle option

There's a variant people rarely mention: WordPress as the admin panel only, with no front end of its own, and a separately written interface on top. Your editors work in a tool they already know, and the site is fast because none of WordPress reaches the browser.

It works well for content-heavy sites where somebody non-technical is publishing daily. It costs what a custom build costs, so it isn't a shortcut — it's a way to keep comfortable editing alongside good performance.

The thing that matters more than the choice itself

After years of this I've come to a view: whether a site runs on WordPress or on its own code matters less to how it ends up than whether anyone is looking after it.

I've seen WordPress installs running beautifully after six years, because somebody spent an hour a month on updates. I've also seen custom-built sites that wouldn't compile after three, because nobody had touched a dependency since launch.

The technology choice sets your ceiling. Maintenance decides where you actually land. It's why every quote I write includes a conversation about what happens after launch — I've written about that separately in website technical support.

If WordPress: plan updates, backups and monitoring from day one. If custom: make sure somebody refreshes dependencies even when nothing appears broken.

In short

For most companies who come to me, the sensible path looks like this: start on WordPress, give the site a year or two to show whether it brings in customers, and only then decide about rebuilding — on the strength of data rather than instinct.

The exception is projects where the website is part of the product rather than a description of it. There, starting from a template usually costs you a year.

Not sure which side of that line you're on? Get in touch. We'll go through what the site actually has to do, and I'll tell you plainly which is the more sensible option in your case — including when the most sensible option is keeping what you already have.