Lovable drastically shortened the time between a decision and a working page on our own website. What it didn't do was make sure the site could be read by search engines and AI crawlers, that analytics actually recorded visits, or that the English and Spanish versions showed English and Spanish content. That was our job, and some of it only surfaced months after launch.
This is an account of how we used the tool, problems included. It's meant for anyone evaluating AI app builders for a company website, a landing page, or an internal product.
Why we used Lovable
We build websites, platforms, and systems for clients. When it was time to rebuild our own, with a new visual identity and content that reflected what Cortex IQ actually does, the project had the classic fate of internal work: it always slipped to next week.
Lovable is a web app builder where you describe what you want in natural language and an agent writes and edits the code. The tool was called GPT Engineer before it rebranded (Lovable), which is why the commits it generated in our repository are signed "gpt-engineer-app[bot]."
The output is an ordinary React project: Vite, TypeScript, Tailwind CSS, and shadcn/ui components, with a database and backend functions through Supabase, offered inside the platform as Lovable Cloud. It is not a black box. The project syncs with GitHub in both directions (Lovable Docs), so you can open the code in any editor and work on it outside the tool.
What we built
This was not a landing page: company pages, service pages, offer pages built from a single data-driven template, case studies, a blog, forms that write to the database and send email, a cookie banner that only enables Google Analytics 4 after consent, and three languages (Portuguese, English, and Spanish).
What worked was treating Lovable as a fast developer who needs a precise brief. Every request spelled out the stack, the exact color tokens, the component hierarchy, the form pattern, and the internationalization rules. The more explicit context, the less rework.
Where we had to step in at launch
Three things needed someone hands-on in the code or rewriting the request:
- Visual identity on one offer. One of the offer pages came out with a different visual theme from the rest of the site. We fixed it with a detailed override prompt. Lesson: if the identity is specific, it has to be written into the request, not implied.
- Files for search engines. Generating the sitemap from the content files took hand-written code. Tasks tied to the build process are still better handled by a developer.
- Dependency conflicts. Incompatible library versions broke the build more than once. That's the pace of the JavaScript ecosystem, not a flaw in the tool, but someone has to catch it before publishing.
What surfaced after launch
This section was added in September 2026, with the site a few months in production. It's the most useful part of the account, because none of these problems show up in the preview.
Everyone was reading Portuguese. The offer, case study, and RÜNARA pages showed Portuguese text even when the URL said /en-us or /es-es. The menu switched language, the main content didn't. Nothing looked broken, so it went unnoticed until a file-by-file review.
Analytics recorded nothing. The code loaded Google Analytics by injecting the script dynamically after consent. The data layer showed the right events, but no request ever reached Google. We fixed it by switching to the static tag in the HTML, with configuration still gated on consent, the same pattern already working on two other sites we host on Lovable. We also found that, because this is a single-page app, navigating between pages didn't fire a page_view, so we now record every route change.
AI crawlers saw an empty page. This was the serious one. The site rendered entirely in the browser: all 84 sitemap URLs returned the same empty HTML shell, and content appeared only after JavaScript ran. Google renders JavaScript in a step after crawling (Google Search Central), but an analysis by Vercel showed that none of the major AI crawlers, including GPTBot and ClaudeBot, execute JavaScript (Vercel, 2024). If you want to be cited by ChatGPT, Claude, or Perplexity, that's the same as having no site. The fix was a prerendering step in the build that writes static HTML with content, title, and structured data for every route.
Our local code fell 23 commits behind. Because Lovable and GitHub sync on the main branch, edits made directly in the Lovable editor and edits made locally diverged. Reconciling them meant resolving conflicts file by file. The rule now is simple: each change starts in one place only, and whoever starts syncs first.
None of these problems is unique to Lovable. They're common to any single-page app built in a hurry. The difference is that the tool's speed gets you to them faster and, sometimes, gets you to publish before you notice.
What we'd do differently from day one
Knowing what we know now, three decisions would have come before the first screen.
- Prerendering or server-side rendering from the start. Fixing it later meant touching the build, the routing, and parts of the code that accessed browser APIs on load. It would have been cheaper to start that way.
- A written rule on where changes happen. The 23-commit divergence required a file-by-file reconciliation that a two-line agreement would have prevented.
- A simple automated test in the build that opens every route in every language and checks that the main content is in the right language. The language bugs would have been caught on day one, not months later.
None of these decisions depends on the tool you pick. All of them depend on someone asking the right questions before requesting the first screen.
Checklist before publishing an AI-built site
- Open the page source (not the browser inspector) and check that the main text is in the HTML. If it isn't, AI crawlers won't read it.
- Change the language in the URL and read the content, not just the menu.
- Accept cookies and check GA4's realtime report for your visit. Then decline and confirm nothing is sent.
- Navigate across three pages and check that each one records a view.
- Paste each key page's link into LinkedIn or WhatsApp and check the title, description, and image.
- Validate the sitemap: every listed URL should exist and serve content in the declared language.
- Decide where changes happen, in the Lovable editor or in the repository, and write it down.
Who it's worth it for
It's worth it if you know exactly what you want to build, have someone who can read the generated code, and have at least a basic design system to anchor it. Without clear scope, any tool just produces the wrong result faster. Without a technical reviewer, the problems above only show up when the traffic doesn't.
The split we ended up with is the same one we recommend to clients: the tool generates, people decide, verify, and answer for what goes live. If you're weighing this route for your company's site or product, see the projects we've delivered and how we work on apps and digital products.