Why We Don't Build on WordPress

The position, up front

Seypro doesn't build on WordPress. We don't take WordPress projects, we don't take maintenance retainers on existing WordPress sites, and we won't migrate a project onto WordPress for you. Clients sometimes ask, and the answer is the same every time. This article explains the reasoning so the position is on the record.

It's not about WordPress being a bad product. The platform powers a meaningful share of the public web and works well for plenty of cases. It's that the kind of work we do — production systems for regulated industries, telecoms, fintech, and security SaaS — operates on a different set of constraints than the ones WordPress was built for, and the gap is wide enough that bridging it is more expensive than starting from a stack that fits.

Where the position comes from

Three things drive it, in order of how often they matter:

• Attack surface. The plugin and theme ecosystem is the value of WordPress and also its largest source of risk. Every plugin a site depends on is a separate codebase, on a separate update cadence, with separate ownership. For systems where security posture is part of the contract, that risk surface is structural — you cannot harden it away.
• Operational fit. Our engagements involve real-time data, deep backend integrations, audit-grade logging, custom auth flows, and infrastructure that auto-scales. WordPress is a content management framework first and a platform for that kind of work second. Everything beyond CMS becomes a fight against the framework rather than with it.
• Code ownership and portability. Clients we work with care that the codebase is portable, deployable anywhere, and not held hostage to a hosting provider's plugin pricing. A typical WordPress install accumulates a long tail of paid plugins; the value-creation path runs through that ecosystem rather than around it.

If a project's fit is genuinely WordPress — a content site for a small team that doesn't need much beyond editorial — there are agencies that specialise in it and do better work than we would. We refer those clients out.

What we build with

Across the active client roster, the stack we use is consistent because it earns its place on each project, not because it's a default:

• Nuxt 4 or Next.js for the application layer — server-rendered, edge-cacheable, with SPA-like interactions where they help and SSR where they matter.
• TypeScript end-to-end so the contract between the frontend and the API is checked at compile time rather than at runtime in production.
• Postgres (typically Neon for serverless or AWS RDS for fixed footprint) as the system of record. Drizzle or Prisma as the ORM where type safety into the database matters.
• Vercel for the most common hosting target; AWS or self-hosted where compliance, region, or cost economics demand it.
• A CMS where the content workflow earns one — but built into the application, not a plugin economy bolted onto it. Marketing teams get a real admin surface; we don't ask them to learn WordPress to update a page.

What this means for migration projects

Most projects that come to us as 'we want to migrate from WordPress' are well-suited to the work we do. Content extraction, URL preservation, redirect mapping, schema continuity, and a phased cutover are all part of how those engagements run. The migration target is custom — the new site behaves like a product, not a CMS install.

What we don't do: stand up another WordPress instance to receive the migration, or pick a theme + plugin combination that approximates what the client had. The migration target is the architecture we build with everywhere else.

See how we approach website design and custom software development — and the related comparison piece, custom software vs no-code platforms.