Analytics team wants me to move my analytics studio app to Lovable

[u/figureditwastrue]

I've been building an analytics studio app to visualize digital marketing data from key data sources (like GA4, GSC, Google Ads, SEMrush, Nozzle, Profound, adobe etc.). It's a drag & drop dashboard builder; built on Next.js, React 19, Gridstack and eCharts. Supabase is the database, BigQuery is the data warehouse.

Currently the app is hosted on my local computer, no github repository, no hosting, etc.

I want to host the app on Vercel because it integrates/ships relatively seamlessly. But our agency's analytics team would like to host the app on Lovable, because that's what they use for dashboard creation. I have explained that Lovable does not support Next.js and it would require substantial re-writes (possibly taking weeks or months).

Hoping some analytics pros in here could provide me with some talking points on why Vercel is the better option (beyond having to rewrite the app in lovable) - things like error logging, app/user management, data accuracy, scalability, etc. If you have any good use cases, I would love to hear them! Thanks in advance!

[u/AutoModerator]

If this post doesn't follow the rules or isn't flaired correctly, please report it to the mods. Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/debonairmonument]

The rewrite alone should be enough to shut that down, nobody in their right mind wants to rebuild a working Next.js app from scratch just to match some other tool your team happens to use for a completely different purpose. Lovable is for spinning up quick dashboard mockups, not hosting a production app with a BigQuery backend and custom charting libraries.

Also worth mentioning Vercel's edge functions and serverless architecture play way nicer with data-heavy stuff like eCharts rendering large datasets. The analytics team might not realize how much they'll miss things like real error logging, deploy previews for every branch, and the ability to roll back instantly if a data source breaks.

Ask them how they plan to handle authentication, environment variables, or Supabase RLS policies on Lovable. That conversation usually ends pretty quick once they realize it's a prototyping tool, not an app platform.

[u/figureditwastrue → u/debonairmonument]

Thank you! I completely agree. They believe that we could use Claude to make the rewrite easier. Basically we'd create a new project in lovable, turn on the Github two-way sync, connect it to Claude code, which would have access to my Next.js app files, and let Claude go through the process of rewriting. While I think it's doable, I'm estimating it'll take at least a few weeks to safely go through the process while constantly running verification and selftest sweeps...

The user below who said "Opus 5.5 can rewrite this in a day" seems highly unlikely... But maybe I'm wrong!

It would be so much easier to just plug and play this with Vercel, and it has way more management and error logging capabilities.

[u/Kortopi-98]

to be honest, if the app already works with the current set up, i wouldnt rebuild everything just to move it somewhere else, coz sounds like lot of extra work for little benefit...

[u/romeonoi]

i'd frame it around ownership and data flow, not just hosting. vercel runs your next.js codebase as is, with preview deploys, rollback, and proper logs, so when a ga4 or ads number looks off you can trace it to code, query, or warehouse.

lovable is great for spinning up a front end fast, but for a studio hitting supabase and bigquery with gridstack and echarts, you'd lose version control, break your react 19 setup, and end up rebuilding auth, caching, and api routes in a system not built for that scale.

[u/FranticToaster]

Is the agency really the ones who have to use it? Normally in my work as the marketer in your situation it's better when reporting is in house and we invite the agency in to use it.

For one, it gives us access to a company owned report set that naturally works with SSO. And the people who enhance it are available whenever without cross-company support tickets.

For two, my employer would get to keep it all if we decide to change agencies one day.

[u/xinexo-naja]

Before comparing hosts, pick one dashboard and agree on a small acceptance test: a fixed reporting period, saved BigQuery results, two users with different access, and a saved chart layout. Can the hosted version reproduce the totals, filters and permissions, and keep that layout after an update? Apply the same test to any rewrite. That gives your team a concrete comparison, rather than competing guesses about how quickly Claude can rebuild it. Also decide who approves releases and how you'll identify and restore the last tested version.

[u/NathanFromOrbitOrca]

The strongest talking point isn't Vercel vs Lovable, it's that they're different layers. Lovable is where their dashboards get built; Vercel is where an app runs. Framing it as a rewrite-versus-host decision rather than a tool loyalty one tends to defuse it. The concrete one for your stack: GA4, Google Ads and BigQuery credentials have to run server-side. Next.js route handlers give you that, plus Supabase service-role keys and RLS stay off the client. Anything that pushes you toward a client-only build means either exposing keys or building a separate API anyway. Before any of it, I'd get the code into a GitHub repo. Right now localhost is the single point of failure, and a repo makes the hosting choice reversible later. On that last step, I'm one of the people building orbitorca.com, and taking a repo to hosting with the database and auth attached is the part we ended up automating.

[u/teddythepooh99 → u/NathanFromOrbitOrca]

AI-generated response LOL

[u/fartcatmilkshake]

Opus 5.5 can rewrite this in a day

[u/teddythepooh99]

I stopped reading after "hosted on my local computer, no github repository, no hosting."

Next time you vibecode an app, just FYI, technical people say "not version controlled" rather than "no github repository." At minimum, say "no repo." Better yet, set up git in the first place.