Back to blog

Lovable vs. Claude Code: Why I Rewrote a React Site to Plain HTML

Lovable generated 90+ files, 67 dependencies and over 12,000 lines of code. For a simple landing page. Claude Code rewrote the whole thing into 4 files and 2,295 lines in a matter of minutes. Both tools are good. But each one for a different job.

Key takeaways:

  • Lovable generated 90+ files and 67 dependencies for a simple landing page
  • Claude Code rewrote it into 4 files with 0 dependencies, scoring 100/100 in PageSpeed
  • For static websites, a framework is unnecessary complexity — it slows loading and hurts SEO
  • AI tools are great, but you need to pick the right tool for the specific job

What this is about

Most AI tools today can generate a website in minutes. Write a prompt, click, and you're done. But very few people stop to ask whether the result is unnecessarily complex.

This is the story of how I used one tool to create a website that worked but was massively over-engineered under the hood. And how I used a different tool to achieve a better result with a fraction of the code.

The brief

I needed a landing page for 3DCap, our algorithmic trading company. Nothing complicated: hero section, service descriptions, process overview, FAQ, Calendly contact widget, and two language versions (Czech and English). No dynamic data, no backend, no complex interactions.

What Lovable created

Lovable spun up a project in seconds. At first glance, it looked great. Dark design, modern cards, responsive layout. Everything worked.

Under the hood, however, Lovable had built a full-scale application with dozens of libraries, a translation system, and complete infrastructure meant for complex web projects. Its standard approach, applied to every project regardless of whether it's a simple presentation or a complex application.

The result? Over 90 files, 67 libraries, and 12,400+ lines of code. For a page that displays static text and a few images.

What followed were 50+ iterations. Tweaking content, colours, and layout. Each change was slower than it needed to be, because it went through the entire machinery. Editing a single heading meant changing it in three places and rebuilding the whole project.

Why rewrite

Two main reasons: SEO and speed. The Lovable version was shipping a massive amount of code to the browser before the page could even appear. For a landing page you want to rank well in search, that's a problem. On top of that, running plain HTML is vastly simpler and cheaper than an application that requires a build step and a special server environment.

The rewrite with Claude Code

I opened Claude Code, gave it the project context and said: "Rewrite this to plain HTML and CSS, no framework, keep the design and both language versions."

Within a few prompts, Claude Code:

  1. Analysed the entire application, components, styles, translations, layout
  2. Deleted all 90+ files
  3. Created 4 files from scratch: two HTML pages (CZ/EN), one CSS file, and 60 lines of JavaScript for animations
  4. Simplified deployment, just upload files to a server
  5. Preserved the complete design including effects, animations, and layout

No incremental refactoring. A clean rewrite with an understanding of what the site actually needed.

The numbers

Rewrite results: From 90+ files to 4. From 67 libraries to zero. From 12,400 lines of code to 2,295. And the site loads in under a second.

Metric Lovable Claude Code
Files 90+ 4
Dependencies (npm) 67 0
Lines of code 12,400+ 2,295
PageSpeed score 100 / 100 / 100 / 100
First Contentful Paint 0.8 s
Total Blocking Time 0 ms
Deployment Build + Node.js server Upload files

Google PageSpeed Insights: 100 out of 100

The rewritten site achieved a perfect score in Google PageSpeed Insights. 100 points across all four categories: performance, accessibility, best practices, and SEO. Even when simulated on a slow mobile connection.

Google PageSpeed Insights — comparison of Lovable vs Claude Code results
Results comparison in Google PageSpeed Insights

Key metrics for the rewritten version:

  • First Contentful Paint: 0.8 s. The page starts rendering almost instantly
  • Largest Contentful Paint: 0.8 s. Main content visible in under a second
  • Total Blocking Time: 0 ms. The browser doesn't have to wait for any JavaScript
  • Cumulative Layout Shift: 0. Nothing jumps around while the page loads

Zero waiting. Zero layout shift. On an emulated slow mobile connection. The Lovable version can achieve good results, but it requires significantly more optimisation and trade-offs, because the foundation it runs on alone is larger than the entire rewritten site.

Why this happened

Lovable isn't a bad tool. It did exactly what it's designed to do: generate a modern web application. The problem is that a landing page doesn't need an application.

The page doesn't need to remember anything. No forms (Calendly is an embedded widget). No dynamic data. No page-to-page navigation, it's two HTML files. For this type of site, the whole complex system is an unnecessary layer that slows down loading and adds complexity.

A few concrete examples:

  • FAQ section: Lovable used a dedicated library for it. But HTML has a native <details> element that does exactly the same thing, without a single line of JavaScript
  • Two languages: Lovable deployed a translation system with dictionaries and language detection. The HTML solution? Two files, index.html and en/index.html. Done
  • Animations: Lovable needed a complex system for them. The plain version handles it in 20 lines

When a framework does make sense

I don't want to be unfair. There are situations where React or another framework is the right call:

  • Stateful applications like dashboards, admin panels, e-commerce with shopping carts
  • Heavy interactivity such as filters, real-time updates, forms with validation
  • Team development where components and type systems help maintain consistency
  • Rapid prototyping, Lovable is excellent for having a working prototype within an hour so you can validate an idea

But a framework isn't the default for everything. And that's exactly the mistake most AI tools make. They use a single approach regardless of context.

The takeaway

AI tools for generating websites are incredible today. Lovable gives you a working prototype in minutes. Claude Code is primarily a tool for developers, but it's getting easier to use and I'd recommend giving it a try even if you're not a programmer. It handled the entire rewrite in a matter of minutes.

Automation isn't about adding another tool. It's about removing unnecessary layers.

From 90 files to 4, from seconds of waiting to instant loading. Neither tool is bad. But if your site doesn't need application logic, you're paying for complexity that gives you nothing in return. Slower loading, worse search rankings, higher hosting costs.

This is exactly the kind of technology decision I make in companies every day. Finding the simplest solution that delivers the biggest impact. Does any of this sound familiar?

  • Parts of your workflow are still unnecessarily manual
  • You have more tools than results
  • You've automated something, but the result is complex and hard to maintain
  • You're not sure how to use AI effectively without creating more work

If you're asking yourself how to do more with less, automate routine steps, or make better use of AI without unnecessary complexity, I'd be happy to walk through your processes and propose a solution that's technically simpler, commercially effective, and ready for growth.

Book a free call about your automation