How much does a website cost?

It depends on scope: a simple WordPress business-card site (Express) starts at 3,000 PLN, a Next.js landing page from 5,750 PLN, and a full company website from 13,150 PLN. You get an exact quote for your project from the online calculator or within 48 hours of the brief.

How much does an online store cost?

A WooCommerce store with a small catalog, one payment gateway and basic integrations starts at 10,150 PLN. The price grows with the number of products, integrations (BaseLinker, ERP, marketplaces) and the design tier — the calculator gives you exact numbers.

How long does project delivery take?

It depends on scope: an Express business-card site takes 5-7 days, a Next.js company site or landing page 4-8 weeks, a WooCommerce store 3-8 weeks, and a web app from 12 weeks. Every project gets a weekly schedule together with the quote.

What affects the price of a website or store?

The price depends on the platform (WordPress or Next.js), number of pages, design tier, and the integrations you choose (payments, CRM, ERP, multilingual support). That's why prices are shown as a starting point, not one fixed number — the calculator gives you an exact figure for your scope in real time.

How much does post-launch maintenance cost?

Maintenance and hosting come as three monthly plans: Basic 240 PLN, Standard 640 PLN, Premium 1,600 PLN — they differ in incident response time (4-24h) and monitoring scope. Updates, backups and SSL are included; you can also host it yourself and just call me for occasional fixes.

← Back to blog#wordpress

Headless WordPress for product catalogs - when it makes sense

Headless WP sounds sexy, but it doesn't always pay off. Five scenarios where it's the right call, and three where you should stick with the monolith.

Dawid ZmarzlakPublishedMay 6, 20264 min read

"Let's do headless WordPress" - this sentence shows up in briefs more often than it should. Most of the time, the client wants Next.js with a nice editing panel and thinks that's what they need. Sometimes they're right. Often they're not.

“
Headless WP isn't a WordPress upgrade. It's a completely different maintenance model - and half the clients who want it actually need something simpler.
”

What "headless WP" actually means

WordPress as a CMS gives you two interfaces:

Classic stack - a PHP theme renders the frontend. WooCommerce, Elementor, the whole familiar circus.
Headless - WP serves only the REST API or GraphQL (via WPGraphQL), and the frontend is built in something else (Next.js, Astro, SvelteKit).

In a headless setup WP keeps:

the editing panel (Gutenberg / Block Editor),
user and role management,
the media library,
plugins for SEO, forms, backups.

It loses:

its own rendering (the theme is unused),
live preview out of the box - needs frontend wiring,
ready-made integrations with page builders (Elementor / Divi stop making sense).

Five situations where it makes sense

1. Product catalog + content marketing on one domain

A client runs a B2B store with 500+ SKUs plus a blog with 200 articles. On the frontend they want a very fast site with great Core Web Vitals. The result: Next.js statically generates the listing with ISR (revalidate hourly), the editing panels stay in WP where marketing already knows the interface. Payoff: 90+ Lighthouse, a panel the marketing team doesn't need training for.

2. Multi-channel publishing

The same content (product copy, articles) needs to land in:

the website,
the mobile app,
a newsletter (Mailchimp / Customer.io),
a partner integration (XML feed).

The WP REST API becomes one source of truth. Without going headless you'd be rewriting copy in five places.

3. Strict design system with code-only components

The client has a design system in Figma mapped 1:1 to React components. A WP theme would be a gateway to chaos - any editor could paste arbitrary HTML. In a headless setup the editor block defines the data structure and the frontend renders it with known components. The design system stays intact.

4. Frontend-side personalization

If the site has to show different content to logged-in vs anonymous users, A/B-test hero variants, or do geolocation routing - you do that at the edge / middleware layer, where WP's PHP would just be in the way.

5. The client picks a VPS over shared hosting

Classic WP hosting (cPanel and friends) is built around PHP and MySQL. If the client has a VPS and likes Docker - headless WP lives in one container, the frontend in another, Caddy / Nginx proxies them. Hosting no longer dictates architecture.

Three situations where it's the wrong call

1. Client has 5 subpages and 1 editor

Headless WP for a business-card site is overengineering. Classic theme plus a light page builder (Bricks or a homegrown ACF setup) ships faster, cheaper, with better preview.

2. Site has to be maintained internally by a non-technical team

In a headless setup live preview needs configuration. Every React component change requires a frontend deploy. If the client wants "click and publish" - the WP monolith wins, because Gutenberg renders directly.

3. E-commerce with WooCommerce as the engine

WooCommerce works in a headless setup, but you lose everything Woo gave you for free - cart, checkout, payment integrations, transactional mail, reporting dashboards. You end up rebuilding all of that on the Next.js side via the WooCommerce REST API. If the store has fewer than 500 products and doesn't need a custom checkout flow, the classic Woo theme wins by light-years.

Decision table

Signal	Classic WP	Headless WP	Next + Sanity / Payload
Client knows WP	Yes	Maybe	No
Site has 10+ repeating templates	Maybe	Yes	Yes
Site has 3-5 pages, rarely updated	Yes	No	No
High performance required (CWV)	Maybe	Yes	Yes
E-commerce with WooCommerce	Yes	No	No
Multi-channel publishing	No	Yes	Yes
Client has their own PHP hosting	Yes	Yes	No
Client wants click-and-publish	Yes	Yes (with preview)	Yes

There's no single answer. There are nine questions worth asking before you make the call.