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#architecture

Next.js 16 + Spring Boot - our production architecture

Static Next.js frontend, Spring Boot backend, embedded admin SPA. A real-world layout from apps/site: why not a monolith, and how it actually ships.

Dawid ZmarzlakPublishedMay 9, 20263 min read

Most projects I work on end up with the same layout: static Next.js frontend + JVM Spring Boot backend + an embedded admin SPA. This isn't a first-pass decision - it's the result of several iterations. Here's what works and what I'd change if I were starting today.

Three apps, one repo

The itsolutions-platform repo is a pnpm workspace with three apps:

apps/site - the public site. Next.js 16 with output: 'export'.
apps/site/admin-frontend - the admin SPA (React Router, Vite). Embedded in site.
apps/site/backend - Spring Boot 3, PostgreSQL, JWT auth.

This isn't ideological. It's three genuinely different use cases:

App	Traffic profile	Tech decision
Public site	Long-tail SEO, 95% one-time visitors	Static export → Caddy → CDN
Admin	1 user, 100 visits/day	SPA, no SSR - fast dev cycle
Backend	Steady TPS, transactions, emails	JVM + JPA + scheduler

Each component has a different bar for uptime, cold start, and deploy frequency. Forcing them into a Next.js monolith would mean compromising everywhere a little.

Why not Next.js Server Actions instead of Spring Boot

Asked weekly. Reasons I'm sticking with the JVM:

output: 'export' rules out server logic. The site is served by Caddy with a CDN - no Node runtime spins up per request. A form lead POSTs to api.itsolutionsdz.pl, not to Next.js.
Cron, queues, transactional email. Spring Boot has @Scheduled, Spring Mail, Spring Retry. I don't want to wire retry logic into Vercel CRON handlers by hand.
Audit + typed schema. Liquibase / Flyway + JPA give me migration history and typed entities. Drizzle and Prisma on Node are fine, but for projects spanning 5+ years I lean conservative.

How admin talks to backend

The admin SPA is embedded in site:

apps/site/admin-frontend/   ← React Router, Vite
apps/site/public/admin/     ← build output, copied on `pnpm build`
apps/site/middleware.ts     ← gates /admin/* with basic auth

After login, admin holds a JWT in an httpOnly cookie. Every backend call goes through fetch('/api/...') - Caddy proxies that prefix to Spring Boot on a separate port. Cookie is SameSite=Lax, so CSRF needs its own token, but in return admin lives on the same domain as the public site without CORS gymnastics.

Deploy - no Vercel, no Kubernetes

The stack lives on one VPS:

Caddy

:80 / :443

static out/

frontend

spring-boot

:8081

Postgres

volume

One VPS, one Caddy, zero Node in the front-serving path

Deploy is docker compose -f docker-compose.prod.yml up -d --build. Static out/ is served by Caddy with no Node in the middle. Backend and Postgres run in containers with restart policies.

Conclusion

“
Architecture should be a result of project requirements, not a list of conference-stage tooling.
”

- the stack-selection rule

Three apps in a monorepo, each with its own deploy target, mean I can change the site's hero section without redeploying the backend. I couldn't pull that off in full-stack Next.js.