Lovable, Figma Make, and the Rise of Instant Websites — So Why Would Anyone Go Headless?

I built this site using AI tools. That's not a confession — it's context.

I used Cursor to write code, AI to generate copy drafts, and leaned on modern frameworks the whole way. It was faster than any site I've built before, and honestly more enjoyable. So when I talk about AI-powered site builders, I'm not doing it from a place of skepticism. I've been on the inside of this shift.

But I've also managed web at JFrog, Okta, and DocuSign. I've inherited CMS platforms that were held together by institutional knowledge and prayer. I've sat in rooms where migrating a single content type took six months of engineering time. So when the question comes up — why would anyone invest in headless infrastructure when you can launch a full site in minutes? — I think I'm in a decent position to give you an honest answer.

The short version: both are right, depending on what you're actually building.

What We Mean by "Websites in Seconds"

A new category of AI-first tools has emerged that genuinely changes what's possible for someone without a development team. I want to give each one an honest look, because they're not all the same.

Lovable is probably the one getting the most attention right now. You describe what you want — in plain language — and it generates a working React app with Supabase on the backend. It's impressive. The output is real code you can deploy, and for founders or small teams who need to move fast, it's genuinely useful. The limitation is what happens after you launch: making targeted changes, maintaining consistency, and scaling the content gets messy quickly if you're not a developer.

Base44 sits in similar territory — AI-generated full-stack apps, fast. It's particularly good for internal tools and early-stage product prototypes. Where it gets complicated is the same place Lovable does: when your needs outgrow the initial generation and you need to start customizing or integrating with your existing stack.

Figma Make is a different animal and, I think, the most interesting one for design-forward teams. If you're already doing your design work in Figma, the ability to push that directly to a live site is genuinely compelling — especially for campaign landing pages and marketing moments where speed matters and the design already exists. The tradeoffs are real though: it works best for relatively contained use cases, not for a site that's going to grow and evolve with editorial workflows.

A few others worth knowing: Framer has carved out a strong niche for marketing sites that need a designer's touch without heavy engineering. Bolt.new (StackBlitz's entry) is popular with developers who want to prototype fast. Durable is targeting small business owners who just need something live immediately. Wix AI and Squarespace AI have added generation features, though they're more template-guided than fully generative.

Where These Tools Genuinely Shine

I want to be clear: I think these tools are good, and I think the people dismissing them haven't actually used them.

Here's where they work well:

• MVPs and proof-of-concepts. If you're testing whether an idea is worth investing in, nothing beats getting something live fast. The cost of a bad architectural decision is low when you're still figuring out if the thing should exist at all.
• Campaign landing pages. One-off pages that need to look great, convert, and then possibly go away. Perfect use case.
• Solo founders and small teams without engineering resources. If you're one person with a business idea and no technical co-founder, these tools are the difference between launching and waiting.
• Internal tools and prototypes. The audience is small, the stakes are lower, and iteration speed matters more than governance.
• When time is the constraint. Sometimes "good enough and live" beats "perfect and three months away."

I used AI extensively to build my own personal site, and I'd do it again. The speed was real.

Where They Fall Apart

This is the part of the conversation that doesn't get enough airtime, so I want to be specific.

Content governance. The moment you have more than one person updating a site, you need a system. Approval workflows, version history, role-based permissions, the ability to schedule a publish without someone being at a keyboard — AI builders generally weren't designed for this. It's not that it's impossible, it's that you'll be fighting the tool instead of working with it.

Compliance. CCPA, GDPR, cookie consent, accessibility requirements — these aren't optional, and they're not trivial to retrofit. Enterprise-grade CMS platforms have been building compliance tooling for years. With AI-generated sites, you're often on your own to figure out how the privacy layer works, who owns the data, and how to handle a data subject request.

Integration complexity. A modern B2B website doesn't live alone. It needs to talk to Salesforce, HubSpot, Marketo, your data warehouse, your CDP, your customer portal. This is where the gap between "generated a nice site" and "runs a web ecosystem" becomes very apparent, very fast.

Scale and performance at the enterprise level. Thousands of pages, multiple locales, complex navigation taxonomies, A/B testing programs, personalization — the tools that make spinning up a site fast weren't built with this surface area in mind.

Multi-channel content. This is the one that I keep coming back to. If you're thinking seriously about AEO and AI agents — and you should be — your content needs to exist as structured, queryable data, not just as rendered pages. Headless architecture was designed for this. AI-generated sites, largely, were not.

The Case for Headless (And When It Actually Makes Sense)

Headless CMS — Contentful, Sanity, Hygraph, Storyblok, Prismic — separates where your content lives from how it gets displayed. Your content is stored as structured data via an API, and any frontend (your website, a mobile app, an AI agent, a partner portal) can query and display it however it needs to.

That architecture matters for a few specific reasons.

Webflow sits in an interesting middle position here — it's not truly headless, but it's not a traditional CMS either. It gives design teams a lot of control without requiring engineers for every change, and its CMS API lets you pull content programmatically. For a mid-size marketing site with a design-forward team, it's often the right call. I've seen it work well at that layer. Where it struggles is at genuine enterprise scale — large content volumes, complex workflows, and deep integrations start to strain it.

Contentful is where I've spent a lot of time personally. It's the right choice when you have a large team, multiple frontends consuming the same content, and real compliance requirements. The content modeling is powerful. The workflows are built for teams. And the API is mature enough that your engineers will be comfortable with it. The tradeoff is cost and complexity — it is not cheap, and it is not simple to set up well.

Sanity is what I'd recommend to someone who wants the power of headless without the rigidity of Contentful's opinionated structure. The content lake model is genuinely flexible, and the developer experience is excellent. It's my pick for teams who know they'll need to evolve their content model over time but don't want to be locked into a schema they made in year one.

The honest tradeoff with headless: you need engineering resources, you'll take longer to launch, and the upfront investment is real. If you don't have those resources, headless is not the right answer — regardless of how much I like the architecture.

The Framework I Use to Actually Decide

When someone asks me which tool they should use, I try to get them to answer a few questions honestly before we look at any specific platform.

Are you building a product or a project? A project has a launch date and a relatively stable scope. A product evolves continuously, has multiple stakeholders, and serves different audiences over time. Projects can live in simpler tools. Products need infrastructure.

How many people will be updating this thing? One person, maybe two — almost any tool works. A team of ten across marketing, legal, HR, and engineering — you need governance, workflows, and permissions. That rules out most of the instant-site category.

What does this site need to connect to? If the answer is "just a form and an analytics pixel," you have a lot of options. If the answer is "Salesforce, HubSpot, our data warehouse, and three third-party tools," you need to think carefully about the integration layer from day one.

How long does this need to last? If the answer is six months for a campaign, pick the fastest thing you have. If the answer is five years and multiple redesigns, the content architecture you choose now will either save or haunt your future self.

Does your team have engineering capacity? Headless requires engineers who understand APIs and frontend development. If that's not available, a visual builder with a CMS layer — Webflow, Framer, even a well-configured WordPress — is often a better fit than a technically superior but unsupported headless setup.

Where This Leaves Us

I don't think these categories are at war with each other. I think the honest answer is that the web tooling landscape has finally given us real options at every level, and the hard part now is matching the tool to the actual need rather than picking whatever is newest or whatever worked at your last company.

The AI builders are genuinely impressive and genuinely limited. Headless is genuinely powerful and genuinely complex. Webflow sits in a useful middle — enough control for most, not enough for some.

What I'd tell anyone figuring this out right now: be honest about where you are, not where you want to be. The best architecture is the one your team can actually maintain and build on. Start with the simplest thing that meets your real requirements, and leave room to evolve.

The tooling will keep maturing. And honestly, that's the part I find most interesting — we're not done yet.