Lovable helped us build the Queuey website. Then, when we hit a limitation in how the site was being published, Lovable effectively told us:
This part is not going to work here. Use something else.
So we did.
This weekend, we moved the publishing layer of queuey.ai to Cloudflare, with GitHub in between.
And within two days, crawler traffic appears to have increased by roughly 100x.
If anything, the whole process made us like both Lovable and Cloudflare more.
It started with a boring SEO problem
The Queuey platform itself is not built in Lovable. Lovable is used for our public website, where it has been a very effective way to build, change and experiment quickly.
The problem appeared when we started looking more closely at how our articles were seen by crawlers.
Open an article in a browser and everything looked perfect.
But the site was a single-page application. The initial response could contain the generic application shell, while JavaScript rendered the actual article afterwards.
Humans got the article.
Some crawlers got the shell.
And crawlers are no longer just Googlebot. They can be AI search engines, LLMs, coding agents or other machines trying to understand what Queuey does.
We wanted something much simpler:
Ask for an article. Get the article.
So we built pre-rendering.
During the build, static versions of our articles were generated as:
dist/articles/<slug>/index.html
Title, metadata, structured data, article content. Everything was there.
Except there was a catch.
The HTML existed. The internet just couldn't reach it.
We tested the live site.
Even when requesting the generated article file directly, Lovable's hosting layer still returned the SPA shell.
The pre-rendered article had been built.
It had been deployed.
It just wasn't being served.

And this is where Lovable deserves real credit.
It didn't keep inventing increasingly creative fixes for something the underlying hosting layer simply wasn't going to do.
It tested the live result and gave us the answer:
The dist/articles/<slug>/index.html files are being deployed but never served.
That was it.
The pre-rendering wasn't broken.
The hosting behavior was the constraint.
One quality we value in AI is knowing where its own limits are.
Lovable did.
Instead of giving us another confident workaround, it told us where the boundary was.
That saved us time.
So we moved publishing to Cloudflare
The new setup is simple:
Lovable → GitHub → Cloudflare
Lovable is still a big part of how we work on the website. It gives us speed, and speed matters when you are constantly testing messaging, pages and ideas.
GitHub gives us a clean handoff between what we build and what gets deployed.
Cloudflare now handles the publishing layer.
And Cloudflare is extremely good at exactly this job: giving us control over what happens between a request hitting queuey.ai and the right content being returned.
If we generate a pre-rendered article, we can serve the pre-rendered article.
Simple.
And the effect was almost immediate.
In the first two days after the move, we have seen roughly 100x more crawler traffic hitting queuey.ai than before.
Two days is too early to call that a victory, and crawler traffic is not the same thing as rankings or organic traffic.
But it is a strong signal that machines are now finding — and reaching — much more of the site.
Which was exactly the point.
The crawler problem exposed a better architecture
SEO was the trigger, but the move solved something else too.
Publishing through GitHub and Cloudflare makes it easier to bring the Queuey website and the Queuey service closer together.
Today they are technically different things.
The website explains Queuey.
The platform is Queuey.
Over time, that distinction should matter less.
Documentation, demos, signup flows, product data and parts of the service can be connected more naturally. Publishing from GitHub gives us more freedom to coordinate those pieces, while Cloudflare gives us a strong layer in front of them.
The goal isn't a prettier architecture diagram.
It is making Queuey feel like one product.
Good tools don't need to do everything
Software platforms often want to own the entire stack.
We don't think they need to.
Lovable is exceptionally good at helping us build and iterate on the website quickly.
Cloudflare is exceptionally good at delivering it with control.
GitHub connects the two.
We moved because crawlers were getting the wrong thing.
Two days later, the early signal says the change mattered.
And the funny part is that Lovable helped us get there.
It helped us build the website fast, then was honest about where its own hosting layer stopped being the right fit. Cloudflare turned out to be excellent at exactly that part.
That feels less like replacing one tool with another — and more like what a good modern stack should look like.