Landing Page Builder

Free — GPL coresize Mplanned, not built

Generated from docs/plan/core/landing-page-builder/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merged from duplicate proposals: “Landing Page & Sales Funnel Builder”

A free core feature that lets merchants create distraction-free promotional landing pages using drag-drop templates, designed for email campaigns and ad funnels. Paid tiers add premium template designs and advanced component libraries.

The problem

Merchants’ blog pages have sidebars, navigation, and footer links that distract visitors from a campaign goal (signup, download, product purchase). They need dedicated landing pages optimized for a single action, but building them requires design or code skills they don’t have.

What it does

• Drag-drop landing page builder with basic blocks (hero, CTA button, form, product showcase, testimonials, FAQ)
• Template library with 10-15 free starter templates (product launch, email signup, giveaway, discount, webinar)
• Page metadata (title, description, slug, SEO settings)
• One-column and two-column layouts with mobile-responsive preview
• Image and video blocks (upload or URL)
• Form builder (fields: email, name, custom fields; integrates with subscriber list)
• CTA button customization (text, color, link target)
• Publish to custom domain or AstroCMS subdomain
• Page performance metrics (views, clicks, form submissions)
• A/B testing (two pages, traffic split, click-through rate comparison)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Conditional logic (show/hide blocks based on UTM parameters) — paid module owns dynamic personalization; core can’t model state
• Third-party embed scripts (Gated content, Typeform, custom widgets) — security risk; paid credential module owns allow-list
• Multi-step forms (progressive profiling across pages) — paid owns form state machine and funnel orchestration
• Landing page analytics deep-dive (cohort analysis, attribution models) — paid owns cross-channel attribution; core only tracks page-level metrics
• Premium template designs (Unbounce or Leadpages quality) — paid owns design team and template updates
• Custom domain SSL (HTTPS on custom domain requires cert provisioning) — infrastructure; document manual cert upload or paid upgrade

Data model

New entities: landing_pages {id, name, slug, title, description, templateId, status (draft/published), publishedAt, blocks[], customCss, ownerId, createdAt}; landing_page_blocks {id, pageId, type, order, config{text, imageSrc, linkUrl, …}}; landing_page_analytics {id, pageId, views, clicks, formSubmissions, conversionRate}; landing_page_variants {id, pageId, variant (A/B), blocks[], trafficPercentage}.

API

• POST /api/landing-pages
• GET /api/landing-pages
• PATCH /api/landing-pages/{id}
• DELETE /api/landing-pages/{id}
• POST /api/landing-pages/{id}/publish
• GET /api/landing-pages/{id}/preview
• GET /api/landing-pages/{id}/analytics
• POST /api/landing-pages/{id}/variants
• GET /api/landing-pages/{slug}

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Dashboard: create, list, edit, publish/unpublish, delete pages. Drag-drop editor: block palette, preview pane, settings panel. Analytics: views over time, form conversion rate, A/B test winner. SEO preview card showing title and meta description.

The seam — why this is core

Core owns interface (drag-drop builder, free templates, publish/unpublish) and honest implementation (basic blocks, mobile preview, form submission). Paid modules own premium template library (design team), conditional logic and personalization (state machines), third-party embeds (credentials and security).

Core owns the interface and basic template implementation for landing pages as a content type distinct from blog. Paid owns premium template design and advanced component library.

Dependencies

• Email service (to send form submissions to subscriber list)
• Storage (to save landing pages, variants, form submissions)
• Scheduler (optional, for time-based A/B test rotation)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A page created from ‘Product Launch’ template renders with hero image, product grid, CTA button, and form
• A form submission to landing page creates new subscriber record with email and name from form fields
• A/B test split shows variant A to 50% of visitors and variant B to 50%, within ±5% accuracy
• A published page is accessible at {domain}/landing/{slug} and renders mobile-responsive at 375px
• An unpublished page returns 404 when accessed publicly
• Custom CSS in <style> tags renders on page without XSS or selector conflicts
• SEO meta description appears in page preview and in <meta> tag of HTML source
• Page with image block shows image after upload or URL entry; broken URLs show alt text
• Analytics show exact form submission count and match number of records created in subscribers table
• A/B test metrics show which variant has higher form submission rate

Risks

XSS in custom CSS: user-supplied CSS can inject payloads; sanitize on save. Slug collision: unique slug enforcement needed. Mobile rendering: test at actual viewport sizes, not just preview. Form submission loss: implement retry logic and logging. Analytics accuracy: implement session deduplication to avoid inflating view count. Template initialization: validate template structure on load. A/B test traffic split: avoid rounding to 0 or 100; set explicit min threshold.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.