2
3 Comments

We realized we’re spending way too much on Framer for idea validation – so we built our own alternative

Over the last months I noticed something odd in both my side projects and our venture building work. We’re validating ideas quickly, but the tooling around landing pages has quietly become… expensive.

Typical setup for a “quick test”:

  • Framer: $15–30/month
  • Custom domain
  • Forms + integrations

Multiply that by multiple experiments and suddenly you’re spending hundreds per month on pages that might live for 2–6 weeks.

What bothered me even more:
Most of the time, the actual value is just:

  • a fast landing page
  • good SEO defaults
  • newsletter signup (with DOI; which is also a pain to setup)
  • contact form
  • multilingual

So over Christmas I tried something different.
I built a reusable landing page blueprint for myself using:

  • Astro (fast, static, SEO-friendly)
  • Netlify (free hosting)
  • simple contact form (Brevo) + spam protection (Turnstile)
  • newsletter handling
  • i18n baked in

What really changed the equation for me was pairing this setup with AI tools like Cursor / Codex.
Instead of starting from a blank page every time, I can:

  • adapt copy and sections directly inside the codebase
  • generate new pages (e.g. blog posts, landing variants) from a structured prompt
  • extend or tweak components

The template already handles the “boring but critical” stuff (forms, spam protection, i18n, legal pages), so AI can focus on content and structure, not wiring.
I even added small agent guides and a first-prompt example in the repo, so the AI knows how the project is structured and how to work within it.

The result feels less like “coding a landing page” and more like assembling and refining one — fast, repeatable, and brand-consistent.

So far it’s been:

  • essentially zero recurring cost
  • faster than starting from scratch
  • more control than Framer — without losing speed

This isn’t a product yet.
Right now it’s just something I reuse internally.

But it made me curious:

  • How do you handle landing pages for early experiments?
  • Framer / Webflow despite the cost?
  • Custom code every time?
  • Something reusable?

And an honest follow-up question:

If a reusable, production-ready landing page setup saved you a few days and recurring costs — would you pay once for it, or would you expect this to stay free?

on December 30, 2025
  1. 1

    This resonates a lot. We went through the same realization when validating multiple ideas - the subscription costs for "temporary" landing pages add up fast.

    For early experiments, we've settled on a hybrid approach: Astro + Cloudflare Pages for anything that needs to stick around, but we've also been exploring AI-powered landing page generation for ultra-quick tests. The key insight you nailed is having that reusable foundation so you're not rebuilding forms, i18n, and legal pages every time.

    To your follow-up question - I'd absolutely pay once for a production-ready template if it handles the annoying stuff (DOI flows, spam protection, multi-language). The friction isn't really "can I code this" but "do I want to spend 2 days on plumbing instead of validating the idea." A well-structured template that plays nice with Cursor/AI agents would be worth it.

    What's your i18n setup like? That's usually where things get messy with static site generators.

    1. 1

      Thanks for the detailed note — agree on the “plumbing tax.” On i18n: this template keeps it simple and explicit. de is the default at /, en lives under /en/. Routes are fixed in routeMap.ts, and i18n.ts handles locale prefixing + safe alternates.
      Copy is split per locale, UI strings live in ui.ts, and there are parallel Astro pages under src/pages/ and src/pages/en/ with localized slugs for legal/confirmation pages.

      It’s intentionally non-magic: predictable, easy to diff, no runtime translation layer.

      1. 1

        The "intentionally non-magic" approach is underrated. I've seen too many i18n frameworks where the abstraction is so thick you can't debug routing issues without diving into library internals.

        Parallel page structures (src/pages/ and src/pages/en/) sounds like more upfront work but way easier to reason about long-term. And it means AI tools can just copy/modify files without needing to understand a complex translation runtime.

        The routeMap.ts pattern is clever - having a single source of truth for routes that's also easy to diff. Does it play well with Astro's content collections, or do you keep those separate?

Trending on Indie Hackers
I'm a lawyer who launched an AI contract tool on Product Hunt today — here's what building it as a non-technical founder actually felt like User Avatar 150 comments A simple way to keep AI automations from making bad decisions User Avatar 63 comments “This contract looked normal - but could cost millions” User Avatar 54 comments Never hire an SEO Agency for your Saas Startup User Avatar 53 comments 👉 The most expensive contract mistakes don’t feel risky User Avatar 41 comments I spent weeks building a food decision tool instead of something useful User Avatar 28 comments