DEV Community

Cover image for I built an open-source SEO landing builder (Next.js + Payload). But I need your help — is this actually useful?
AntonAmbarov
AntonAmbarov

Posted on

I built an open-source SEO landing builder (Next.js + Payload). But I need your help — is this actually useful?

#nextjs #opensource #seo #marketing

The problem I kept seeing

I've spent years in SEO across enterprise teams and different niches. Then I became a full-stack developer.

And I kept running into the same issue:

The SEO-Dev gap.

In every company I worked for, SEO tasks were stuck in a backlog. Changing an H1, adding a FAQ block, or updating a phone number — these are 2-minute tasks that take 2 weeks because they need a developer.

I've been on both sides. I know why devs hate these tickets. And I know why SEOs get frustrated.

The enterprise solution?

In big companies, they build internal landing constructors. Custom tools where SEOs can build pages themselves — no designers, no frontend devs, no waiting.

But every company rebuilds the same thing from scratch. Expensive. Time-consuming. Only big players can afford it.

So I built an open-source alternative.

Introducing SEO Landing Constructor

A free, self-hosted landing page builder with SEO at its core.

Built with: Next.js 15 (App Router), Payload CMS 3, TypeScript, Tailwind CSS, shadcn/ui, PostgreSQL + Drizzle

MIT licensed. Deploy on your own infrastructure. No vendor lock-in.

What it does right now (MVP)

For SEOs & Marketers:

  • Blocks-based builder — Hero, Pricing, FAQ, Testimonials, CTA, Features. Assemble pages in minutes.
  • Visual Block Customization — adjust padding, margins, background, theme (dark/light) directly from admin panel.
  • Global shortcodes — change price, phone, company name in ONE place. Updates across ALL pages instantly.
  • Bulk JSON import — migrate entire page structures or generate pages via AI in seconds.

For Developers:

  • SEO out of the box — SSR, metadata, sitemap, schema.org, Open Graph, optimized Core Web Vitals
  • overrides/blocks/ system — customize any block without touching core code. Keep your design system.
  • Self-hosted — deploy on your domain, subdomain, or separate domain. Full control.
  • Clean codebase — well-structured, TypeScript, modern stack

Architecture deep dive

Here's the high-level structure:
├── payload/blocks/ # Block schemas for admin panel
├── components/blocks/ # React components for frontend
├── components/overrides/ # Safe customization layer (!!)
├── payload/globals/ # Global settings & shortcodes
└── components/ui/ # shadcn/ui base components

The key design decision: the overrides/ folder.

Developers can override ANY block without modifying the core package. This means:

  • You keep your design system intact
  • You can add custom business logic
  • You don't fight with the CMS when you need to customize something
  • Upgrades don't break your customizations

Why this matters: Most open-source CMS tools force you to either accept the default UI or fork the entire project. This approach gives you the best of both worlds — a working system out of the box, with escape hatches when you need them.

What's coming (Roadmap)

In progress:

  • Live Preview & Draft mode — see changes before publishing

Next:

  • Advanced SEO blocks — Stats, Trust Bar, Comparison Table, Logos, Countdown, FAQ with schema
  • Custom HTML Block
  • Built-in form handling with server actions
  • Page templates — reusable structures
  • A/B testing for individual blocks
  • Multi-language (i18n) support

Future:

  • Reusable Widgets system
  • AI-assisted content generation
  • Analytics integration (GTM/GA4)
  • CLI improvements
  • Smart page templates with block inheritance

Where I need YOUR help

This is an MVP. There are bugs. The UI isn't perfect. And I'm not sure if I'm building the right thing.

So I have some open questions for the community:

  1. Is this actually useful? — Would you (or your marketing team) use something like this? Or is the problem not painful enough?

  2. What blocks are missing? — What landing page components do you constantly rebuild? What would make you switch from Webflow/Carrd/your current solution?

  3. Devs — what would make this easier to adopt? — Better CLI? More documentation? Video tutorials? Docker setup?

  4. SEOs — what's the #1 feature you wish existed? — I've built what I think you need, but I might be wrong.

  5. How should I grow this? — Focus on more blocks? Better developer experience? Marketing site? Community?

  6. Is the overrides/ approach actually useful? — Or should I make customization even simpler?

Try it. Break it. Tell me what sucks.

Live Demo: https://create-seo-landing.vercel.app/

Admin Panel: https://create-seo-landing.vercel.app/admin/
login: demo@demo.com
pass: Demopassword

GitHub Repo: https://github.com/AntonAmbarov/create-seo-landing

Quick start:

git clone https://github.com/AntonAmbarov/create-seo-landing.git
cd seo-landing-constructor
cp .env.example .env
pnpm install
pnpm dev
Enter fullscreen mode Exit fullscreen mode

The bigger picture

I've seen this work in enterprise. Now I want to make it available for everyone — indie founders, small teams, agencies, and anyone tired of the SEO-Dev gap.

But I can't build this alone

I need feedback. I need people to break it. I need to know if I'm solving a real problem or just building something that seems cool.

So if you have 5 minutes:

Try the demo

Break something

Leave a comment telling me what you think

GitHub: https://github.com/AntonAmbarov/create-seo-landing
Open to: Contributors, feedback, feature requests, and brutal honesty.

Thanks for reading 🙌

Top comments (0)