DEV Community: Geminate Solutions

IoT App Development Cost: What Drives It in 2026

Geminate Solutions — Mon, 07 Sep 2026 12:16:15 +0000

What actually sets the budget on an IoT build, from a single-device monitor to an industrial platform, broken down by device count, real-time depth, and hardware surface. Written by the team that runs a GPS system tracking 30,000+ vehicles in real time.

Three things set the budget on an IoT build, and the dashboard isn t one of them.

Device count and message rate. Fifty sensors reporting hourly is a weekend problem. Thirty thousand trackers reporting every ten seconds is an architecture problem. Message volume, not feature count, sizes the whole system.
How much has to be real time. Storing a reading and charting it later is straightforward. Running geofence math and pushing a live map fresh within milliseconds under load is the part that demands real architecture, and on a fleet platform it can take a fifth to a third of the build.
The hardware surface. One off-the-shelf board speaking MQTT is fast. Three protocols, custom firmware, field provisioning, and over-the-air updates that must never brick a device is a different project. Effort follows those three. A single-device monitoring app is 8 to 12 weeks with two or three engineers. A multi-device fleet platform is 3 to 5 months with three or four. An industrial system with predictive maintenance is 6 to 10 months with five to seven, plus DevOps and QA. Add 3 to 4 weeks on top for hardware and protocol testing, because physical devices misbehave in ways you can t reproduce in code. Scope those honestly and the number follows. We ll scope yours and come back with a straight answer, usually within hours.

Skip the guesswork and scope your actual IoT build.

Everything on this page comes from IoT work we ve actually shipped, including the Pixytan GPS platform that tracks 30,000+ vehicles in real time. What you won t find here is a price table, because a number pulled off a web page is worthless until someone has looked at your devices, your message rate, and what has to happen the moment a reading crosses a threshold. What you will find is the honest anatomy of where the money goes on a connected-device build, so you can sanity-check whatever estimate you re holding.

Here s the one thing that makes IoT different from a normal web or mobile build. You re writing software that talks to physical hardware. So you also carry firmware integration, network connections that drop without warning, provisioning thousands of devices in the field, and a real-time pipeline that simply can t stall. Every one of those is engineering a standard app project never sees, and every one of them is why two IoT projects with identical-looking dashboards can differ threefold in effort.

We ll scope your project properly and hand you a straight answer, usually within hours. You own the code outright, a senior team builds it, and there s no agency overhead padding the invoice. We ll never tell you we re the cheapest. We ll tell you the number is honest and the work is worth it. Your number comes from a quick scoping conversation, privately and fast, which is the only place a real one can come from.

IoT Complexity Tiers and What Sets Them Apart

What Actually Drives an IoT App s Cost?

Two IoT projects with the same dashboard can differ threefold in effort. The budget is set by what the fleet does, not by how the screens look. Here is what moves it, in rough order of impact.

Device count and reporting frequency. This is the master variable. A hundred devices reporting hourly and thirty thousand reporting every ten seconds are different engineering problems, not the same one scaled up. Broker tuning, database sharding, and queue backpressure only become real work past a certain message rate, and once they do they never stop being work.
How much of the pipeline is real time. Ingesting readings and charting them tomorrow is straightforward. Taking location updates from thousands of devices, running geofence math, and keeping a dashboard fresh inside a few milliseconds is the heaviest single block on most fleet platforms. Plan for it to take a fifth to a third of the build if your product is live-view first.
The protocol and firmware surface. One off-the-shelf board speaking MQTT is quick. A site running MQTT, Modbus, and OPC UA at once needs a translation layer, and that layer is often the largest integration in an industrial build. If firmware has to change, add the board revision cycle to your timeline too.
Field operations. Provisioning, certificate rotation, over-the-air updates, and remote diagnostics rarely appear on a wireframe and quietly add weeks. They re also the difference between a pilot and a product, because a fleet you can t update in the field is a fleet you ll be driving to.
Offline and reconnection behaviour. Devices drop off the network constantly. Tunnels, rural dead zones, power cuts. Buffering on the device, deduplicating on arrival, and healing the timeline afterwards is unglamorous engineering that decides whether your data is trustworthy.
Non-functional requirements. HIPAA for patient monitoring, ISO 27001 for enterprise, audit trails on device data, and physical security of the devices themselves. These never show on a demo and always show on the invoice.
Team seniority. An engineer who has held a production IoT system up at scale reaches for the right broker configuration the first time. That s cheaper over the life of the project than a cheaper team whose architecture you pay to replace at ten thousand devices. Timeline tracks the same factors. A simple monitoring app lands in 8 to 12 weeks, a fleet platform in 3 to 5 months, and an industrial system in 6 to 10 months, with 3 to 4 weeks on top for hardware and protocol testing in every case. Off-the-shelf hardware shaves real time off the front of any of those. The sections below walk each tier in detail, then break the drivers down by feature and industry so you can sanity-check whatever estimate you re holding.

What Goes Into a Simple IoT App?

One device type. Temperature sensors, air-quality monitors, a basic GPS tracker. A build like that covers the device communication setup (usually MQTT), a cloud backend that receives and stores the readings, a web dashboard that shows them live, and a push notification the moment a value crosses a threshold you care about. At this tier the engineering is well understood, so the budget is driven by the alerting rules and the reporting, not by the pipeline.

Picture cold-storage monitoring, since it s one of the clearest cases. A single ESP32 sensor in each warehouse unit reports its temperature every 30 seconds over MQTT to a cloud backend. The dashboard shows every unit on one screen, color-coded, and the second one drifts out of the safe band, on-duty staff get an SMS and an email. That whole pattern sits at the light end of IoT work, and we can scope and ship it without much drama. The value isn t in the software being clever. It s in catching the failure before the inventory spoils, which is why the escalation logic deserves more scoping attention than the charts do.

What Goes Into a Medium-Complexity IoT Platform?

Now you re juggling several device types, a real-time dashboard, geofencing, historical analytics, and a mobile companion app. Plan on 3 to 5 months. The team is usually three or four engineers plus a QA person who can test both the software and the hardware integration, because on IoT those aren t the same skill and pretending they are is how pilots fail.

The Pixytan GPS fleet tracking platform is our own example at this tier, and it s the project we lean on when we scope this kind of work. GPS hardware in each vehicle sends a location every 10 seconds over MQTT. The backend processes geofence entry and exit in real time, scores driver behavior off speed and braking, and feeds a web dashboard where a fleet manager watches the whole operation. It tracks 30,000+ vehicles today, and at that volume the MQTT broker is moving millions of messages a day without falling over. Most of what we know about scaling IoT, we learned holding that system up.

Here s the driver nobody budgets for at this tier: the real-time pipeline. Taking location updates from thousands of devices, running the geofence math, and pushing the dashboard fresh, all inside a few milliseconds, is the part that demands real architecture rather than a framework. If your product is live-view first, set aside a fifth to a third of the total effort for the pipeline alone and you won t get surprised. Skimp there and the whole thing feels laggy under load, which no amount of frontend polish will hide.

What Goes Into a Complex Industrial IoT System?

This is the deep end. Predictive maintenance, several device protocols at once, edge computing, ML analytics, and security a compliance team will actually sign off on. An industrial system like this runs 6 to 10 months, with a team of five to seven engineers plus DevOps, an ML person, and QA who understands the domain.

Take predictive maintenance on a factory floor, since it s the case that justifies the top tier. A few hundred CNC machines, each wearing vibration, temperature, and power sensors, reporting over a mix of MQTT and Modbus. The platform pulls in millions of data points a day, runs ML models that flag the anomaly pattern preceding a bearing failure days before it happens, and surfaces it on a dashboard the floor team can read. Edge nodes at each site keep processing locally when the internet drops, which on a factory floor it will. The two things that set the budget here aren t the ML and they aren t the dashboard. They re the protocol translation layer between old machines and modern software, and whether you have enough labelled failure history for a model to learn from. If you don t, the first months are data collection, and that has to be in the plan honestly rather than discovered later.

Custom IoT Platform vs AWS IoT vs Azure IoT Hub

The trade-off, in plain terms. AWS IoT Core and Azure IoT Hub get you live 2 to 3 months sooner and take a real chunk of build effort off the table. Lovely, until you cross ten thousand devices and per-message billing starts to bite, because that meter tracks your fleet while your own infrastructure stays roughly flat. A custom platform costs more effort to build and then quietly earns it back every year at scale. We run Pixytan GPS on a custom stack for exactly that reason. At 30,000+ devices, per-message fees on a managed service would have chewed straight through the margin, so the build paid for itself. Under about five thousand devices, that maths runs the other way and you should take the managed option without guilt. If your devices report into an IoT app builder such as ThingsBoard, Blynk or Losant rather than a raw cloud broker, the ceilings are different again, and our IoT app builder or custom build guide lays them out builder by builder.

What Drives the Budget by Build Scope

IoT carries more weight than ordinary software work, and the reason is simple. It needs firmware and cloud skill in the same heads. A good IoT engineer is comfortable with embedded C on a microcontroller, knows how to tune an MQTT broker, can keep a time-series database fast, and still builds a clean real-time dashboard. That combination is genuinely scarce, which is why the honest scoping question is never how many screens you want. It s how many devices, how often they talk, and what has to happen the moment one of them says something alarming.

How Much Effort Does Each IoT Feature Add?

The feature set, not the screen count, is the real driver. Use the effort below to sanity-check any estimate and to decide what belongs in your first release versus a later one. Each line is roughly additive, so a fleet platform that needs provisioning, a live map, geofencing, and a mobile app stacks those four on top of the base build.

Where Do Companies Waste Money on IoT Development?

Building custom hardware when off-the-shelf works. A custom PCB burns 3 to 6 months in revision cycles before anyone writes application code, and each revision restarts your testing. For most business IoT, fleet tracking, environmental monitoring, asset tracking, you don t need any of it. Commercial GPS modules, ESP32 boards, and industrial sensors do the job off the shelf. Custom hardware only earns its keep at manufacturing volume, or when you genuinely need a form factor that doesn t exist yet.

Over-engineering the pipeline on day one. We see it constantly. A team architects the backend for a million devices and launches with fifty. The million-device version takes multiples of the effort to build and multiples again to run, and it sits idle for years while the roadmap starves. Build for about ten times your launch volume. Rebuild when you actually hit the ceiling, because by then you ll know things about your traffic you can t guess now.

Skipping the device simulator. To test IoT software you need either real hardware on the bench or a simulator that fakes it. A proper simulator is a few days of upfront work and it pays for itself fast, because a developer can reproduce a bug in seconds instead of waiting around for a physical device to misbehave on cue. Teams that skip it tend to spend a third more time chasing bugs in production. We build the simulator early on almost every IoT project for exactly this reason.

Ignoring offline and reconnection. IoT devices drop off the network all the time. Tunnels, rural dead zones, power cuts. If your app doesn t handle that gracefully, you lose data and you spray out ghost alerts that train people to ignore the real ones. Proper offline buffering and reconnection logic is a modest line item upfront. Skipping it costs far more later, in lost data and in the support tickets that follow.

How Do You Choose the Right IoT Development Company?

Push on hardware integration. Building IoT software isn t building a web app with extra steps. Your development partner has to actually know device protocols like MQTT, CoAP, and Modbus, has to respect firmware constraints, and has to be able to debug across the hardware-software line. Ask them to tell you about a time a physical device did something the documentation swore it wouldn t. The answer tells you in about thirty seconds whether they ve really lived with hardware or just read about it.

Check the scale claims. Running 100 devices and running 30,000 are different engineering problems, not the same one bigger. At scale, broker config, database sharding, and message-queue tuning are what keep the lights on. We operate Pixytan GPS at 30,000+ vehicles, and that kind of operational scar tissue isn t something a team can fake in a sales call.

Run a small proof-of-concept first. Spend a couple of weeks on a sprint where the team wires your real hardware to a basic backend and gets data onto a plain dashboard. You ll learn fast whether they can handle your specific devices, protocols, and data formats. That short engagement is the cheapest insurance there is against picking a team that can t carry the IoT complexity, and it has saved buyers from far more expensive mistakes.

Ask how they handle the 2am call. IoT systems need round-the-clock monitoring, because devices don t stop reporting on a Saturday night. Get them talking about alerting, log management, and what actually happens when something breaks. A team that runs production IoT will have those answers loaded and ready. A team that has only built prototypes will improvise, and you ll hear it.

What Drives an IoT Build by Industry

How to Get an Accurate IoT Development Estimate

Want a number you can actually trust? Bring us a few specifics. What devices you re connecting and how many. How often each one reports, because that single figure sizes the pipeline. The protocol your hardware speaks, or a note that you haven t picked hardware yet, which is fine. The handful of data points you really need to watch, and what should happen the moment one of them goes wrong. Your device count at launch and where you think it lands in a year. And any compliance you re bound by, like HIPAA for healthcare or ISO 27001 for enterprise. The more honest you are about the hardware, the tighter the estimate, because the integration is where most IoT budgets quietly blow up. Send us that and we ll come back with a straight answer, usually within hours.

Should You Build IoT With a Partner or In-House?

An IoT build wants two skill sets in the same place. Firmware and hardware on one side, cloud and app development on the other. Standing up an in-house team that genuinely covers both, MQTT, device provisioning, real-time dashboards and all, means recruiting across two disciplines at once, plus a hardware test bench, plus the dead months before anyone ships a line of application code. So the real question isn t which looks cheaper on paper. It s this. Do you want to spend six months recruiting, or do you want to start building next week? If the platform is going to keep growing rather than ship once and stop, building it with a dedicated IoT team is the shape that usually fits.

That s where building with a partner earns its place. We built Pixytan GPS, the fleet platform tracking 30,000+ vehicles with live telemetry, geofencing, and driver-behavior analytics, and those architecture patterns carry straight into other IoT verticals: smart agriculture, industrial monitoring, asset tracking, home automation. We don t rediscover them on your dime. Our team plugs into your workflow, learns your device protocols and your data volumes, and designs for the scale you re actually heading toward. Anyone can write an MQTT handler. The hard part is building the system that holds from 100 devices to 100,000, and that s the part we ve already done.

The engagement also covers more ground than a single hire does. Build with us and one scope covers device onboarding, cloud infrastructure, the real-time pipeline, the mobile app, and the admin dashboard, with senior code review and project management already inside it. Recruit one local IoT engineer and you get one local IoT engineer, who still needs the other half of the skill set sitting next to them. When device reliability isn t negotiable, having a partner whose infrastructure choices are already proven in production is worth paying for.

One thing worth being clear about. Geminate Solutions is a software and product development partner, not a staffing desk. We don t rent you a seat and walk away. We scope, build, and ship the IoT product with you, firmware through cloud dashboard, in your tools and your standups, carrying architecture patterns proven across 30,000+ connected devices. The gap between a web shop that also does IoT and a team that ships IoT for a living shows up in one place: whether it stays reliable once the device count climbs.

Engagement Models for an IoT Build

Fixed scope. The clean choice when you already know your device type, your data points, and what the dashboard needs to do. You agree the deliverables up front and pay against milestones. No hourly tracking, no surprise scope-creep invoice. You get a working system that takes in device data, shows it live, fires alerts, and produces reports. It s the model finance teams like, because they can approve a hardware-inclusive budget without a question mark hanging over it, and the risk of mis-estimating sits with the build team rather than with you.

Iterative. Better suited to work where the hardware keeps moving. Protocols shift. A sensor vendor changes its API overnight. A new board revision needs the software adjusted. This model gives the work room to absorb all that without reopening the contract every time, and you reprioritize the backlog sprint by sprint as the fleet grows. Hardware-software integration is unpredictable by nature, and this shape is built to live with that. Detailed logs, reviewed each week, keep the effort honest and visible.

Dedicated team. For an ongoing IoT platform, a team that builds and maintains the whole stack with you, device onboarding through admin dashboard, as your device count climbs from hundreds into the tens of thousands. It s a partnership that scales with your fleet, not a head you rent by the month. On a scoping call we ll point you to the model that fits your stage: a first pilot usually starts fixed scope, a moving hardware roadmap leans iterative, and a live platform with a growing fleet moves to building with a dedicated IoT team.

IoT App Cost: Frequently Asked Questions

Three things, and the number of dashboard screens is not one of them. First, how many devices are talking and how often, because message volume, not feature count, is what sizes the whole system. Second, how much of the pipeline has to run in real time, since a reading stored every hour is straightforward and a live map that has to stay fresh under load is not. Third, the hardware surface, meaning how many protocols you speak, whether firmware needs touching, and how devices get provisioned and updated in the field. A single-device monitoring app is 8 to 12 weeks with two or three engineers. A multi-device fleet platform is 3 to 5 months with three or four. An industrial system with predictive maintenance is 6 to 10 months with five to seven.

A normal mobile app talks to one API. An IoT app talks to thousands of physical devices at once, and every one of them drops connection, runs a slightly different firmware version, and needs its sensors calibrated. So you also carry device firmware, a protocol layer like MQTT or CoAP, provisioning at fleet scale, and a real-time pipeline that cannot fall behind. That hardware-software layer is real engineering a pure-software build never pays for, and it needs the most testing time, because physical devices throw variables you cannot reproduce in code.

A simple monitoring app takes 8 to 12 weeks. A multi-device fleet platform runs 3 to 5 months. A full industrial system with predictive analytics is more like 6 to 10 months. Add 3 to 4 weeks on top for hardware and protocol testing, because physical devices throw variables you only find on real hardware. Using off-the-shelf gear such as ESP32 boards or commercial GPS trackers shaves real time off the front of the project.

Under about 5,000 devices, AWS IoT Core or Azure IoT Hub is the sane choice. You ship 2 to 3 months sooner and you skip a chunk of upfront build. Past 10,000 devices, or when you need an industrial protocol the managed services do not speak, a custom platform wins, because managed brokers bill per message and that bill climbs with your fleet while your own infrastructure stays roughly flat. We run the Pixytan GPS platform on a custom stack for exactly that reason, and it tracks 30,000+ vehicles in real time.

Three things. Reporting frequency, because a location every 10 seconds across thousands of vehicles is a very different pipeline from one every 10 minutes. Map performance, since rendering thousands of live markers with clustering and history playback is genuinely hard frontend work. And how much derived intelligence you want on top, meaning geofencing, driver scoring, fuel monitoring, route optimization, and predictive maintenance, each of which is its own engineering block.

Four buckets, and only one of them is hosting. Cloud infrastructure, the MQTT broker, and a time-series database scale with message volume, which means they track device count rather than feature count. Alerting through SMS or push is metered per message sent. Firmware updates and security patches arrive every quarter whether you planned for them or not. The one people forget is maintenance, which typically runs a low double-digit percentage of the original build effort each year.

Someone on the build needs to understand firmware, even if it is not a full-time hardware engineer. If you are using off-the-shelf gear such as ESP32 boards, Raspberry Pi, or commercial GPS trackers, a strong software team can handle the integration. The moment you want a custom PCB or a proprietary sensor, you need a real hardware engineer alongside the software side, and you inherit board revision cycles that add months. Most business IoT never reaches that point.

MQTT carries most of it. It is lightweight, it survives bad connectivity, and it holds thousands of device connections at once. CoAP fits tiny, memory-constrained devices better. WebSocket pushes the live updates to the dashboard, and plain HTTP REST is fine for anything that only reports occasionally. Industrial sites add Modbus or OPC UA on top, and that translation layer is often the single heaviest integration in a factory build. The usual shape is MQTT from device to cloud and WebSocket from cloud to dashboard.

IoT wants two skill sets in the same place, firmware and hardware on one side, cloud and app development on the other, and hiring both at once is slow. A partner engagement already absorbs project management, QA, infrastructure, and the hardware test bench. The bigger win is speed, since a partner team ships in week one instead of after a months-long hiring loop across two disciplines. In-house makes sense when connected devices are your core product competency.

Use off-the-shelf hardware instead of a custom board, start on a managed broker such as AWS IoT Core or Azure IoT Hub, build a device simulator early so engineers can reproduce bugs without waiting on physical hardware, and architect for about ten times your launch device count rather than a million devices you do not have yet. Ship one real monitoring loop end to end, get it in front of the people who will actually watch the dashboard, then add predictive analytics and edge computing once the data justifies them.

We scope the platform with you, then build and ship it as a dedicated team rather than a rented seat. Firmware integration, cloud infrastructure, the real-time pipeline, the dashboard, and the mobile companion app sit inside one engagement, along with senior code review and project management. You own the code outright. Geminate Solutions is a software and product development partner, not a staffing agency, and the number for your build comes from a short scoping conversation rather than a table on a web page.

Get a straight answer within hours.

Tell us your devices, your protocols, and what you need to monitor. We ll scope it properly and come back with a clear number and timeline, usually within hours. No slide deck, no sales pressure. You own the code, a senior team builds it, and the team that reads your brief is the team that built the GPS platform tracking 30,000+ vehicles in real time.

★4.9 stars across 24+ client projects, in their words.
→50+ products shipped across web, mobile, and AI.
→10M+ requests a minute on the real-time GPS platform we run. Related: Custom software development | Build with a dedicated IoT team | Real-time GPS platform case study | Fleet management case study | Mobile app development cost | Client testimonials | Interactive cost calculator

Originally published on Geminate Solutions.

Custom Fleet Management Software Cost & Build Guide (2026)

Geminate Solutions — Mon, 07 Sep 2026 12:16:06 +0000

The fleet management market keeps compounding to 2030. What the core features really are, when to build custom vs buy Samsara or Geotab, what EV fleet management takes, and what really drives the build effort.

How Big Is the Fleet Management Software Market?

The global fleet management market is projected to more than double between 2025 and 2030 at 15.32% CAGR (MarketsandMarkets). Cloud-based deployment accounts for 72% of new implementations.

Three buyers push it forward. Commercial operators come first, the trucking, delivery, and logistics crowd. Then municipal fleets, which means government vehicles and public transit. And the newer one we keep seeing show up: corporate EV fleets that need charging optimization built in from day one.

Samsara and Geotab own most of this market. They work fine until the per-vehicle pricing catches up with you, and at scale it always does. So companies running 500 or more vehicles keep coming to us to build custom software instead, the kind that kills the recurring per-vehicle fee for good.

What Features Does Every Fleet Management System Need?

Real-Time GPS Tracking: Position updates land every 5 to 30 seconds, pulled from OBD-II dongles or dedicated GPS hardware. For the map itself Google Maps API bills per thousand requests, and Mapbox bills a fraction of that per thousand. That is roughly 14x cheaper, which matters once a fleet gets big. You also want history playback so anyone can replay a route and verify it.

Route Optimization: This is the shortest or fastest path math, but it has to weigh real constraints. Traffic. Vehicle capacity. Delivery windows. How many hours a driver has left. We tend to reach for OSRM (open source, self-hosted) or the Google Directions API for the routing engine. Done right, custom optimization shaves fuel costs by 15 to 25%.

Driver Management: Digital profiles for every driver, with license expiration alerts so nobody falls through the cracks. You track hours-of-service (HOS) for ELD compliance. You score behavior too, things like harsh braking, speeding, and idle time. And you handle which driver is in which vehicle on a given day.

Geofencing: You draw zones on a map and the system pings you when a vehicle enters, leaves, or just sits there too long. In practice that means arrival alerts when a truck reaches a customer site, a heads-up when someone strays off the assigned route, and a way to catch overtime before it happens. Under the hood it is polygon math on GPS coordinates. We let Turf.js carry that load.

Maintenance Scheduling: Two kinds, really. Preventive, on a schedule, and predictive, based on what the vehicle is actually telling you. You watch mileage, engine hours, and the OBD-II diagnostic codes, then flag service before it turns into a roadside problem. Fleets that do this well cut breakdown downtime by 25 to 35%.

Fuel Monitoring: You read consumption straight from OBD-II data, or from dedicated fuel sensors if you want tighter numbers. The fun part is theft detection. A sudden drop in fuel while the engine is off is a pretty loud signal. From there you can work out cost-per-mile per vehicle, which is the number that actually drives optimization calls.

See our custom software development services →

Should You Build Custom or Use Samsara or Geotab?

Samsara: Bills per vehicle per month, and that price bundles the hardware, GPS, dashcams, and ELD compliance. Honestly, for a fleet under 500 vehicles it is hard to beat. The catch is the math scales in a straight line, so a thousand vehicles multiplies that per-vehicle fee a thousand times over, every month. Customization stays limited, and your data sits in their cloud, not yours.

Geotab: A little cheaper on the per-vehicle subscription, though you pay for the hardware per device on top. Its open API is genuinely strong, so it suits data-heavy operations where you want to dig in. Same trap at scale, though. The per-vehicle pricing still bites. And that API is complex enough that you end up writing real code against it anyway.

Custom Build: A one-time development effort sized by feature depth and integration surface, then a standing monthly line for hosting and infrastructure. There is no per-vehicle fee and you own the whole thing. At 500 vehicles, going custom typically saves 40 to 60% against Samsara over three years. Push past 1,000 vehicles and the gap widens to 60 to 75%.

Decision framework: Here is roughly how we'd call it. Under 200 vehicles, buy off-the-shelf and move on, Samsara or Geotab will do fine. Between 200 and 500, it depends. If you need a specific feature or integration the vendors can't give you, custom starts to make sense. Over 500 vehicles, custom almost always wins on total cost of ownership.

Don't skip the data question either. With Samsara or Geotab, your fleet data sits on their servers. Build custom and it is yours, full stop. That ownership matters a lot to companies that treat their fleet data as a real competitive edge.

One more case. If your trackers already report into an IoT app builder such as ThingsBoard or Blynk rather than a fleet vendor, the decision has a different shape. Our IoT app builder or custom build guide walks it builder by builder, including how to move off one without touching the hardware.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

What Does EV Fleet Management Require?

EV fleets bring their own set of technical headaches, and most off-the-shelf tools handle them badly. Here is what actually has to work:

Charging Schedule Optimization: You are juggling three things at once. Electricity rates, which shift with time-of-use pricing. When each vehicle has to leave in the morning. And how much grid capacity you actually have. Get the algorithm right so 80% of the fleet charges during off-peak hours and you can knock 30 to 40% off the electricity bill.

Range Anxiety Management: Real-time range estimates that account for battery state of charge, the outside temperature, how heavy the load is, the terrain, and how the person drives. Then the routing has to know where the chargers are along the way. For long-haul EV trucks that part is not optional, it is the whole game.

Battery Health Monitoring: Track state of health (SOH) and how fast each battery is degrading, vehicle by vehicle. Once you can see the trend, you can predict when a pack will fall below its usable threshold and swap it out on your terms, not when it strands a vehicle on a Tuesday morning.

Charging Infrastructure Management: You need to know the state of every charger, whether it is free, in use, or faulted, and decide who gets priority in the queue when demand spikes. On top of that, you meter energy per vehicle and roll it up into the reporting your sustainability compliance team keeps asking for.

EV fleet management is still early days. Most of the big platforms treat EV as a bolt-on, a few basic features tacked on after the fact. So the companies investing in real custom EV systems right now are quietly building a moat. Our full-stack developers put these together with Node.js on the backend and Flutter on mobile. Want one looked at? Get a free project assessment.

How Much Does Fleet Management Software Cost to Build?

Three things set the budget, and none of them is fleet size. How many vehicle data sources you have to normalize. How deep the optimization, compliance, and EV layers go. And who maintains the platform once it is live. Here is how those drivers stack up by tier:

Simple fleet tracker (GPS + basic alerts): Figure 2 to 3 months. You get GPS hardware integration, a live map, geofencing, and basic reports. That is plenty for a small fleet that mainly wants to know where its vehicles are. The effort stays small because there is one data feed and no compliance layer to build around.

Mid-range fleet management system: 4 to 6 months. This is the simple tracker plus the parts that earn their keep: route optimization, driver management, fuel monitoring, and maintenance scheduling. You also get a mobile app for the drivers and an admin dashboard for whoever runs the show. What moves the effort here is the routing constraints and how many vehicle data sources you have to normalize.

Enterprise fleet platform: 6 to 10 months. Everything so far, then the heavy stuff. EV support. ELD compliance. Predictive maintenance with a model behind it. Multi-tenant setup if you are a fleet management company serving several clients off one platform. Plus an API so third parties can plug in. Compliance load, the data layer, and multi-tenancy are what separate this tier from the one below it.

Hardware: OBD-II dongles are the cheapest option per unit (we usually spec Queclink or Teltonika). Cellular GPS trackers cost roughly double a dongle. Dashcams with cloud storage are the priciest hardware line. The nice part is hardware is a one-time spend per vehicle, not a monthly drip.

Ongoing costs: The recurring stuff is mostly small. SIM cards for the GPS devices bill per vehicle every month. Google Maps API becomes one of your largest recurring lines on a large fleet, which is exactly why we keep pointing people at Mapbox, at a fraction of the cost. Cloud hosting is a standing monthly line that grows with fleet size.

How Did We Build a 30,000 Vehicle Tracking System?

We shipped a real-time vehicle tracking system handling 30,000+ vehicles. GPS updates land every 10 seconds. It does geofencing alerts, driver scoring, and fuel monitoring on top of that. The thing chews through millions of GPS data points a day and still answers queries in under a second.

See the full case study: Twings, GPS Vehicle Tracking and Fleet Tracking Portfolio.

A few architecture calls did most of the heavy lifting. PostGIS handles the geospatial queries. Redis caches live positions. WebSocket pushes updates to the map in real time. And TimescaleDB stores the time-series GPS history. Put together, it absorbs 10x traffic spikes without breaking a sweat.

Get a free fleet management system assessment →

CEO and co-founder of Geminate Solutions, a software and product development partner. He has led teams shipping custom web apps, mobile apps, SaaS platforms, and AI products that serve over 250,000 daily active users.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Most teams that reach us have a working product and a growing list of things that scare them. We read the code first and tell you what actually needs fixing, including the parts that do not. Rebuilding from scratch is rarely the honest answer.

Lovable Backend Solutions: What You Have, Where It Ends

Lovable gives you a real backend, until it does not. The documented ceilings of the edge function model, the five signals your app has outgrown it, the three ways to add a custom backend without a rebuild, and the honest case for doing nothing yet.

AI App Builder: Which One to Pick, and What Breaks After

Every comparison ranks these tools on the demo. None say what you are left holding. What Lovable, Bolt.new, v0, Replit Agent, Base44 and Firebase Studio each generate, where no-code AI app builders differ from code-generating ones, and the four failures that show up the week real users arrive.

How Do You Stop Prompt Injection in a Production AI Agent?

Your system prompt telling the model to ignore injected instructions does not hold, and a classifier will not save you either. Where the trust boundary actually belongs, why closing the exit beats guarding the entrance, and the six published patterns that trade capability for a guarantee.

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

Every comparison is a table of checkmarks. None say whether the decision deserves the three weeks you are about to give it. What each platform actually is, where lock-in really accumulates, what breaks first once the fleet is real, and when the right answer is to skip both.

React Web App to Mobile: Wrap, Rewrite, or Neither?

The tutorials say the wrap takes five minutes. They are right, and that is not the hard part. What ports out of a React codebase, what quietly does not, the App Store rule nobody mentions until after the work is done, and how to tell which of the three answers your product actually needs.

Can You Put PHI in an LLM? What a BAA Actually Covers

Every page tells you ChatGPT is not HIPAA compliant. None tell you what compliant looks like in your stack. Which vendors sign a BAA, what that signature reaches, why zero data retention decides whether it means anything, and the leak sitting in your own observability tooling.

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Google deletes Firebase Studio workspaces on 22 March 2027. Your data survives and your app keeps running. The record of why it was built the way it was does not. What the export contains, what it leaves behind, and what breaks first under real users.

Base44 to Production: What You Own and What You Cannot Take

You pressed export and got a repository. Then you read the environment file and found it still points at Base44. What the export actually contains, what stays behind, what the Wiz security disclosure means, and the four-stage sequence for moving off the platform.

Your AI Pilot Works. Why Is It Still Not Live?

The demo landed and the budget followed. Nine months later it is still a pilot. Why a pilot is a complete answer to a different question, what has to exist around the model before real users arrive, how to tell a retrieval problem from a generation one, and the order the work has to happen in.

FlutterFlow to Production: What Export Actually Gives You

You pressed Export Code and found out it only goes one way. Somebody has already said the word rebuild. It is real Flutter and it compiles, so this is almost never a rewrite. What actually lands in your repository, why the helper library is now yours to maintain, where custom code stops, and the order a takeover has to happen in.

Single Tenant to Multi Tenant: What Actually Has to Change

Fifteen customers on fifteen deployments, or one bespoke build you now want to sell as a product. Somebody has told you this needs a rewrite. It usually does not. Why the tenant column is the easy afternoon, why enabling row-level security does not apply it to the role that owns the table, and what breaks that is not the database at all.

Expo Go to Production: What Actually Breaks

It ran fine in Expo Go and now it will not ship. The JavaScript is not the problem and almost none of it needs rewriting. Why you no longer eject, why your environment variables were baked in at build time, what the New Architecture migration really costs, and who should not do any of this.

On-Premise LLM Deployment: Do You Actually Need It?

The data cannot leave our infrastructure is four requirements in one sentence, and only one of them needs your own hardware. What the cloud already guarantees by default, why strict retention quietly switches off specific frontier models, and the three cases where on-premise is genuinely the only answer.

Supabase Scaling: Which Wall You Actually Hit (2026)

Three walls, in a fixed order. Connection exhaustion first, query shape second, real architectural limits a distant third. Why upgrading compute is usually the wrong first move, why Prisma times out when nothing else does, and the three cases where leaving Supabase is genuinely the answer.

What Does Lovable Actually Generate? The Answer Changed in May 2026

Nearly every guide still says React on Vite. Lovable s own FAQ says apps created from 13 May 2026 use TanStack Start with server-side rendering. How to check which one your project is, why it decides whether AI crawlers can read you, and why you almost certainly do not need a Next.js rebuild.

Next.js 16 Migration: What the Codemod Cannot Do For You

The codemod renames middleware to proxy and moves your Turbopack config. It cannot decide where your auth boundary lives, and it will not stop next build failing on a webpack config you never wrote. What breaks, in what order, and who should wait.

Replit to Production: The Blast Radius Guide (2026)

Taking a Replit app live is not a code quality problem, it is an access problem. What the 2025 database deletion actually proved, what Replit fixed within a day, what still shares credentials with your agent, and who should not harden anything yet.

MCP Server in Production: What Changes When It Stops Being Local

Your MCP server works on STDIO. Exposing it over HTTP turns it into an internet-facing OAuth 2.1 resource server with a different threat model. What the spec actually requires, why token passthrough is forbidden twice, and who should not build this at all.

Originally published on Geminate Solutions.

IoT App Builder or Custom Build? How to Decide

Geminate Solutions — Mon, 07 Sep 2026 12:15:57 +0000

Every IoT app builder gets you to a working dashboard in a fortnight. Blynk, ThingsBoard, Losant, Ubidots, Datacake, all of them. The question that decides your next two years is what happens the day you hit something the builder was never shaped to hold. Here is the short answer. Stay on the builder while your ceiling is still configuration: a widget that won t draw, a dashboard that crawls past 90 days. Move when you can name a structural ceiling: an alert rule that needs state across devices, a second customer who needs their own tenant, a compliance signature the vendor won t give. This guide walks that decision first, with a table of what each builder locks, then the architecture behind the custom path: protocols, the sensor pipeline, device management, OTA and dashboards. Most IoT projects don t fail in the cloud. They fail at the device. A gateway drops its cellular signal, a firmware push bricks 200 units in the field, and someone has to drive out to them. We ve watched all of that happen while shipping the hardware-to-cloud pipeline behind Pixytan GPS, now tracking 30,000+ vehicles, so this is what actually matters when the platform has to survive contact with the real world.

Should You Use an IoT App Builder or Build Custom? Blynk, ThingsBoard, Losant, Ubidots and Datacake Compared

You stood the dashboard up in a fortnight and it worked. Then you tried to write one alert rule the drag-and-drop editor couldn't express, and everything stopped. That is the wall. An IoT app builder like Blynk, ThingsBoard, Losant or Ubidots will get you to a working demo faster than any custom build, and it stops being the right tool the moment your product needs something the builder's data model was never shaped to hold.

What a builder locks is not the interface, it is the model underneath. Four things, and none of them is the part you see. The data model comes first: telemetry arrives in the shape the platform expects, so a device reporting a nested payload gets flattened or dropped at the door. Second is the rules engine, and its expression limits are the ceiling most teams actually hit. A condition like "alert when vibration stays above baseline for 90 seconds across three sensors on the same machine" needs state the editor has nowhere to keep. Third is tenancy. Most builders assume one organisation looking at one fleet, so your second customer wanting their own users, their own thresholds and their own branding is a re-architecture, not a setting. Fourth is egress. Your history lives in their store, in their schema, behind their export limits.

Run what you just hit against this before you decide anything:

An IoT app builder is a platform that turns device telemetry into dashboards, alerts and user accounts through configuration rather than code. Blynk, ThingsBoard, Losant, Ubidots and Datacake are the five we see most. An IoT platform is the layer underneath, the broker, the time-series store and the rules engine, and a builder is a platform with those decisions already made for you. That is why it is fast. It is also where it stops, and each one stops in a different place. Everything in the table below comes from the vendors' own documentation, checked this month, not from a sales deck.

Read that table honestly and ThingsBoard is the one you are least likely to outgrow. Its rule chains hold state and aggregate across devices, its tenancy is real, and because you can run the Community Edition yourself, the history is in your database rather than behind an export limit. The price of that is operations. Somebody has to patch it, back it up and scale the queue, and that somebody is you. The hosted builders trade that work away and hand you a ceiling in return. Neither choice is wrong. The mistake is not knowing which one you made.

The ceiling nobody puts in a feature table is commercial. Builders bill on some mix of provisioned devices, active devices, message volume and stored data points, and the mix decides whether your bill tracks your fleet or your traffic. A fleet of quiet sensors on a per-device plan pays for silence. A handful of chatty devices on a metered plan pays for every heartbeat. Model your fleet's shape against the plan's meter before you scale, because that ceiling arrives on the renewal, not in a support ticket. The drivers behind a custom IoT build are the other half of that comparison.

Plenty of teams should stay exactly where they are, and we will say so. Under a few hundred devices, with standard telemetry like temperature, GPS or on-off state, one organisation looking at the data and no regulator asking you to sign anything, a builder is the correct answer. Moving off it would waste your money and six months of your calendar. We have told people this and watched the project go away. It is still the right call. The trigger to move is never ambition. It is a ceiling you can name.

The expensive mistake is not picking a builder. It is waiting until the platform is load-bearing under a signed customer contract before admitting you have outgrown it. Migrating at 500 devices is a project. Migrating at 40,000, mid-contract, with a support queue already open, is a different animal entirely.

Here is the part that vendors and agencies both get wrong: your devices usually survive. Firmware is the last thing you touch, not the first. If your devices already speak MQTT, they are speaking to a topic and a broker, and both of those are replaceable without anyone driving to a site. The order we run it in: stand up your own broker, EMQX or AWS IoT Core, alongside the platform. Dual-publish so both receive the same stream while nothing is live yet. Rebuild the rules engine against your broker and run it silently next to theirs for two weeks, comparing every alert one by one. Backfill history through the platform's export into TimescaleDB. Cut the dashboard over last. Only then do you repoint device config, and in most migrations the firmware is never rebuilt at all, because the endpoint is configuration rather than code. If you have already made the decision to build and want the architecture end of it, our IoT platform development guide goes deeper there.

Hit a ceiling you can name? Send us the rule you cannot express and your device count, and our team will tell you straight whether it is a configuration fix or a real migration. If it is a configuration fix, we will say so and you will owe us nothing.

What Types of IoT Apps Are Companies Building?

IoT Analytics counted 18.8 billion connected IoT devices in 2025, and the projection puts that near 30 billion by 2030. None of that growth is just consumer gadgets. A lot of it is industrial sensors, fleet trackers, medical wearables, smart buildings, farm monitors. And here's the part people underestimate: every one of those verticals wants a different architecture. Which architecture you land on is also what moves the effort, and the drivers behind an IoT build are broken out separately.

Fleet and asset tracking is the biggest IoT segment by sheer deployment volume. Put a GPS device on a truck or a container and it ships location, speed, and diagnostic data every 10 to 60 seconds over the cellular network. The app turns that into live maps, route history, geofence alerts, fuel-consumption patterns. We've built IoT systems tracking 30,000+ vehicles in production. Our Pixytan platform runs the geofencing, speed alerts, and live tracking across Gujarat's road network, so this isn't theory for us.

Industrial monitoring is factory equipment, energy systems, environmental sensors. Temperature, vibration, pressure, humidity, all of it reporting back to one platform. Readings cross a threshold and the system fires alerts, sometimes an automated shutdown if you wire it that way. Picture a steel plant with 2,000 sensors going off every 5 seconds. That's 400 data points a second slamming into your pipeline, and it never stops.

Connected healthcare means wearable monitors, remote patient devices, clinic equipment. A heart-rate, blood-pressure, SpO2, or glucose monitor sends its readings over BLE to a phone, and the phone relays them up to the cloud. Then HIPAA and GDPR compliance show up and add 20 to 30% to your build cost. Plan for it early.

Smart home and building automation leans on Zigbee, Z-Wave, or plain WiFi to run lighting, HVAC, security cameras, door locks. The app handles remote control and scheduling, throws up energy-usage reports, and ties into a voice assistant like Alexa or Google Home for the people who want that.

So what ties every one of these together? Reliable data ingestion at scale, real-time processing, and dashboards people actually act on. The protocol changes. The device hardware changes. The compliance rules change by vertical. But underneath, the software architecture rhymes from one project to the next. For a closer look at how we handled fleet tracking in particular, read our fleet management software guide.

How Much Does IoT App Development Cost by Project Type?

McKinsey's IoT Value report puts the annual economic value of IoT at trillions of dollars once you fold in productivity gains, cost savings, and new revenue lines. That's the upside. What it costs you to actually go capture a slice of it swings hard depending on the use case.

Device count is the biggest cost lever, by far. Running 500 sensors and running 50,000 are not the same product wearing different paint. At 500 devices reporting every 30 seconds you're handling 1,000 messages a minute. Bump that to 50,000 devices and you're at 100,000 messages a minute. Your database, your message broker, your compute, none of it scales in a straight line as you climb.

Protocol complexity is the second driver. A WiFi-only device speaking MQTT straight to AWS IoT Core is about as simple as it gets. But put a BLE device that pairs to a phone gateway, which then relays to the cloud over a REST API, and now you've got two communication layers that fail in two different ways. Throw LoRa into the mix for long-range, low-power units out in rural areas and you're supporting three protocols at once. Each one is its own thing to debug.

We've load-tested our examination systems at 10 million+ requests per minute. That experience carries straight over to IoT. Same core problem really: swallow a huge volume of time-stamped data, do it fast, and don't blow past your latency budget while you're at it.

Planning an IoT platform? Tell us your device type, your protocols, and the scale you're aiming for, and our team will scope the architecture with you.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

Which IoT Protocol Should You Use: MQTT, BLE, HTTP, or CoAP?

The Eclipse Foundation's 2025 IoT Developer Survey found that 83% of IoT developers use MQTT, which makes it the default for cloud-connected devices. That doesn't mean it's always right. Every protocol trades something away, and the trade is what decides which one fits your case.

Reach for MQTT on anything with WiFi or cellular. The publish/subscribe model means a device never has to hold a persistent connection to one specific endpoint. A temperature sensor just publishes its readings to a topic, say factory/floor-3/temp/sensor-42. From there your dashboard, your alert engine, and your data pipeline can all subscribe and pull those messages on their own, independently of each other. EMQX and Mosquitto are the two brokers most teams pick. If you'd rather not run your own, AWS IoT Core gives you a managed MQTT broker.

MQTT's Quality of Service levels are where reliability lives or dies, so pick deliberately:// QoS 0: Fire and forget (fastest, possible loss)client.publish('sensors/temp', '22.5', { qos: 0 });// QoS 1: At least once delivery (may duplicate)client.publish('sensors/temp', '22.5', { qos: 1 });// QoS 2: Exactly once delivery (slowest, guaranteed)client.publish('sensors/critical-alert', 'overheating', { qos: 2 });

BLE is for device-to-phone hops. Fitness trackers, glucose monitors, smart locks. They lean on BLE because it sips battery. The phone plays gateway here: it picks up the BLE data from the device and pushes it out to the cloud over its own internet connection. BLE 5.0 doubles the speed and quadruples the range of BLE 4.2, and its 251-byte payload is plenty for the kind of sensor readings these devices send.

CoAP is for the truly starved devices. When your microcontroller has 64KB of RAM and has to nurse a coin-cell battery for 5 years, CoAP over UDP comes in lighter than MQTT over TCP. It borrows the same request/response shape as HTTP but ships far smaller messages. You see it a lot in agricultural sensors and infrastructure monitoring, the places where thousands of devices have almost no power to spare.

How Do You Architect a Sensor Data Pipeline?

AWS reckons IoT deployments can pump out up to 1 TB of data per day per 10,000 devices. You're not going to dump that into a plain PostgreSQL table and walk away. IoT pipelines get built for one job: swallow high-volume, time-stamped writes and still answer queries in real time.

Four stages, and they always show up in the same order. Ingestion first: devices fire data over MQTT into a broker like EMQX or AWS IoT Core. Then processing, where a rules engine or stream processor (AWS Lambda, Apache Kafka) validates the message, reshapes it, and routes it onward. Storage comes next, a time-series database such as TimescaleDB or InfluxDB holding the data under automatic retention policies. Last is querying, where the dashboard and alert engine read back out with time-range filters.

Drawn out, the flow looks like this:Device (MQTT) → Broker (EMQX/AWS IoT Core) → Rules Engine (filter + transform) → Hot path: Real-time alerts (if threshold exceeded) → Warm path: TimescaleDB (queryable for 90 days) → Cold path: S3 (archived indefinitely, at a fraction of a cent per GB)

On IoT, a time-series database isn't optional. TimescaleDB bolts hypertables onto PostgreSQL, and those partition your data by time on their own. You keep full SQL, and you pick up time-series helpers like time_bucket() for downsampling. InfluxDB is the other route. It writes faster and gives you retention policies out of the box, though you trade your SQL for its own query language (Flux). Either one will take 100K+ inserts per second on a single node.

Tiered retention is where you stop bleeding money. Hot data, the last 24 hours, stays in memory so dashboard queries come back instantly. Warm data, the last 90 days, sits in TimescaleDB for the historical stuff. Anything older, 90 days and up, gets shoved to S3 at a fraction of a cent per GB a month. A retention policy moves it between tiers for you. And honestly, most IoT dashboards never look past the last 7 days, so there's no good reason to keep 12 months of raw sensor data parked in an expensive database.

Edge computing just drags the processing closer to the device. Rather than streaming raw accelerometer data at 50 readings a second up to the cloud, an edge processor crunches it locally and sends one summary every 30 seconds. That alone cuts bandwidth by 95% and cloud costs by 80%. If you want it managed, AWS Greengrass and Azure IoT Edge are the two to look at. For this exact pattern running in fleet tracking, read our Twings GPS case study.

What Does Device Management and OTA Updates Involve?

Gartner pegs it at 75% of IoT projects blowing their timeline because of device management complexity. The sensor and the app are the visible parts, the bits everyone budgets for. Running 10,000 deployed devices is where the time actually goes. Provisioning them, watching their health, pushing firmware, cleaning up when one fails. That's where the real engineering hides.

Provisioning comes first. Every device needs a unique identity (a device ID plus an X.509 certificate), its config (reporting interval, server endpoint, alert thresholds), and a credential to authenticate against the MQTT broker. At 100 devices you can sit there and set each one up by hand. At 10,000 you can't, you need an automated provisioning pipeline. AWS IoT Core does fleet provisioning with templates: a new device boots, hits a provisioning endpoint, gets handed its certificate and config, and starts reporting. No manual touch per device, which is the whole point.

Device shadows, sometimes called digital twins, hold the state for you. A shadow is just a JSON document up in the cloud that mirrors each device's last known state. Device drops offline? The shadow can still answer "what was the last temperature reading?" or "is this thing healthy?" Then the device comes back, syncs against the shadow, and catches up on whatever commands were waiting for it.

OTA firmware updates are the part that keeps you up at night. Push a bad update to 10,000 devices and you've just bricked 10,000 devices that you cannot physically reach to fix. So here's the pattern that keeps you safe. Upload the new firmware to a CDN or S3. Create an update job aimed at one device group. Ship it to 5% of devices first as a canary, then sit on your hands and watch for 24 hours. Only after that do you roll out in batches of 10 to 20%, with automatic rollback armed in case error rates spike.

A health-check query we lean on looks like this:-- Find devices that stopped reporting in the last hourSELECT device_id, last_seen, firmware_versionFROM device_registryWHERE last_seen AND status = 'active'ORDER BY last_seen ASC;

Then there's battery management for the wireless units. A GPS tracker on a 3,000mAh battery, reporting over cellular every 10 seconds, gives you maybe 3 to 7 days. Drop it to 60-second intervals with sleep mode between transmissions and the same battery stretches to 30 to 60 days. So your management platform has to watch battery levels, guess at replacement dates, and warn the operators before a device goes dark on them.

Certificate rotation is a security must, not a nice-to-have. Device certificates expire, usually after 1 to 2 years. Before that day comes, the device has to ask your provisioning service for a fresh certificate, check it, and cut over to it without any downtime. AWS IoT Core automates the rotation for you. Go self-managed, though, and that rotation logic is something you bake into the firmware yourself.

How Do You Build Real-Time IoT Dashboards?

Grafana Labs says over 20 million users run their dashboarding platform for IoT monitoring. Dashboards aren't just pretty charts though. In IoT they're the layer that sits between raw sensor data and a human deciding what to do about it. A good one takes 100,000 data points and hands you three things worth acting on.

Pre-built or custom? It depends on who's looking. When your users are technical, ops teams and engineers, Grafana is the obvious pick. It plugs straight into TimescaleDB and InfluxDB, streams in real time, and ships 100+ visualization types. But hand Grafana to a fleet manager or a building operator or a healthcare provider and it's wrong for them. Those users get a custom React or Next.js dashboard built around how they actually work.

For live updates, it's WebSocket or SSE. The dashboard subscribes to a WebSocket channel, and the moment new sensor data lands in the pipeline the server pushes it out to every connected client within 1 to 3 seconds. If you only ever push server-to-client and never need anything coming back the other way, Server-Sent Events (SSE) is the simpler choice. SSE holds up fine for 50 concurrent dashboard users. Past 500, WebSocket backed by Redis pub/sub handles the fan-out a lot more gracefully.

The widgets that actually earn their place on an IoT dashboard? A live map with device locations color-coded green, yellow, red so status reads at a distance. A time-series chart for the last 24 hours of whatever metric you've selected. An alert feed listing triggered alerts newest-first. A device health table showing battery level, firmware version, last-seen timestamp, signal strength. And a comparison chart that puts trends across device groups side by side. That's the set we keep coming back to.

For fleet and asset tracking, geofencing visualization is the thing that matters most. You draw polygons on the map to mark out zones, a warehouse, a delivery area, a restricted area. When a device crosses into or out of one, the system fires an alert and logs it. The dashboard then plots those boundary crossings as timeline events right next to the map. Our custom development team has built exactly this kind of geofencing for fleet platforms running tens of thousands of vehicles.

Keep load time under 2 seconds. Pre-aggregate the common time ranges, last hour, last day, last week, so the dashboard never has to grind through raw data on the fly. Cache the device metadata you read constantly in Redis. Lazy-load any chart that starts below the fold. None of this is busywork: a slow dashboard means operators miss alerts, and in industrial IoT a missed alert can mean wrecked equipment or someone getting hurt.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

On-Premise LLM Deployment: Do You Actually Need It?

Supabase Scaling: Which Wall You Actually Hit (2026)

What Does Lovable Actually Generate? The Answer Changed in May 2026

Next.js 16 Migration: What the Codemod Cannot Do For You

Replit to Production: The Blast Radius Guide (2026)

MCP Server in Production: What Changes When It Stops Being Local

Originally published on Geminate Solutions.

Build on Samsara or Geotab Data: What the APIs Allow

Geminate Solutions — Mon, 07 Sep 2026 12:15:48 +0000

What the Samsara and Geotab APIs actually let you build, their documented limits side by side, why one pushes and the other only polls, who should not build at all, and what to build first.

The renewal quote is on your desk and it has a new line on it. A customer asked for a portal where they can see their own vehicles. Dispatch wants a rule the alert editor cannot express. Finance wants trips joined to invoices. Every answer from the vendor has been another per-vehicle add-on, so you typed samsara api integration, or geotab api integration, because you suspect the data could just be used directly.

It can. Both vendors publish a real API, and the hardware you already paid to install keeps doing exactly what it does today. What changes is where the features live. Built inside the catalogue, a feature is rented and leaves with the contract. Built on the API, it is yours and it survives a vendor switch. That is the whole argument, and nobody has to rip anything out of a truck to act on it.

One warning before the detail. The two APIs are not the same shape. Samsara will push events to you. Geotab will not, by design, so you poll. Which one you have decides what the first month of engineering looks like, and most agencies quoting this work have never read either set of docs closely enough to tell you that.

How do the Samsara and Geotab APIs actually differ?

They differ on push, on pagination and on how the limits are counted. Everything below comes from the vendors' own developer documentation as published at the start of September 2026, not from a sales deck, and where we could not verify a figure we say so rather than guess.

Read the table as an engineer would. Samsara's model is a modern REST API you can mostly treat like Stripe. Geotab's model is a synchronisation feed, closer to a replication log than a query endpoint, and it rewards a different design: a poller that remembers where it got to, calls again immediately when a page comes back full, and slows down when nothing changes. Their own guide describes exactly that adaptive loop.

One thing we could not settle. Community posts quote a hard cap on records per GetFeed call that does not appear in the official rate limit guide. We build to the official table and treat the community figure as a rumour until a vendor page says it.

What does staying inside the vendor s add-on catalogue cost you?

Not money, or not first. The fleet hub on this site already covers the per-vehicle arithmetic in our custom fleet management software guide, and if that is your question, start there. This page is about the thing that arithmetic hides.

Every feature you configure inside the vendor's product is a feature the vendor owns. The customer portal you switched on is their portal with your logo. The report you built in their editor lives in their editor. When the renewal comes back higher, or when a second business unit turns up already on the other vendor, every one of those features is a reason you cannot move. The per-vehicle line grows with the fleet. The things you built on top of it are rented.

The practical consequence shows up in three places. Sales loses a deal because a prospect wanted their vehicles inside the prospect's own system and you could only offer a login to yours. Finance reconciles trips against invoices by export and spreadsheet every month, because the join never existed. And operations keeps a rule in someone's head that the alert editor could not hold. None of those is a crisis on its own. Together they are the reason you are reading a page about APIs at renewal time.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

Who should not build on the API at all?

Most fleets under a couple of hundred vehicles, and it costs us work to say so.

If you run one vendor, your needs are reminders, maintenance workflow and a tidier report, and nobody outside your company ever has to log in, do not build anything. Fleetio's marketplace integration, Zapier's Samsara connector or the vendor's own app marketplace already cover that, and the vendor keeps them working when the API changes. Building your own integration for a workflow problem gives you a second system to maintain and no feature your team can see.

There is a second group who should wait. If your only pain is the price, the API does not fix it. Your data still lives with the vendor, the hardware still reports to the vendor, and you still pay per vehicle. What changes when you build on the API is ownership of the features and the history, not the subscription. If the subscription itself is the problem, that is the build-versus-buy decision in the hub guide, and it has a different answer at different fleet sizes.

Come back to this page when a customer, a billing rule, or a second vendor needs data in a shape the catalogue will not give you. Those three are the real triggers.

What can you actually build on top of the data?

Building on telematics data means taking the vehicle positions, trips, engine status and events the vendor already collects, pulling them through the published API into a store you control, and putting your own application on top. The hardware, the cellular link and the vendor's platform stay exactly as they are. Your product starts one layer above them.

Four things account for nearly every request we see, and the order matters.

A customer-facing portal. Equipment hire, last-mile contractors and field service operators all get asked the same question by their own customers: where is my thing right now. A portal that shows a customer only their assets, with their own users and their own alert preferences, is the single most common build, and it is a multi-tenant application problem more than a telematics one. The vendor's shared login was never designed for it.

A dispatch rule the editor cannot hold. Vendor alert editors handle thresholds well. They handle state badly: a rule that depends on the last three stops, on which driver is assigned today, or on a job that lives in your own scheduling system. Once the rule needs your data as well as theirs, it has to run on your side.

Billing joined to trips. Usage-based invoicing, chargebacks between business units, proof of delivery attached to an invoice line. The join between a trip record and a commercial record is the feature finance keeps asking for, and it only exists if both records land in one place.

Reporting joined to the rest of the business. Fuel against ERP purchase records, utilisation against the maintenance system, driver scores against HR. Each of these is a report the vendor cannot produce because half the data was never theirs.

Every one of these starts with the same first component, an ingestion layer that copies vendor data into your own time-series store as it arrives. On our own 30,000-vehicle fleet platform that store is TimescaleDB with Redis holding the live positions, and the same shape works whether the data arrives from your own hardware or from a vendor API. If your devices report into an IoT builder such as ThingsBoard rather than a fleet vendor, the ceiling arrives differently and our IoT app builder guide walks that version.

Webhooks or polling: which fits a portal, a dispatch rule or billing?

Webhooks fit anything that has to react in seconds, polling fits anything that has to be complete, and the vendor you have already made half the choice for you.

A webhook is the vendor calling your server the moment something happens. Samsara offers this for alerts and for event subscriptions, signs each payload with HMAC SHA-256 so you can prove it came from them, and retries five times with exponential backoff if your endpoint fails. That is the right feed for a dispatch rule or a customer alert, where a geofence exit that arrives three minutes late is a log entry, not an alert. It is the wrong feed for billing, because a webhook you missed during a deploy is a trip you never invoiced, and five retries is not a guarantee.

Polling is your server asking the vendor what changed since last time. Geotab's GetFeed is built for exactly this: every response carries a version token, you pass it back on the next call, and you receive only the records that changed. Nothing is lost if your server was down for an hour, because the checkpoint waited. That is the right feed for billing and history, and with the adaptive loop the guide recommends it is fast enough for a live map. It is a poorer fit for sub-minute alerting, and the per-method rate limits in the table above are the constraint you design around.

So the practical rule is this. On Samsara, run both: webhooks for the reactive features, a scheduled paginated pull for the record of truth. On Geotab, run one well-built poller with a checkpoint per entity type, and derive alerts from the stream on your side. Either way the poller or the receiver writes into your store, and everything you build reads from that store, never from the vendor directly. That separation is what makes the vendor swappable later.

How do you handle more than one telematics vendor?

You normalise once, at the ingestion layer, and nothing above it knows which vendor a vehicle came from.

Multi-vendor fleets are more common than the vendors admit. An acquisition brings a Geotab fleet into a Samsara company. A subcontractor runs Motive. A rented excavator reports through Trackunit. The temptation is to build the portal against one vendor's API and bolt the others on later. The result is a portal with four code paths and four sets of bugs.

The cleaner shape is a small canonical model, a vehicle, a position, a trip, an event, a fault code, and one adapter per vendor that translates into it. Samsara's cursor pages and Geotab's version feed both land in the same tables. The portal, the dispatch rules and the billing job read the canonical tables and never see a vendor field. Adding a fifth vendor is one more adapter, not a rewrite.

There are companies that sell this layer as a product, Terminal and flespi among them, and for a fleet that only needs the normalised feed they can be the right buy. Two honest tests. If you would build nothing on top except a dashboard, buy the layer. If the thing on top is your product, the customer portal you sell or the billing engine your margin depends on, the adapter layer is small enough to own and too important to rent. Motive and Trackunit both publish developer documentation, and we do not quote their limits here because we have not verified them the way we verified the two above.

Who owns the data when you switch platforms?

You own what you have already pulled. You lose access to the rest when the contract ends.

Neither vendor hides this. Samsara's history is available through the same paginated endpoints you use every day, so a nightly job that walks every vehicle's trips into your own store builds the archive as a side effect. Geotab's feed can be replayed from version zero or from a date, and full database export exists as an administrative feature, with longer retention handled through support. In both cases the work is the same: pull it while you have a key, into a store you control.

This is the argument that convinces the people who were not convinced by features. A fleet that has been on one vendor for six years and moves to another loses six years of driver behaviour, fuel patterns and route history unless it copied them out. An integration layer you built for a portal turns out to have been an insurance policy. It is also the reason we put the store between the vendor and the application in every diagram on this page. Swapping the vendor means swapping the adapter. The history, the portal and the billing rules do not notice.

When it is worth handing this to someone

If the catalogue covers you, use it and read no further. If a single Zapier flow or a Fleetio connector closes the gap, do that this week.

The point where it stops being a side project is the first feature that someone outside your company depends on. A customer portal that goes down at their month end, a billing job that double-charged because a webhook retried, a poller that quietly stopped at a version token nobody was watching. This is ordinary engineering, but it is engineering on live vehicles and live invoices, and the vendors' rate limits, retries and session rules are exactly the details that go wrong when they are learned in production.

That is the work we do at Geminate Solutions. We build software products for companies that run fleets and the businesses around them, on top of whichever telematics they already have, and we do not sell rebuilds. The hardware stays. The vendor stays until you decide otherwise. You own the code, the adapters and the store from the first commit. We run our own fleet platform at 30,000+ vehicles, have shipped 50+ products, and hold Top Rated Plus on Upwork at 4.9. If you want to see how we scope this kind of build, our custom software development service page lays out how an engagement runs.

The starting point is the one we would give a friend with a renewal on their desk: a short written review of what your vendor's API will and will not give you, which of the four builds you actually need, and whether you need any of them yet.

Frequently Asked Questions

Can you build a custom app on top of Samsara data?

Yes. Samsara publishes a REST API with token or OAuth 2.0 authentication, cursor pagination at up to 512 records a page, and signed webhooks for alerts and event subscriptions. A customer portal, a dispatch rule or a billing feed can be built against it without changing anything on the vehicle.

Does the Geotab API support webhooks?

No. Geotab's data feed guide says a push model would require Geotab to connect into your network through your firewall, so the documented pattern is polling. You call GetFeed with a fromVersion checkpoint, receive only what changed, and pass the new version back next time.

What are the Samsara API rate limits?

Samsara documents 150 requests a second per API token and 200 a second per organisation, with endpoint categories capped lower, down to 100 a minute for some. Over the limit you get a 429 with a Retry-After header and the docs ask you to back off by that value.

Should I use Fleetio or Zapier instead of building on the API?

Often, yes. One vendor, workflow needs, nobody external logging in: a marketplace integration covers you. Build when a customer, a billing rule or a second vendor needs data the catalogue does not expose in the shape you need.

Do I lose my fleet data if I switch from Samsara to Geotab?

You lose access to the vendor's copy when the contract ends. History you already pulled through the API into your own store stays yours. That is the strongest practical reason to put your own integration layer between the vendor and anything you build.

Tell us which vendor you run and what you are being asked for. A senior engineer reads the API against your request and writes back with what it will give you, what it will not, and whether you should build at all. No pitch, no commitment.

Whether your vendor's API exposes the data your portal, rule or billing feature needs
Webhooks, polling, or both, and what that means for the first month of work
An honest answer if Fleetio, Zapier or the vendor marketplace already covers it
The order to build in, and which piece protects your history if you ever switch

Get your free integration review

Drop your fleet s vendor and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

On-Premise LLM Deployment: Do You Actually Need It?

Supabase Scaling: Which Wall You Actually Hit (2026)

What Does Lovable Actually Generate? The Answer Changed in May 2026

Next.js 16 Migration: What the Codemod Cannot Do For You

Replit to Production: The Blast Radius Guide (2026)

MCP Server in Production: What Changes When It Stops Being Local

Originally published on Geminate Solutions.

Lovable Authentication for Real Users: What Breaks

Geminate Solutions — Mon, 07 Sep 2026 12:15:41 +0000

Every guide to Lovable authentication wires a login into a blank project. This one is for the app that already has users, and the four failures that show up the week they arrive.

Google login started bouncing to the preview URL the day your domain went live. Sign-ups stopped getting their confirmation email. A customer wants an admin who can see their whole team, and an investor just asked whether you have two-factor. None of those is a Lovable problem, exactly. Lovable Cloud runs on Supabase Auth underneath, so every one of them is a Supabase setting the prompt box never mentioned.

Here is the short version. The app does not need rebuilding. Authentication in a Lovable app is a handful of configuration decisions plus one database policy per table, and they can be fixed in place, in an afternoon or a week depending on which ones got skipped, without logging out a single existing user. This page goes through them in the order that stops the bleeding first.

One thing before the detail. If you have under a hundred users, take no payments and hold nothing personal, read the section on who does not need to touch any of this and probably stop there. We would rather say that now than three sections in.

What does Lovable actually give you for authentication?

A real authentication system, not a mock. Lovable Cloud ships email and password, magic links, one-time codes, phone, Google, Apple, Microsoft and SAML SSO, plus an anonymous-user mode for guest flows, all configured from the Cloud tab under Users and then Auth settings. Underneath it is Supabase Auth, the same thing you would get by connecting your own Supabase project, and our Lovable Cloud vs Supabase guide covers who owns what in that arrangement.

That matters because it tells you where the settings live. When Google login breaks, it is not the React code Lovable generated. It is a URL in Supabase's auth configuration. When confirmation emails stop, it is a rate limit on Supabase's built-in mailer. When one user can see another's rows, it is a missing Row Level Security policy on a Postgres table. The generated code is usually fine. The configuration around it was set for a demo.

Three defaults deserve naming because each is right for building and wrong for launching. Auto-confirm. Lovable's own docs call it convenient while building and testing, because you can create accounts without checking an inbox. Leave it on and anyone can sign up with an address they do not own. The built-in email provider, which Supabase caps at two messages an hour. And the Site URL, which points at wherever the app lived when auth was first wired up, and that is never your production domain.

Lovable also ships two security scanners. The Basic scan lints RLS policies, reviews the schema and audits dependencies. The Deep scan adds access control review and backend endpoint protection. Run both. Then read the sentence in the same documentation that says you are responsible for ensuring the app meets the security requirements of its use case, because that sentence is why this page exists.

Why does Google login break the week you connect a custom domain?

Because Google never talks to your domain. It talks to Supabase, and Supabase sends the user wherever its Site URL says, which is still the preview address.

The flow has three parties and two of them keep a list of allowed addresses. Your app sends the user to Google. Google sends them back to Supabase's callback URL, which has to appear in Google Cloud's authorised redirect URIs. Supabase then sends the user on to your app, at the Site URL by default or at whatever redirectTo you passed, and that address has to be on Supabase's redirect allow-list. Connect a custom domain and neither list has heard of it. The user signs in with Google successfully, lands on the old preview URL, and tells you login is broken.

Lovable offers two ways to run Google sign-in and they fail differently. Managed by Lovable means Lovable owns the OAuth client and the redirect handling, with no Google Cloud console at all, at the cost of being limited to email and basic profile scopes and to apps on Lovable Cloud. Your own credentials means you own the consent screen and any scope you need. Lovable's docs are blunt about the most common failure there: the redirect URIs you selected in Lovable do not exactly match the ones in Google Cloud. Scheme, path, trailing slash. All of it has to match.

The checklist to run before you flip the domain, not after. Set Site URL to the production domain with the exact path. Add the production domain to the redirect allow-list and remove localhost and the preview URL. If you run your own credentials, add Supabase's callback to Google Cloud's authorised redirect URIs. And set a custom auth domain, because Supabase's guide says that without one users see your Supabase project id on the consent screen, which makes the app more susceptible to successful phishing attempts. That is not a sentence you want to explain to a customer.

Wildcards exist on the allow-list and they are useful for preview branches. In production, use the exact URL. A pattern that matches your staging subdomain also matches a subdomain somebody else registers.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

Why did sign-ups stop confirming?

Because Supabase's built-in email provider sends 2 emails an hour, and that limit can only be raised by configuring your own SMTP.

This one arrives on launch day like clockwork. Ten people sign up in the first hour, two of them get a confirmation email, eight write to you. Lovable's docs describe the symptom exactly: if many sign-ups happen at once your project may have hit its hourly email rate limit, and the fix is custom email sending through your own domain. Supabase publishes the rest of the table. 30 one-time passwords an hour across the whole project. A 60-second window per user before a second magic link or code goes out. 360 verification requests an hour, 1,800 token refreshes, 30 anonymous sign-ins, 15 MFA challenge and verify calls.

The tempting fix is to switch confirmation off. Do not. Lovable's own docs say it plainly: without confirmation, anyone can sign up with an address they do not own. The right fix is a transactional email provider on your domain, ten minutes of DNS, and the built-in limit stops applying. While you are there, read what the templates say and where their links point, because confirmation and password-reset links go to the Site URL, the same setting from the previous section.

Two smaller things in the same area. Password reset in Supabase deliberately does not reveal whether an account exists, so a user who typed the wrong email sees the same message as one who typed the right one. Say so in the interface or support will hear about it. And the leaked-password check against Have I Been Pwned, which Lovable exposes as a setting, is a Pro plan feature on Supabase's side, so if you moved off Lovable Cloud onto a free Supabase project it is silently not there.

Who does not need to touch any of this?

More people than the security vendors would like.

If you have fewer than a hundred users, take no payments, store nothing you would call personal, and nobody outside your own company logs in, you do not need a development partner and you do not need Auth0. You need three switches. Confirm email is on. Site URL is your real domain. Row Level Security is enabled on every table that holds user data, which our vibe coding security guide walks through with the SQL. Do those, run Lovable's Deep scan, and go back to building the product.

If the app is internal, same answer with one addition. Turn on Google or Microsoft sign-in restricted to your company domain and you have solved onboarding and offboarding with one setting.

Come back when one of five things happens. Someone pays you. You store health, financial or identity data. A customer asks for their own admin. A customer asks for SSO. Or a second business unit needs its own users on the same app. Those are the triggers for the rest of this page, and until one fires the rest is premature.

How do you add roles and an admin without a rebuild?

Store the role in a table, put it into the token with an auth hook, and check it in the database policy. Never store it anywhere the user can edit.

The first version usually goes wrong in one of two ways: a role column on a profile row the user can update, or a role in user metadata. Supabase's RLS documentation is explicit that raw_user_meta_data is user-modifiable and unsuitable for authorisation, while raw_app_meta_data cannot be changed by the user. An admin flag a user can set on themselves is not a role. It is a suggestion.

The pattern Supabase documents is short. A user_roles table keyed on the user id. A Custom Access Token Auth Hook, which is a Postgres function that runs before every token is issued and adds a user_role claim to the JWT. Then policies that read the claim, so a team's admin view is visible only to sessions whose token says they belong there. One trap in the same docs: the hook changes the access token but not the auth response object, so the client has to decode the JWT to learn the role. A frontend that reads the role from the session object will treat everyone as a viewer and you will spend a day wondering why.

This is also where multi-tenancy starts, and it is not a rebuild either. A tenant id on every table, a membership table joining users to tenants with a role, and a policy that says a row is visible when a membership exists for the current user and this row's tenant. Lovable can generate the tables. What it cannot do is test the policy from a second account, which is the only test that counts. Sign in as a user in tenant B and try to read tenant A's rows by changing the id in the request. If it works, you are not done.

Frontend role checks stay, for the interface. They hide the button. The policy is what stops the request.

Do your users need two-factor, and how is that different from your own Lovable account?

They are two different systems. Two-factor on your Lovable account protects your editor seat and your deploy button. Multi-factor for your app's users is a Supabase Auth feature you enrol them in yourself, and about half the search results for the phrase confuse the two.

Lovable's account 2FA lives under your own login and works whichever way you sign in. It protects the thing that can redeploy your app. Turn it on today. It takes a minute and it is the cheapest security win on this page.

Your users are separate. Supabase Auth offers two factor types, an authenticator app using time-based codes and phone messaging using a code Supabase generates. The API has three parts: enrol a factor, challenge it, verify the code. After a normal login the token carries an assurance level of aal1. After a second factor it carries aal2. That claim is what makes the feature worth having, because you can write a restrictive policy on a sensitive table that reads (select auth.jwt()->>'aal') = 'aal2', and the payout table or the medical record simply does not exist for a session that only did a password.

Who needs it: anyone handling money, health or identity, anyone whose customers are companies with a security questionnaire, and anyone who has already had one account taken over. Who does not: a consumer app where the worst case is a lost to-do list, where a second factor costs sign-ups for nothing. The rate limit is real as well, 15 challenge and verify requests an hour, so a login screen that retries in a loop will lock people out of the very thing meant to protect them.

How long should a session last, and what happens to the people already logged in?

One hour for the access token, which is Supabase's default and the right answer for most apps. And nobody gets logged out when you change it, because sessions are only enforced at the next refresh.

This is the section for the founder afraid that hardening means every existing user is signed out on a Tuesday morning. It does not. Supabase's model is a short-lived access token, one hour by default, and a refresh token that never expires on its own but can be used exactly once, with a 10-second reuse window so a flaky network does not sign people out. Tighten the settings and Supabase's docs are explicit that sessions are not proactively destroyed. The new rule applies the next time each session refreshes, so the real lifetime is the timeout plus one token expiry. Users notice nothing.

The controls beyond the default are Pro plan features on Supabase's side. A time-box that ends a session after a fixed duration regardless of activity. An inactivity timeout. And single session per user, which keeps the most recent sign-in and closes the rest. That last one is the answer to shared logins on a paid plan, and to the support ticket where a former employee is still signed in on a laptop nobody can find.

The rule of thumb in our production checklist for Lovable apps, a one-hour access token and a refresh window measured in days, still stands. What that checklist could not fit is the mechanism, and the mechanism is what tells you the change is safe to make on a live app.

Do you need Auth0, WorkOS or Clerk, or is Supabase Auth enough?

Enough, for most Lovable apps. The pages telling you otherwise are mostly written by the vendors.

We read the search results for this question while planning this page. There were no Lovable-specific answers at all, and the general ones came from WorkOS, from Auth0 integration partners, or from people selling an alternative to both. That is not a reason to distrust the products. It is a reason to notice who is answering.

The honest line is this. Supabase Auth covers email, social login, magic links, phone, MFA, roles through the hook above, and enforcement in the database through RLS. That is everything on this page. The moment to reach for WorkOS or Auth0 is enterprise SSO: a customer who needs SAML against their own identity provider, SCIM provisioning so their IT team can add and remove seats, or audit logs their compliance team will ask for by name. Lovable Cloud lists SAML SSO among its sign-in methods, so even that case may already be covered on the built-in path, and it is worth testing before you add a vendor, a second user store and another bill to reconcile.

Clerk is a different trade: a very good pre-built interface for auth in exchange for holding your users in Clerk. If your users already live in Supabase, moving them is a migration with password resets attached. That is a change you make once, for a reason, not because a tutorial did.

Adding a vendor does not remove the RLS work. Whoever issues the token, the database still has to check it.

When it is worth handing this to someone

The moment someone else's money or data sits behind the login.

If the disqualifier section described you, do the three switches and go. If one of the five triggers has fired, the work on this page is a week of careful configuration and testing for someone who has done it before, and a month of guesswork for someone who has not, because the failures are silent. A policy that allows too much does not throw an error. A hook that forgot a claim makes everyone a viewer, quietly. A redirect allow-list wildcard that is too wide never complains.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can be trusted with them, and we do not sell rebuilds. Your Lovable app stays your Lovable app. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs. If it is the backend rather than the login that is creaking, the Lovable backend solutions guide is the sibling to this one.

The first step is a written review of what your auth configuration will and will not hold: the two URL lists, the email path, the session settings, the roles, and a second-account test against every table. We send it back within 48 hours and it stays yours whether or not we ever talk again.

Frequently Asked Questions

Can a Lovable app use magic link login instead of passwords?

Yes. Lovable Cloud supports magic links and one-time codes alongside passwords, all through Supabase Auth. The sending limits still apply: the built-in mailer sends 2 emails an hour and each user can request one link or code per 60 seconds, so configure your own sending domain before you rely on it with real users.

Does hardening authentication log out my existing users?

No. Supabase enforces session settings at the next token refresh rather than destroying sessions, so a tighter timeout takes effect gradually and silently. Changing the Site URL, the redirect allow-list, the email provider or the MFA settings does not end anyone's session either.

Does Row Level Security replace authentication?

No. Authentication establishes who the user is. Row Level Security decides which rows that user may read or write. Without it a logged-in user can read every row through the public key, because a table in an exposed schema with no policy is open to any role with a grant. You need both.

Can a Lovable app be multi-tenant without a rebuild?

Yes. Add a tenant id to each table, a membership table linking users to tenants with a role, and a policy that checks membership for the current user on every read and write. Then test from a second account in a second tenant, which is the only test that proves it.

Is two-factor on my Lovable account the same as MFA for my users?

No. Two-factor on your Lovable account protects your editor and deploy access. MFA for your app's users is a Supabase Auth feature with authenticator app and phone factors, enrolled per user, which raises the session's assurance level to aal2 so sensitive tables can require it.

Send us the live URL of your Lovable app. A senior engineer checks the two redirect lists, the email path, the session settings, the roles and a second-account test against your tables, and writes back with what will hold and what will not. No pitch, no commitment.

Whether Google and email login will survive your custom domain and your first busy hour
Whether any table lets one user read another's rows, tested from a second account
Where roles, admin and two-factor belong, and which of them you can skip for now
An honest answer if you do not need any of this yet

Get your free auth readiness review

Drop your app s URL and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It

What the Samsara and Geotab APIs let you build without touching the hardware. Their documented rate limits and pagination side by side, why one pushes events and the other only polls, who should use Fleetio or Zapier instead, and what to build first.

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

On-Premise LLM Deployment: Do You Actually Need It?

Supabase Scaling: Which Wall You Actually Hit (2026)

What Does Lovable Actually Generate? The Answer Changed in May 2026

Next.js 16 Migration: What the Codemod Cannot Do For You

Replit to Production: The Blast Radius Guide (2026)

Originally published on Geminate Solutions.

3PL Warehouse Management Software: When to Build Instead

Geminate Solutions — Mon, 07 Sep 2026 12:15:28 +0000

Every result on this search is published by a company that sells a WMS. So none of them can tell you the most useful thing about one, which is where it stops.

Most 3PL operators looking for new warehouse software don't need a new WMS. They need the billing layer their WMS was never built to hold. The picking and putaway you already run is fine. What broke is the bit where a movement in the warehouse turns into a line on a client invoice, and that's a smaller, cheaper and far less disruptive thing to fix.

One question tells you which situation you're in. Is your month-end invoice run happening inside your WMS, or does it start with an export?

If it starts with an export, keep reading. Saying this first costs us the larger project. It's still the right answer.

Why does 3PL billing always end up in a spreadsheet?

Because a warehouse management system models one rate card, and a third-party logistics business sells a different one to every client. That's the whole mechanism. Everything else follows from it.

Take storage on its own. One contract charges by pallet position on a receipt anniversary cycle, so a pallet received on the 9th bills in cycles from the 9th rather than from the start of the month. The next client pays per square metre, monthly, with a minimum that applies whether they use the space or not. A third is on cubic metres, because their goods are light and bulky and they negotiated hard. Same building. Same racking. Three different meanings for the word storage.

Handling splits the same way. Receiving might bill per pallet for one client and per carton for another. Pick and pack might be per order, per line, or per unit, and the client who agreed per order two years ago has since started sending single-line orders in volume. That's quietly the worst deal in the building. Then come the accessorials: wrapping, labelling, kitting, returns, rush handling, after-hours work. Plenty of those were agreed on a phone call and live in an email rather than in any system.

A standard WMS handles a rate card perfectly well. What it can't handle is fifty of them, each with exceptions, each on its own cycle, changing whenever a contract gets renegotiated. So the operations team does the only sane thing left. They export the movements, open a spreadsheet, and finish the job by hand.

None of this is the WMS failing. It was built to know where the stock is, and it does that. Billing a commercial agreement is a different problem that happens to use the same data.

What does an off-the-shelf WMS actually stop doing?

It is worth being precise about where the line falls, because the useful answer is not that off-the-shelf software is bad. It is that the line sits in a consistent and predictable place.

On the near side of the line, do not rebuild any of this. Receiving and putaway. Location and bin management. Wave and batch picking. Cycle counting and inventory adjustment. Lot, batch and serial tracking, including first-expired-first-out rotation if you hold food or pharmaceuticals. Barcode and scanner workflows. This is mature software that took the vendors years to get right, and there is no prize for doing it again.

On the far side, this is where teams start improvising. Multi-client rate cards with per-contract rules. Billing cycles that follow contract anniversaries rather than the calendar. Accessorials that need to be captured at the moment the work happens rather than remembered at month-end. A client-facing portal where your customers can see their own stock and their own charges without emailing you. Customs and tax obligations that treat an invoice as an integration rather than a document. Margin visibility per client, which is the one most operators want and almost nobody has.

That last one deserves a sentence of its own. Most 3PL operators can tell you revenue per client exactly. Very few can tell you which clients are actually profitable once labour, space and accessorial work are attributed properly, because the data needed to answer it is split across a WMS, a payroll system and a spreadsheet. The clients people assume are their best are not always the ones that survive that calculation.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

What is the spreadsheet actually costing you?

Three things, and only one of them is time.

The first is leakage you can't measure. Accessorial work is the usual culprit. Someone re-wraps a damaged pallet, or handles a rush order after hours, and whether it gets charged depends on a person remembering to write it down. Charges that depend on memory get missed. They also get missed in one direction only, because nobody ever over-remembers work they didn't do.

The second is that you can't defend an invoice you can't reconstruct. A client disputes a storage charge four months later. To answer properly you need a chain running from the invoice line back to the movements that produced it, with the contract version that was in force at the time. If the calculation happened in a spreadsheet that's been edited fourteen times since, that chain doesn't exist. So the dispute gets settled with a credit note, because arguing costs more than conceding.

The third is a person. There's always one person who understands the billing spreadsheet. They can't easily take leave at month-end, and if they resign the knowledge walks out with them. That's a real operational risk sitting in a file nobody has ever tested.

None of it appears on a profit and loss statement as a line item. It shows up as margin that's slightly worse than it should be. Every month, for years.

Who should not build warehouse software?

Plenty of people, and it's worth saying so plainly.

Don't build if you run one client, or a few on near-identical terms. The thing that justifies custom work is contractual variety. Without it you're buying an expensive way to do something simple.

Don't build if your rate card fits in one table with no exceptions. That's exactly what off-the-shelf 3PL billing modules are for, and they'll handle it.

Don't build if your invoice run takes an afternoon. Annoying isn't the same as broken. The threshold worth acting on is when it takes days, or when it needs one specific person.

Don't build if your WMS can't export clean movement data. This one is a sequencing problem rather than a permanent no. If you can't get reliable, timestamped movements out of the system you already run, a billing layer on top of it inherits that mess. Fix the data first, or change the WMS first, then come back to this.

In any of those cases, look at Extensiv, Logiwa, ShipHero or Da Vinci Unified before you talk to anyone about a build. They solve the common case properly. We'd rather tell you that now than three months into a project that was never going to pay for itself.

Should you replace the WMS or build alongside it?

Alongside it, in almost every case we look at. The urge to replace usually comes from frustration rather than analysis. Replacing a working WMS means stopping the part of your operation that's currently fine in order to fix the part that isn't.

The shape that works is a seam. Your WMS stays the system of record for stock truth: what's where, in what condition, owned by whom. A separate service subscribes to movement events coming out of it, receipts, putaways, picks, shipments, adjustments, and stores them as an immutable ledger of things that happened. Nothing in that ledger is ever edited. Charges get derived from the ledger by applying the contract that governed each movement at the time it happened.

That last detail is the difference between a system you can defend and another spreadsheet with better styling. Rate cards need versioning with effective dates, and every charge has to reference the version that produced it. Re-run a month a year later and you should get the same answer. If you can rerun a disputed invoice and land on the identical number, the dispute ends in one email.

The seam has a second benefit that matters more than it sounds. It keeps the risky, changing part of the project away from the part of the operation that must not stop working. If the billing service fails on a Tuesday, pickers keep picking.

The same reasoning applies if you also run vehicles. Telematics and route data belong in their own system for the same reason, and we cover that separately in our guide to fleet management software.

What changes for a 3PL in Saudi Arabia or the UAE?

Two things that most warehouse software quietly assumes away, and both of them touch billing rather than operations.

An invoice stops being a document and becomes an integration. Under the Saudi e-invoicing regime administered by ZATCA, invoices have to be generated in a prescribed electronic format and passed through the authority's platform rather than simply issued to the customer. That changes the engineering problem. Your billing system now has to produce a structured document, handle acknowledgement and rejection responses, deal with the case where the platform is unavailable at month-end, and keep the resulting records. A billing module designed around producing a PDF has nowhere to put any of that. The UAE now has a dated timetable of its own. The Ministry of Finance's e-invoicing programme runs on the OpenPeppol standard, began its pilot on 1 July 2026, and requires every business with annual revenue of AED 50 million or more to appoint an accredited service provider by 31 July 2026 and be live by 1 January 2027, with everyone else live by 1 July 2027. A system built today for one Gulf market should not hard-code the assumption that invoicing is a local operation, because within a year it will not be in either.

Stock carries a customs status, not just a location. If you operate in a free zone or a bonded facility, the same physical pallet can be in different duty states, and moving it across a boundary can constitute an import with paperwork attached. Off-the-shelf systems typically model location and owner. Fewer model duty state as a first-class property of the stock, and almost none let you bill differently based on it. Operators end up tracking this in a parallel system, which is the same failure mode as the billing spreadsheet, with worse consequences if it is wrong.

Neither of these is a reason on its own to build. They are reasons to check, early, whether the product you are evaluating can express them at all. That question is much cheaper to ask before a migration than after one.

What should 3PL billing software actually do?

Turn every movement into a charge you can defend, under the contract that governed it at the time, and hand the result to whichever tax platform your market requires. That is the whole job. Most products sold as 3PL billing software do the first third of it well and leave the rest to you.

Hold one rate card per client, versioned, with effective dates. Storage per pallet-day, per pallet position on an anniversary cycle, per square or cubic metre with a minimum. Handling per pallet, per carton, per order, per line or per unit. The shapes matter less than the versioning. A charge that cannot say which version of which contract produced it is a spreadsheet cell with better formatting, and it will lose the first dispute it meets.

Capture accessorials where the work happens, not at month-end. A re-wrap, a relabel, a kitting job, a return, a rush pick after hours. The scanner or the portal records the work as it is done, tied to the client and the stock it touched. Anything left to memory leaks, and it only ever leaks in one direction.

Give each client a statement, not just an invoice. Charges to date, the movements behind every line, stock on hand, documents. A portal that shows the client the same ledger you see removes most of the email your operations team answers, and it ends most disputes before they are raised, because there is nothing left to argue about.

Reconstruct any invoice, months later, to the identical number. This is the test that separates a billing engine from a report. Movements land in a ledger that is never edited. Charges are derived from the ledger and the contract version, never typed in. Rerun a disputed month a year on and the figure has to match to the cent.

Treat the tax authority as an integration with failure states. In Saudi Arabia, the Fatoora platform under ZATCA's integration phase clears a standard tax invoice before it is valid, returning it with a cryptographic stamp and QR code, while simplified invoices are reported to the platform within 24 hours of issue, both as XML. The integration phase has arrived in waves since January 2023 and the turnover threshold that pulls a business in has dropped with every wave, so a 3PL that sat outside it two years ago may not now. In the UAE the mechanism is different: invoices travel between accredited service providers on the Peppol network under the Ministry of Finance's programme, on the timetable above. Either way the billing engine needs a queue, retries, a record of what the authority accepted and rejected, and a plan for the hour at month-end when the platform does not answer.

Ask a vendor to show you each of those five on a live screen before you buy, and ask a build partner to show you where each one sits in the plan before you sign. The products that sell themselves as 3PL billing software are usually strong on the first two. It is the last three where the spreadsheet comes back.

How do you connect it to carriers, ERPs and client systems?

Through EDI and modern APIs at the same time, which surprises people who expected to pick one.

Larger retail and manufacturing clients still transact over ANSI X12 document sets, and a 3PL sees a predictable handful of them. The 940 warehouse shipping order tells you to ship. The 945 shipping advice tells them you did. The 943 and 944 cover stock transfers in and out, the 947 covers inventory adjustments, the 846 reports inventory levels, and the 997 acknowledges that a message was received at all. Meanwhile your ecommerce clients want REST endpoints and webhooks, and they want them documented.

So the integration layer has to translate between both worlds and stay honest about delivery guarantees. The practical rule is that no inbound message can be trusted to arrive exactly once. Shipment confirmations in particular get retried, and a retry that creates a second shipment record is how a client gets billed twice for one order. Idempotency keys on every inbound write, and a replayable log of what arrived, are not sophistication. They are the minimum for a system that will be argued about.

We have built this shape of integration surface before in fleet and tracking work, including the platform behind Pixytan, which tracks more than 30,000 vehicles. The domain differs. The problem of ingesting high-volume events from systems you do not control, without losing or duplicating any of them, does not.

What does the build look like, in what order?

Billing first, and against history rather than against the future.

Step one is the movement ledger and the rate engine. Pull movements from the WMS, model the contracts properly with versioning and effective dates, and generate charges. No user interface worth mentioning yet.

Step two is reconciliation, and it is the real acceptance test. Run the last three months through the new engine and compare every line against the invoices you actually sent. You are not looking for a perfect match. You are looking to explain every difference. In our experience of building calculation engines, the differences are the most valuable output of the whole project, because each one is either a bug in the model or revenue you were not charging. Teams routinely find the second kind.

Step three is the client portal. Stock levels, order status, charges to date, documents. This is usually where the commercial return shows up, because it removes a large volume of email that currently lands on your operations team, and it is the part clients notice.

Step four is automation and the rest of the integration surface. Automated invoice generation and dispatch, carrier connections, EDI onboarding for new clients, and the tax platform integration if you operate somewhere that requires it.

Doing it in that order means the thing that pays for the project is live first. If the work stops after step two, you still have a defensible invoice run, which was the actual problem.

How we would approach the build

We would start by asking to see your rate cards and one month of invoices, not by asking about your technology. The contracts are where the difficulty is. The technology follows from them, and any partner who quotes you a plan before reading a rate card is guessing.

We should be straight about one thing. Geminate Solutions has not shipped a 3PL warehouse platform. What we have shipped, across 50+ products, is the harder half of this problem: event ingestion at volume, calculation engines whose numbers get disputed, multi-tenant systems where one customer must never see another's data, and integrations with systems we do not control. The Pixytan fleet platform tracks over 30,000 vehicles. An exam platform we built absorbs more than 10 million requests a minute. An EdTech platform serves 250,000+ daily users. If you want a partner who has built this exact product before, that is a fair requirement and we are not it. Say so and we will tell you honestly.

You own the code and the infrastructure from day one. Geminate Solutions is a software and product development partner, which means we own delivery and you own the result. We are not a staffing agency and we do not place engineers into your team for you to manage.

If you want the drivers of effort rather than the architecture, our guide to what drives logistics software effort covers scope, integration surface and data volume in more detail. For the wider picture of what we build in this sector, see logistics software development.

Find out what your invoice run is missing

Send us one month of movements and the matching invoices. A senior engineer re-derives the charges from your own rate cards and sends back every line that does not reconcile, with the reason. No pitch, no commitment, and you keep the analysis whether or not we ever work together.

Accessorial work that happened but never reached an invoice
Clients whose contract terms have drifted from what you actually bill
Whether your WMS can export movement data clean enough to bill from
An honest answer on whether you need a build at all, or just a better export

Get your free billing leakage check

Tell us which WMS you run and your work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Lovable Authentication: What Breaks the Week Real Users Log In, and What to Fix First

Google login bounces to the preview URL, sign-ups stop confirming, a customer wants an admin, an investor asks about two-factor. Why each one happens in a Lovable app, the Supabase limits behind them, who can ignore all of it, and the order to fix it in without logging anyone out.

Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

On-Premise LLM Deployment: Do You Actually Need It?

Supabase Scaling: Which Wall You Actually Hit (2026)

What Does Lovable Actually Generate? The Answer Changed in May 2026

Next.js 16 Migration: What the Codemod Cannot Do For You

Originally published on Geminate Solutions.

Lovable Stripe Integration: What Breaks With Real Money

Geminate Solutions — Mon, 07 Sep 2026 12:15:17 +0000

Every guide to Lovable and Stripe ends at the first successful test payment. This one starts there, with the four failures that show up the week real customers pay, and the order to fix them in.

A customer paid and the app still says free. Someone cancelled in Stripe last week and still has access. Checkout worked perfectly with the 4242 test card and does nothing at all with a real one. Or the webhook function has been answering 401 since the day you published. None of those is a Lovable bug. Each one is the same missing piece: a Lovable app cannot confirm a payment by itself. Something on a server has to hear from Stripe or Paddle and write to your database, and every failure on this page is that listener missing, unverified, pointed at the wrong mode, or trusted in the wrong order.

Here is the short version. The app does not need rebuilding. Payments in a Lovable app are one product decision, one secret in the right place, one mode cutover, and one webhook handler that does four boring things correctly. All of it can be fixed in place on a live app, without a single customer noticing. This page goes through it in the order that stops money leaking first.

One thing before the detail. If you sell one digital product, have under a hundred customers, pay nobody out, and are still on Lovable Cloud, read the section on who does not need to touch any of this and probably stop there. We would rather say that now than three sections in.

Does Lovable have its own payments product, or do you still need Stripe?

It has one, since April 2026, and it is built on Stripe or Paddle underneath. So you still need a payment provider. What changed is who sets it up and who the merchant is.

Lovable Payments is the built-in feature. You ask for payments in chat, Lovable creates a Paddle or Stripe account for you, wires the checkout, the customer portal, the database tables and the webhook endpoints, and hands you a Payments tab with revenue in it. Lovable's own documentation now marks its older Stripe integration guide as deprecated and says most projects should use the built-in feature instead. That older path still exists and still matters, because a lot of live Lovable apps were wired up on it, and because the built-in feature has one requirement that rules out most apps that have already been hardened. More on that in the next section.

The two providers are not interchangeable. Paddle is a merchant of record: Paddle takes on the legal and operational responsibility for the transaction, and handles VAT, sales tax and GST in the countries it sells into. Stripe, by default, makes you the merchant. Stripe's own merchant-of-record product is called Managed Payments, it covers digital products only, and under Lovable it applies per transaction rather than automatically. If you have ever wondered why a founder in Riyadh or Singapore picks Paddle for a small SaaS, that sentence is the whole reason. Registering for tax in every country you sell into is not a feature you want to build.

One disambiguation, because it shows up in the search suggestions. Stripe Atlas is a company incorporation service. It has nothing to do with Lovable Payments, and you do not need it to take a payment.

Underneath either path is the same shape. Your app, in the browser, never touches a secret and never decides that money moved. A function running on Supabase, which is what Lovable Cloud is, holds the secret key, creates the checkout, and receives an event from the provider when the payment actually happens. Our Lovable Cloud vs Supabase guide covers who owns that backend. Keep the shape in mind, because every section below is about one of its four parts going wrong.

What does Lovable Payments decide for you, and which of it can you undo?

It decides more than the dialog lets on. Most of it is right for a small digital product. Two of the decisions you cannot undo, and one of them is made before you ever see the dialog.

The one made in advance: the built-in feature needs Lovable Cloud. Lovable's docs say built-in payments use the built-in backend for webhooks and subscription data and are not available for projects connected to your own Supabase project. If you followed a hardening guide, including ours, and moved the app onto a Supabase project you own, the built-in feature is simply not offered to you. You are on the manual Stripe path whether the docs call it deprecated or not. That is the fact the launch coverage never mentions, and it is the reason this page covers both paths.

The ones you make by accepting the defaults. Lovable creates the provider account, so on Paddle you complete their verification and domain review before selling, and on Stripe you click a link in the Payments tab to claim the account Lovable created, or link one you already have. Products and prices you create in test sync to live when you publish, discount codes do not, so a launch coupon that worked in preview has to be recreated by hand. One active subscription per user per environment by default. Lovable registers two webhook endpoints per environment on the provider account, one that feeds your app and one that sends Lovable a copy so it can watch delivery, and the docs are blunt that you must not delete or disable either of them. Test checkout accepts only test cards. A Pro plan or higher.

The ones you cannot undo. A project with payments enabled cannot be remixed, so the fork button goes away. And disconnecting is permanent: Lovable deletes your API keys, webhook secrets, environment variables and integration data from the project. A project runs one provider at a time. So a founder who starts on Paddle, grows into a marketplace and needs Stripe Connect is not flipping a switch. They are running two providers side by side while the old subscriptions lapse.

Whether any of this is a problem depends entirely on what you sell. For one digital product to consumers, Paddle as merchant of record is the best default a solo founder can get. For a company that already has a Stripe account with revenue in it, link that account and keep the history. For anything that pays a third party, read the Connect section before you accept the dialog.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

Why did a customer pay and the app still say free?

Because the app upgraded them on the success page, and the customer never reached the success page.

This is the single most common payments bug we see in AI-built apps and it is not the AI's fault. It is the obvious way to write it. Stripe redirects the customer to your success URL, the page reads the session id, the page flips a flag in the database. Stripe's own fulfilment guide says exactly why that is not enough: you cannot rely on triggering fulfilment only from your checkout landing page, because it is not guaranteed customers visit that page. They pay, their phone locks, the tab dies, the train goes into a tunnel. Stripe has the money. Your database has nothing. For subscriptions and for any payment method that confirms later, Stripe says webhooks are required, not recommended.

Lovable's deprecated Stripe guide makes this worse in a quiet way. It says webhooks are opt-in and that Lovable relies on edge-function polling unless you ask for them. Polling means the app asks Stripe on page load whether this user has paid. It works right up until the customer who paid never loads the page again, or the poll fails for a second, or two tabs poll at once. Under the built-in Payments feature Lovable registers the webhook for you. Under the manual path, if you never asked for one, you do not have one.

The fix is a webhook handler that does four things and nothing clever. Verify the request came from Stripe. Return a success status immediately, before any real work, because Stripe times out slow handlers and retries. Fulfil once per Checkout Session, by retrieving the session, checking its payment status is not unpaid, and recording that this session id has been handled, because Stripe's guide says the same function might be called multiple times, possibly concurrently, for the same session. Then act on the events that matter: checkout session completed, and for delayed methods, async payment succeeded or failed. Keep the success page too. Stripe waits up to 10 seconds for your handler before redirecting, so in the normal case the page already shows the upgrade. The page is the nice path. The webhook is the truth.

What it costs to leave it. A customer who paid and got nothing is a support ticket at best, and at worst a dispute, which is the card issuer reversing the payment and debiting your balance for the amount plus a network fee while you gather evidence. You will not see the error, because there is no error. There is a customer who stops replying.

Who does not need to touch any of this?

More people than the payments vendors would like.

If you sell one digital product, take subscriptions or one-time payments from customers who are all in the same app, pay nobody out, have fewer than a hundred paying users, and your app still runs on Lovable Cloud, use Lovable Payments and pick Paddle. Run the readiness check, which looks for a real privacy policy, terms and a refund policy on the live site. Complete Paddle's verification. Then go back to building the product, because the merchant of record just took tax, invoicing, receipts, fraud and chargebacks off your desk, and there is nothing on this page that makes that trade worse.

Do three checks first, all of them in the provider dashboard rather than in Lovable. Both webhook endpoints Lovable registered are present and enabled. Your live products and prices exist, not just the test ones. And your discount codes exist in live, because those did not sync.

Come back when one of five things happens. You connect your own Supabase project. You need to pay a third party, a seller, a coach, a driver, anything. A customer needs two subscriptions at once. Someone reports they paid and were not upgraded, or cancelled and were not downgraded. Or you have a Stripe account with history in it and Lovable's default would leave that history behind. Those are the triggers for the rest of this page, and until one fires the rest is premature.

Why does checkout work with 4242 and do nothing with a real card?

Because test mode and live mode are two different Stripe accounts wearing the same login, and the thing you tested does not exist in the one you published.

Stripe's keys page states it plainly: each mode has its own set of API keys, and objects in one mode are not accessible to the other. A product, a price, a coupon created while you were testing with the 4242 card lives in the sandbox. Swap the keys to live and your checkout code asks Stripe for a price id that, in live mode, has never been created. The call fails, the app shows a button that does nothing, and the customer with a real card leaves. Stripe's go-live checklist has a line for this: objects created in a sandbox are not usable in live mode, and when you recreate them you should reuse the same ids so the code keeps working.

The webhook has the same split. If you registered one endpoint URL and used it in both modes, Stripe's docs say the signing secret is different for each. Register the live endpoint separately and store its own secret, or every live event fails verification and your handler correctly rejects your own customers' payments. Under the built-in feature Lovable manages the two environments and syncs products and prices when you publish, which is exactly the problem it exists to remove. Discounts still do not sync, and Lovable's older Stripe guide notes that the integration does not run in preview at all, so the first time the manual path is really exercised is after publishing.

The cutover, in order, for the manual path. Recreate products and prices in live with the same ids. Register the live webhook endpoint and copy its secret into the function's secrets. Swap the publishable key in the browser to the live one, which is the only key allowed there. Swap the secret or restricted key in the function's secrets to live. Then pay yourself with a real card and refund it. Stripe keeps both keys working for up to seven days when you rotate, which is enough room to do this without an outage.

One thing that is not a bug. The test-mode banner Lovable shows in preview is hidden on the published site by design. If you see it on your live domain, you are looking at the preview, not the launch.

Why does the webhook function return 401, and where must the secret key live?

Because Supabase Edge Functions check for a Supabase login token by default, and Stripe does not have one.

This is the failure that looks most like a security setting doing its job, because it is. Supabase's docs say to keep JWT verification on so the platform validates the token before your handler runs, and then say in the same breath that external providers like Stripe or GitHub do not send Supabase credentials. They sign the request body with their own shared secret. So a webhook function deployed with the default setting rejects every Stripe delivery with 401, Stripe records a failed delivery, retries for up to three days with exponential backoff in live mode, and then gives up. Your customers paid the whole time.

The fix is two halves and you need both. Deploy the webhook function with JWT verification switched off. Then verify Stripe's signature inside the handler, because Supabase's own warning is that disabling the platform check makes your handler fully responsible for authenticating the caller. Stripe signs every event with an HMAC over a timestamp and the raw body, sends it in the Stripe-Signature header, and the official libraries check it against your signing secret with a default tolerance of five minutes. Two traps from Stripe's troubleshooting notes. The body has to be the raw bytes, so a framework that parses JSON before your code runs breaks verification. And the tolerance must never be set to zero, because zero disables the recency check and reopens replay. Supabase's example handler reads the request as text, calls the async construct-event method with a subtle-crypto provider, and carries the comment that the function should be deployed with verification off because Stripe verifies the request through its signature.

Why verification is not optional. Stripe's words: without it, an attacker could send fake webhook events to your endpoint to trigger actions like fulfilling orders, granting account access or modifying records. A webhook URL is not a secret. It is in your Stripe dashboard, your logs, and any screenshot you ever posted asking for help.

Now the key. The secret key, sk or the restricted rk form Stripe now recommends, goes in the function's secrets and nowhere else. Lovable's guide says never to paste it in chat and to use the Add API Key form, which stores it as a Supabase secret the function reads at runtime. The browser gets the publishable key, which Stripe says can identify your account and create payment methods but cannot charge anyone. We have pulled Stripe secret keys out of shipped frontends before, which our AI code audit guide describes, and a secret key in a bundle is someone else's checkout running on your account. If you are not sure where yours ended up, search the built JavaScript for the sk prefix before you read another word of this page.

Why do subscription statuses in your app stop matching Stripe?

Because the app wrote the status once, at checkout, and Stripe has changed it four times since.

A subscription is not a purchase. It is a state machine that Stripe runs on its own schedule, and Stripe tells you about each transition through events. The app that copied 'active' into a profile row on day one and never listened again will be wrong the first time a card expires. Stripe's subscription docs list the statuses: trialing, active, incomplete, incomplete expired, past due, canceled, unpaid, paused. They also say what to do with them. Provision access on invoice paid when the status is active. Ask for new card details on past due. Revoke on canceled or unpaid. An incomplete subscription has 23 hours to make its first payment before it expires and never bills. A trial ending fires an event three days out.

The pattern Stripe recommends is less code than the one that breaks. Store an access-until timestamp on the user, not a boolean. Every time invoice paid arrives, push the timestamp forward one billing period plus a day or two of grace. When the user logs in, compare the timestamp to now. Cancelled, past due and unpaid all take care of themselves, because the timestamp simply stops moving. The Lovable authentication guide covers the other half, which is that the subscription has to hang off a user id your app can trust.

Three properties of Stripe events break naive handlers, and Stripe documents all three. Events arrive out of order: creating a subscription can fire subscription created, invoice created, invoice paid and charge created in any sequence, and Stripe says not to use the created timestamp to order them because events can share a second. Events arrive more than once, so record processed event ids and skip repeats. And events keep arriving after you thought you were done, because in live mode Stripe retries a failed delivery for up to three days and lets you resend manually for 15. A handler that is safe to run twice is the only kind worth having.

The same idea protects the calls you make to Stripe, not just the ones you receive. Stripe's API accepts an idempotency key on every POST request, up to 255 characters, a random UUID is fine, and it stores the result for at least 24 hours so a retried request returns the original outcome instead of creating a second subscription. The generated code almost never sets one. A flaky connection during checkout creation plus a retry is two subscriptions for one customer, and the customer will find out before you do.

Refunds and disputes are events too. A refund issued in the Stripe dashboard fires charge refunded with the charge inside it, and a dispute fires its own event the moment the issuer reverses the payment. If your app only ever listens for the happy path, the refunded customer keeps the product and the disputed one keeps it while you lose the evidence window. Under Paddle as merchant of record, refunds and chargebacks are Paddle's to handle, which is the honest reason to choose it when you have no one to handle them.

When do you need Stripe Connect instead of one Stripe account?

The moment any of the money is not yours.

One Stripe account can take a payment from a customer and put it in your balance. It cannot split that payment with a seller, a tutor, a driver, a clinic or a creator. Stripe's Connect docs describe it as building a platform, marketplace or other business that manages payments and moves money between multiple parties, and the marketplace pattern specifically as collecting from customers and automatically paying out a portion to sellers or service providers. That is a different product with connected accounts, onboarding, and its own webhook scope for events from those accounts.

Neither easy path gets you there. Lovable Payments is a single-merchant setup. Stripe's Managed Payments, the merchant-of-record option, lists Connect explicitly among the integrations it does not support. So a founder who built a marketplace in Lovable and accepted the Payments dialog has a checkout that works and a payout model that does not exist. Sometimes the workaround is honest: take the full amount, pay the sellers by bank transfer at month end, and call it a service business for a while. Sometimes it is a marketplace pretending not to be one, and the sellers notice at tax time.

If you are paying anyone out, the decision is not Lovable Payments or your own Stripe. It is your own Stripe with Connect, from the start, on a backend you control, with the webhook listener registered for connected accounts as well as your own. That is a week of careful work, not a rebuild, and it is the one section of this page where the answer really is to plan before you accept a default.

When it is worth handing this to someone

The moment someone else's money moves through code nobody has read.

If the disqualifier section described you, pick Paddle, run the readiness check, do the three dashboard checks and go. If one of the five triggers has fired, the work on this page is a few days of careful configuration and testing for someone who has done it before, and weeks of guesswork for someone who has not, because none of it fails loudly. A handler with no signature check accepts everything. A live checkout pointing at a test price shows a button. A subscription that never listens again stays 'active' forever. The only test that proves any of it is to pay yourself with a real card, cancel, wait for the event, and watch the database.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can be charged through them, and we do not sell rebuilds. Your Lovable app stays your Lovable app. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs. If the webhook is fine and it is the rest of the backend that is creaking, the Lovable backend solutions guide is the sibling to this one, and the production checklist for Lovable apps is the hub both of them hang off.

The first step is a written review of what your payments setup will and will not hold. Which path you are actually on. Where the secret key lives. Whether the live products and the live endpoint exist. Whether the handler verifies and deduplicates. And what happens to a user the day Stripe says they stopped paying. We send it back within 48 hours and it stays yours whether or not we ever talk again.

Frequently Asked Questions

Does Lovable Payments cost more than using Stripe or Paddle directly?

No. Lovable's documentation says using Stripe or Paddle through Lovable costs the same as setting up the provider directly, with no markup from Lovable. You pay the provider's own rate either way. What differs is who is the merchant of record and who owns the account, not the fee.

Can I move from Lovable Payments to my own Stripe account later?

Partly. On the Stripe path you claim the account Lovable created, so it is already yours, or you link an existing one. On the Paddle path Paddle is the merchant of record, so the sales are legally Paddle's and your subscribers stay with Paddle. Disconnecting is permanent: Lovable deletes the keys, webhook secrets and integration data from the project, and a project runs one provider at a time. Plan a switch as a period of running both, not a cutover.

Can a Lovable app take payments without user accounts?

One-time payments, yes. Subscriptions, not sensibly. A subscription has to belong to someone your app can recognise next time they log in, which is why Lovable recommends adding authentication before payments, and why its built-in feature allows one active subscription per user per environment by default.

Will resending a Stripe event or fixing the webhook double-fulfil an order?

Only if the handler is not idempotent. Stripe delivers events more than once and out of order by design, so the handler must record processed event ids and fulfil once per Checkout Session id. Once that is in place you can resend any event from the Dashboard, which Stripe allows for up to 15 days, and nothing doubles.

Do I still need to verify the webhook signature if Lovable set everything up?

Yes, and you should check rather than assume. Ask Lovable to show you the line in the handler that verifies the Stripe-Signature header against the signing secret. If it is not there, that is the first fix. Without it anyone who finds the endpoint URL can post a fake payment event and grant themselves access. Either way, never delete the endpoints Lovable registered in the provider dashboard.

Send us the live URL of your Lovable app. A senior engineer works out which payments path you are on, checks where the secret key lives, whether live products and the live endpoint exist, whether the webhook handler verifies and deduplicates, and what happens to a user when Stripe says they stopped paying. Then writes back with what will hold and what will not. No pitch, no commitment.

Whether a real customer's payment reaches your database even if they never see the success page
Whether your secret key is anywhere a browser can read it
Whether cancellations, failed renewals and refunds change what the user can access
An honest answer if Lovable Payments with Paddle is all you need

Get your free payments readiness review

Drop your app s URL and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Lovable Authentication: What Breaks the Week Real Users Log In, and What to Fix First

Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

On-Premise LLM Deployment: Do You Actually Need It?

Supabase Scaling: Which Wall You Actually Hit (2026)

What Does Lovable Actually Generate? The Answer Changed in May 2026

Next.js 16 Migration: What the Codemod Cannot Do For You

Originally published on Geminate Solutions.

Lovable SEO: Why Your Live App Is Not Showing on Google

Geminate Solutions — Mon, 07 Sep 2026 12:15:09 +0000

Every page about Lovable SEO is written by someone selling one of three answers. This one separates a settings problem from a rendering problem from plain waiting, using Google s own verdicts, so you buy the right fix once.

You searched your own product name and Google found nothing. Or it found the homepage, with the wrong title, and none of the other pages. A free SEO scanner told you the site is an empty shell with no content. And somewhere in your inbox an agency is explaining that Lovable apps cannot rank and you need to rebuild in Next.js or Webflow. Three of those four things have nothing to do with each other, and the fourth is usually wrong.

Here is the short version. A Lovable SEO problem is one of three different problems wearing the same symptom. The app is not indexed at all. Or it is indexed with the wrong titles, descriptions and canonical tags, which is a settings problem you fix with a prompt. Or it is indexed correctly and Google is simply not ranking a young domain yet, which is a waiting problem no tool fixes. Each one has a different test, and the test is Google's URL Inspection tool, not a third-party scanner and not the site: operator.

The scanner deserves its own sentence, because it is the source of most of the panic. On the older Lovable stack, Google gets a pre-rendered page and the scanner gets an empty shell. Both are telling the truth about what they received. Only one of them decides whether you rank. The rest of this page is about working out which of the three problems you have, and who should do nothing at all.

Is your Lovable app not indexed, or indexed and not ranking?

Those are two different problems with two different fixes, and searching for your own brand name does not tell you which one you have.

Start with the one hard requirement. Lovable's documentation says that only publicly published apps can be indexed by search engines. An app published to your workspace, or one that greets every visitor with a login screen, is invisible to Google by design, and nothing further down this page applies to it. If your app is public, carry on.

Now open Google Search Console, verify the property if you have not already, and paste one URL into the URL Inspection bar at the top. Not the homepage. Pick a page that matters, a pricing page, a feature page, a listing. The verdict comes back in a few seconds and it is one of a small set of phrases. 'URL is on Google' means indexed. Your problem, if you have one, is ranking, and the sections on titles and on young domains are the ones to read. Anything else means not indexed, and the exact wording tells you why. 'Crawled, currently not indexed' means Google fetched the page, read it, and declined for now. 'Discovered, currently not indexed' means Google knows the URL exists and has not fetched it yet. 'Excluded by noindex tag' means the page told Google to stay away. 'Duplicate without user-selected canonical' means Google thinks this page is a copy of another one and picked the other one.

The site: operator is a rough filter and no more. It shows what Google chose to display for that query on that day, and it hides pages it considers near-duplicates. We have watched people conclude a site was deindexed because site: showed four pages when Search Console showed forty. Use it to get a feel. Use URL Inspection to get a verdict.

One more thing before you trust the numbers. Lovable's own Search Console documentation notes that the data is typically delayed by a couple of days, and Google's Page indexing report carries a last-updated date at the top. Read that date. A fix you published on Tuesday cannot show up in a report stamped Monday, and a lot of fixes get declared failures for that reason alone.

Why does your SEO scanner say the site is an empty shell when Google says it is fine?

Because on the older Lovable stack, Google and the scanner were served two different pages, and the scanner is reporting the one it got.

This is the load-bearing fact on this whole topic and it appears on almost none of the pages that rank for it. Lovable's SEO documentation says that apps created from 13 May 2026 use TanStack Start with server-side rendering, so every visitor and every bot receives finished HTML and none of this section applies. Older React and Vite apps work differently. Lovable's docs describe on-request pre-rendering on deployed public URLs, served only to verified search and AI crawlers, and the doc names them: Google, Bing, social-preview bots, and AI engines including ChatGPT, Perplexity, Claude and Gemini. Then it says the part that matters here. Third-party SEO scanners and other unverified agents see the regular single-page app shell, not the pre-rendered HTML.

So when a free audit tool fetches your site, it identifies itself as whatever it is, Lovable does not recognise it as a verified crawler, and it receives a page with a root element and a script tag. It reports zero words, no H1, no meta description, and a red score. That report is accurate for that tool. It says nothing about what Googlebot received, because Googlebot is verified and received the rendered page. The same goes for a curl command, a link checker, and the 'view as bot' feature in most SEO suites. None of them are Google.

What to trust instead. In Search Console, run URL Inspection on the page, then click 'Test live URL' and open 'View tested page'. That is the HTML Google rendered from your site a moment ago, and Google's own JavaScript SEO guide points you to exactly this, the URL Inspection tool and the Rich Results Test, to see what Googlebot sees. If your words are in that HTML, your rendering is not the problem, whatever the scanner said. If they are not, and you are on the older stack, read the section on upgrading.

The stakes are not abstract. We have seen founders spend the week before a launch arguing with a scanner, then pay for a prerendering service, then start a rebuild conversation, on the basis of a report about a page Google never saw. Meanwhile the real problem, four routes sharing one title, sat in the Search Console report unread. Buying the wrong fix is bad. Buying it twice, with an investor asking why the product is not on Google, is what this page exists to prevent.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

Why does every page of your Lovable app show the same title in Google?

One title, one description and one canonical tag were generated for the whole site, and nobody asked for more.

Lovable's SEO documentation says it plainly. Sitemaps, robots.txt, metadata and other SEO elements are not always generated up front. The publish flow generates a site title, a description and an icon for the app as a whole. Per-page metadata, the thing Google's guide calls unique, descriptive titles and meta descriptions, has to exist per route, and on a generated app it often does not. Lovable's own SEO review names the findings you will recognise from your Search Console report: duplicate titles across routes, canonical URLs that point to the homepage, and shared links that still show Lovable's branding instead of yours.

The canonical one is the quiet killer. A canonical tag tells Google which URL is the real version of a page. If every route carries a canonical pointing at the homepage, you have told Google that your pricing page, your features page and your blog are all copies of the homepage. Google believes you. The pages show up in the Page indexing report as 'Duplicate without user-selected canonical' or as alternates of the homepage, and no amount of resubmitting changes that, because you are asking Google to index a page you have labelled a duplicate.

This is a settings problem and it is fixed with a prompt, not a migration. Ask Lovable for a unique title and meta description on every public route, a self-referencing canonical on each page, per-route Open Graph tags, and a sitemap that lists the real URLs. Since 26 August 2026, Lovable shows Social and Search cards for each page before you publish, so you can see the title, description, image and favicon per route and catch a duplicate before Google does. Then publish, because the fix does not exist on the live site until you do, and wait for the report's date stamp to move past your publish date before judging it.

One trap that catches people who did everything right. If you fixed the titles and Google still shows the old one, remember that Google rewrites titles it thinks are poor, and that its cache of your page updates on its crawl schedule, not yours. Inspect the live URL, confirm the new title is in the rendered HTML, and then give it days rather than hours.

Is this a prompt-fixable problem or a rendering problem?

Most of the time it is prompt-fixable, and the way to know is to match what URL Inspection shows against the table below.

The rendering question itself, which stack your project is on and how to tell in two minutes, is covered in our guide to what Lovable actually generates, along with the View Page Source test and what the server-rendering difference means for link previews and AI crawlers. This page does not repeat it. What this page adds is the decision. Take the symptom you have, look at what URL Inspection told you, and read across.

Notice how much of that table is settings and time, and how little is rendering. That is the shape of the problem. The one rendering row is real, and the upgrade section covers it, but it is one row. If someone has looked at your app for thirty seconds and told you the whole thing needs to move to another framework, ask them which row of the table they think you are on.

Who does not need to do anything about this?

A larger group than the vendors on this search result would like.

If your app sits behind a login, stop reading. Internal tools, admin panels, client portals and dashboards are not going to be indexed and should not be. If you are pre-launch, also stop. Rendering and metadata are problems you earn by having a public product with an audience, and a site nobody links to yet has nothing to rank with. Our guide to what Lovable generates covers both of those cases in more detail and we will not repeat it.

Two more groups belong here and they are specific to this page. First, if your project was created on or after 13 May 2026, or you already ran the TanStack Start upgrade, and URL Inspection shows a unique title on each page, you have no SEO fault to fix. You may have no rankings yet. Those are different things, and the section on young domains is the only one you need.

Second, if the app is under about six weeks old, is publicly published, has a submitted sitemap, and every page you inspect comes back 'URL is on Google' or 'Discovered', do nothing for now. Lovable's documentation says indexing can take from a few hours to a few days and sometimes longer depending on Google's crawl schedule. Our experience with young domains is that the longer end is normal. Fixing a problem you do not have, on a site Google has not finished reading, is how people turn a waiting problem into a rendering migration on launch week.

Come back when one of four things happens. URL Inspection shows the same title on more than one route. A page you care about reads 'Crawled, currently not indexed' for longer than a month while the sitemap is submitted and the page is linked from your own navigation. The rendered HTML in URL Inspection is empty. Or search is a real acquisition channel for the business and you are past the point where waiting is a strategy.

Why is a correctly built Lovable app still not indexed after six weeks?

Indexing is a decision Google makes about whether a page is worth keeping, not a technical handshake. A young domain has given it very little to go on.

Google's own definitions are worth quoting, because they are blunter than most of the advice built on top of them. 'Discovered, currently not indexed' means the page was found by Google but not crawled yet, usually because Google postponed the crawl to avoid overloading the site. 'Crawled, currently not indexed' means the page was crawled by Google but not indexed, that it may or may not be indexed in the future, and, in Google's words, that there is no need to resubmit this URL for crawling. Read that last clause twice. Resubmitting does nothing. It is the button everyone presses and it changes nothing about the decision.

We can say what that verdict means from the inside, because our own site is sitting in it. At the time of writing, 184 pages on this domain show 'Crawled, currently not indexed', on a domain with roughly 14 referring domains. Every one of those pages renders perfectly. Google fetched them, read them, and declined. The pages are fine. The domain has not earned enough trust for Google to spend index space on pages that target queries with almost no demand. That is not a rendering problem or a settings problem, and no prompt fixes it. What moves it is fewer, better pages that answer a real question, and links from sites Google already trusts. Slowly.

Two Lovable-specific notes. The Google Search Console connector is useful and also narrower than people assume. Lovable's documentation says only the meta-tag verification method is supported through it, DNS records, HTML file upload and Google Analytics verification do not work, and that the connector cannot request indexing for a URL. It can submit and manage sitemaps and read their status, which is genuinely handy. Requesting indexing, for the few cases where it helps, such as after removing a noindex tag, is done by hand in Search Console. And, a view of ours rather than a documented rule, a custom domain gives Google a cleaner entity to build trust around than a shared subdomain does. Get the domain first and verify that, so the history you build attaches to something you own. Our Lovable authentication guide covers the custom-domain switch and what it breaks in login flows, which is the other reason to do it early rather than late.

The hard truth, stated without a sales pitch behind it. A correctly built app that is not indexed after six weeks is usually an app with no links, on a domain with no history, targeting queries where established sites already answer the question. The fix is the unglamorous one. Write the two or three pages that answer what your customers actually search, get mentioned by a few sites that matter in your niche, and give Google a reason. Every tool that promises a shortcut is selling you around a decision only Google makes.

Should you install a prerendering proxy on a Lovable app?

On Lovable hosting, no. It solves a problem the scanner invented.

A prerendering proxy sits in front of your site, detects bots, renders the page in a headless browser, and serves the resulting HTML to them. It is a reasonable tool for a single-page app hosted somewhere that does nothing for crawlers. But that is not your situation on Lovable hosting. Lovable already does exactly this for verified crawlers on the older stack, and the newer stack renders on the server for everyone. Adding a proxy in front of it does not give Google anything it was not already getting. It gives the scanner a nicer report, at a monthly fee, forever.

The situations where the question is real are the ones where you have left Lovable hosting. If you exported the code of an older Vite project and deployed it yourself, on Netlify, Vercel, Cloudflare or a VPS, then you left Lovable's crawler pre-rendering behind with it, and now your single-page app really is a shell to every bot. At that point you have three options. Run the TanStack Start upgrade inside Lovable before you export, so what you deploy is server-rendered. Add a prerendering step to your own build, so the public routes are generated as static HTML at deploy time. Or put a proxy in front of it and pay the fee. The first is the cleanest if you are still in Lovable. The second is what we would do with an exported codebase. The third is a bandage that works and that you will eventually want to remove.

One test settles whether you need any of them. Run URL Inspection, view the tested page, and look for your content. If it is there, you do not need a proxy, whichever host you are on.

When does a Lovable SEO problem mean upgrading to TanStack Start, or leaving?

Upgrade when the rendered HTML in URL Inspection is empty, or when link previews and AI crawlers matter to your business and you are on the older stack. Leave almost never, and not for this reason.

The upgrade is an in-product migration. Lovable's documentation says you can start it from the chat by typing a slash and choosing Migrate to TanStack Start, from project settings under project actions, or by asking Lovable in plain language. It moves your page titles, descriptions, social preview tags and analytics scripts into the new template, keeps your design and content, and usually takes several minutes, longer than a typical request. It runs as normal chat work, so it uses credits like any other request. Your published site is untouched until you publish again. And it is reversible: find the version before the upgrade in your project's version history and restore it. Lovable's own warning is that some code libraries only work in the browser and can break server rendering in ways the upgrade's checks may not catch, so test every page after it runs. Our guide to what Lovable generates explains what actually breaks and how that gets fixed.

For SEO specifically, the upgrade changes one thing and it is the right thing. After it, every request, from a browser, from Googlebot, from a Slack unfurl, from a scanner, receives the same finished HTML with the page's own title and description in it. The scanner-versus-Google split from earlier disappears. Per-route metadata becomes ordinary server-rendered tags rather than something a script writes into the document after load. That is the whole SEO case for it, and it is a good case if you are on the older stack with a public site.

What it does not do is the other half of this page. It does not write unique titles you never asked for, though it carries across the ones you have. It does not earn links. It does not age your domain. An upgraded app with duplicate titles still has duplicate titles, and an upgraded app on a six-week-old domain still waits. If URL Inspection already shows your content and your titles, the upgrade is not your SEO fix, and anyone telling you it is has not looked.

Leaving Lovable for Next.js, Astro or a CMS is a rebuild, and a rebuild is what the agencies on this search result are selling. There are real reasons to leave a builder eventually, and our production readiness guide for Lovable apps lays them out. Search indexing is not on that list any more. If the only evidence for a rebuild is a scanner screenshot and a promise about rankings, keep your app and fix the row of the table you are on. If a rebuild does turn out to be right for other reasons, our Lovable backend guide and Lovable Cloud versus Supabase cover what you carry with you and what you leave behind.

What does the fix look like, in order?

In the order that rules things out fastest, so you stop before spending on a step you do not need.

Confirm the app is publicly published. Not internal, not behind a login for the pages you want found. Lovable's docs say only publicly published apps can be indexed.
Put it on your own domain and verify that domain in Search Console. Use the connector if you like, remembering it only supports meta-tag verification, or do it by hand. Use the same site identifier, trailing slash included, everywhere.
Inspect three URLs, not one. The homepage, one page you want to rank, and one deep page. Write down the verdict for each. This is the diagnosis and everything after it depends on it.
View the tested page for each. If your content is in the rendered HTML, rendering is not your problem, whatever any scanner says. Skip step eight.
Fix metadata with a prompt. Unique title and description on every public route, a self-referencing canonical on every page, per-route Open Graph tags, and no leftover noindex. Check the Social and Search cards per page before publishing.
Generate and submit the sitemap. Real URLs only, no drafts, no login-gated routes. Submit it in Search Console or through the connector, then read the sitemap status for errors.
Publish, then wait for the report date to pass your publish date. Judge nothing before that. Request Indexing only on a URL where you removed a noindex or fixed a real error, because Google says a crawled and declined page does not need resubmitting.
Only if rendered HTML was empty: run the TanStack Start upgrade. On a branch, test every page for browser-only libraries, then publish. It is reversible from version history.
If pages are indexed and not ranking, stop touching the app. Write pages that answer the questions your buyers type, and earn a handful of real links. Give it weeks, not days. Steps one to seven are an afternoon for someone who has done it before, and no engineering is involved. Step eight is the only technical step and most readers will never reach it. Step nine is the slow part, and it is slow for everyone, on every stack, on every builder.

When it is worth handing this to someone

When you cannot tell which row of the table you are on, and the cost of guessing wrong is a launch week spent on the wrong fix.

If the disqualifier section described you, close this tab and go back to the product. If you got as far as step four and your content was in the rendered HTML, do steps five to seven yourself. They are prompts and a sitemap. The people who should hand this over are the ones whose rendered HTML came back empty and who have a live app with users on it, because the upgrade is easy to start and the breakages after it are the part that takes judgement, and the ones who fixed everything correctly, waited, and are being told by a vendor that the remaining silence is a technical fault. Sometimes it is. Usually it is a young domain, and the honest thing to say is wait and build, not buy.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can find, use and pay through them, and we do not sell rebuilds. Your Lovable app stays your Lovable app. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs, and the production checklist for Lovable apps is the hub this page hangs off.

The first step is a written indexing review of your live URL. We fetch it as a browser and as Googlebot and compare the two. We inspect the pages that matter, read the titles, canonicals, sitemap and robots file, and tell you which of the three problems you have and which fix it needs, including the answer nobody sells, which is that you need to wait. We send it back within 48 hours and it stays yours whether or not we ever talk again.

Frequently Asked Questions

Can Google index a Lovable app at all?

Yes. Apps created from 13 May 2026 are server-rendered, so Google receives finished HTML. Older React and Vite apps are pre-rendered on request for verified crawlers, Google included, according to Lovable's documentation. The condition is that the app is publicly published. An internal or password-protected app cannot be indexed however it is built.

Why does my SEO tool say my Lovable site has no content?

Because on the older stack Lovable serves the pre-rendered HTML only to verified search and AI crawlers. Lovable's docs say third-party SEO scanners and other unverified agents see the regular single-page app shell. The scanner is reporting what it received, which is not what Google received. Check Google's URL Inspection tool instead, which shows the HTML Google actually rendered.

Does the Lovable Google Search Console connector request indexing for me?

No. Lovable's documentation says the connector cannot request indexing for a URL. It can verify the site, but only by the meta-tag method, and it can submit sitemaps and read sitemap status. Requesting indexing is done by hand in Search Console, and Google says there is no need to resubmit a URL that is crawled and not indexed.

Will upgrading my Lovable app to TanStack Start fix its SEO?

It fixes the rendering half. After the upgrade every visitor and every bot receives the same finished HTML, and per-page titles and descriptions become ordinary server-rendered tags. It does not create demand for your pages, earn links, or make a young domain trusted. If URL Inspection already shows your content, the upgrade is not the fix for a page that is indexed and not ranking.

Should I move my Lovable app to Next.js or Webflow for SEO?

Rarely, and never as the first step. A settings prompt fixes duplicate titles and a homepage canonical. The in-place TanStack Start upgrade fixes client-only rendering and is reversible from version history. A move to another framework is a rebuild, and if a scanner report was the only evidence, the rebuild is being sold to fix a problem Google never had.

Send us the live URL of your Lovable app. A senior engineer fetches it as a browser and as Googlebot, inspects the pages that matter, reads the titles, canonicals, sitemap and robots file, and writes back with which of the three problems you have and which fix it needs. If the honest answer is wait, we say wait. No pitch, no commitment.

Whether Google is receiving your content, regardless of what a scanner told you
Whether your routes share one title or one canonical, and the prompt that fixes it
Whether a page is not indexed or indexed and not ranking, and what each one needs
An honest answer if the right move is a settings prompt and six weeks of patience

Get your free indexing review

Drop your app s URL and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Node.js AI Integration: Adding AI to a Live App Without a Rewrite or a Second Stack

The tutorial says stand up a Python service. The prototype took thirty seconds and the bill doubled in month two. Which integration path fits a live app, streaming inside an existing Express route, the SDK defaults to change, 429s, cost caps, and keeping customer data out of prompts.

Lovable Payments or Your Own Stripe: What Breaks the Week Real Money Arrives, and What to Fix First

A customer paid and the app still says free, a subscription cancelled in Stripe and the user kept access, checkout works with 4242 and not a real card, the webhook returns 401. What Lovable Payments decides for you, who can ignore all of it, and the order to fix it in without a rebuild.

Lovable Authentication: What Breaks the Week Real Users Log In, and What to Fix First

Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

On-Premise LLM Deployment: Do You Actually Need It?

Supabase Scaling: Which Wall You Actually Hit (2026)

Originally published on Geminate Solutions.

Node.js AI Integration: Add AI to a Live App, No Rewrite

Geminate Solutions — Mon, 07 Sep 2026 12:15:01 +0000

Every Node.js AI integration guide starts a fresh project and ends at the first completion. This one starts from a live app with users on it, and covers the eight things that break after the demo.

Your product runs on Node. The team wants a summarise button, a smart search, a draft-this-reply feature. The first tutorial you opened told you to stand up a Python service. The prototype endpoint you built instead takes thirty seconds to answer and the invoice for it doubled between the first month and the second. None of that means you picked the wrong stack. It means the tutorials stop where the real work starts.

Here is the short version. Calling a model is an HTTP request, and Node.js is the runtime built for waiting on HTTP requests. You add the feature inside the app you already have, in the route you already have, with the provider's own Node SDK or a thin layer over it. The part that separates a demo from a feature is not the call. It is streaming so the user sees the first word in under a second, a timeout that is not the SDK's ten-minute default, a retry policy that does not double your bill during an outage, a cap so one user cannot spend the month's budget, and a rule about which customer data is allowed into a prompt.

This page is for a live app, with users on it, adding its first or second AI feature. If you are starting a fresh product and the AI is the product, some of this still applies and a lot of it is premature. And if you are building an agent, something that loops and decides its own next step, our Node.js AI agent guide is the right page and this one hands off to it at the end.

Do you need a Python service to add AI to a Node.js app?

No. And the advice that you do deserves a fair hearing, because it is not wrong so much as aimed at someone else.

Python earned its place in machine learning because training and fine-tuning models, running numerical code, and working with the research libraries all happen there. If your team is going to train anything, Python is the right room to be in. Adding a feature that calls a hosted model is a different job. The model lives on the provider's servers. Your code sends text over HTTPS and reads text back, sometimes as a stream. OpenAI, Anthropic and Google each publish an official Node.js SDK for exactly that, and the Node SDKs carry the same streaming, retry, timeout and tool-calling features as their Python counterparts. Anthropic's TypeScript SDK documentation lists Node.js 20 LTS and later, Deno, Bun, Cloudflare Workers and the Vercel Edge Runtime as supported, and the OpenAI Node README documents the same retry and timeout controls this page quotes further down.

What a second service costs you is the part the tutorial never prices in. A Python service next to a Node app is a second deployment, a second set of secrets, a second place logs go, a second on-call surface, and a network hop between your request handler and the model call that now has its own timeout to get wrong. For a team that already runs Node in production, that is a real weight to carry for a feature that is, underneath, one HTTP call.

The exception is honest and narrow. If the feature needs a model that only runs locally, or a numerical pipeline that only exists in Python, you will end up with a Python process somewhere. Put it behind a queue, treat it as a worker rather than a request-time dependency, and keep the user-facing route in Node. Our guide to on-premise LLM deployment covers when that is worth doing. For a hosted model, which is what nearly every first feature uses, stay in Node.

Which integration path fits a live app: raw fetch, a provider SDK, or a provider-agnostic layer?

For one feature on one provider, the provider's SDK. For several features or a provider you expect to swap, a thin agnostic layer. Raw fetch only for a tool with a cap and no customers.

There are three ways to make the call, and picking one is mostly a question of how many features you will have in a year and how much of the plumbing you want to own.

Two things the table cannot say. First, the provider SDKs are more alike than different, so choosing one is not the lock-in it looks like. Both the OpenAI and Anthropic Node SDKs stream with an async iterable, retry the same classes of error twice by default, time out after ten minutes by default, and expose typed error classes. Swapping later is a day of work in a well-factored route, not a rewrite. Second, the agnostic layer is worth it when it is replacing plumbing you would otherwise write three times. The AI SDK's core documentation describes generateText for one-shot calls and streamText for real-time ones, exposes the result as a textStream that is both a ReadableStream and an async iterable, and ships helpers to pipe that stream into a Node response. If you are writing that glue for a second feature, stop and adopt it.

Whichever path you pick, put the call behind one function of your own with one signature: a feature name, a user id, the input, and an options object. Every section below adds something to that function. If the model call is scattered across six routes, none of them can be added.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

How do you stream a model response inside an existing Express route?

Set the headers, flush them, write each chunk as it arrives, honour backpressure, and abort the upstream call when the client goes away. The event loop is never blocked, because the work is waiting, not computing.

A model reply can take ten to thirty seconds to finish, and a route that awaits the whole thing before writing anything gives the user a blank screen for all of it. Streaming fixes that without any change to your architecture. Both provider SDKs return an async iterable when you pass stream: true, and Anthropic's documentation notes that this form uses less memory than the helper that accumulates a final message for you. The shape of the route, with the details that matter, looks like this.

app.post('/api/summarise', async function (req, res) { const stream = await client.messages.create( { model: MODEL, max_tokens: 600, stream: true, messages: [{ role: 'user', content: buildPrompt(req.body) }] }, { timeout: 30 * 1000, maxRetries: 0 } ); req.on('close', function () { stream.controller.abort(); }); res.setHeader('Content-Type', 'text/plain; charset=utf-8'); res.setHeader('Cache-Control', 'no-store'); res.flushHeaders(); try { for await (const event of stream) { const text = textDeltaOf(event); if (text && !res.write(text)) { await new Promise(function (resolve) { res.once('drain', resolve); }); } } res.end(); } catch (err) { if (!res.headersSent) return res.status(502).end(); res.end(); } });Five lines in there are the ones the tutorials leave out. The per-request timeout of thirty seconds replaces a default of ten minutes. maxRetries is zero on a streamed, user-facing call, because a retry after the first chunk has been written cannot be made invisible to the user, so it is better to fail fast and let them click again. The close handler aborts the upstream request when the browser tab is shut, which Anthropic's SDK documents as stream.controller.abort() and which stops you paying for tokens nobody will read. The drain wait is backpressure: res.write returns false when the socket buffer is full, and a route that ignores that on a slow mobile connection grows memory until the process falls over. And the catch branch has to handle two different worlds, before headers are sent and after, because once the stream has started you cannot change the status code.

If you sit behind a reverse proxy, check that it does not buffer the response, or the stream arrives all at once at the end and you have gained nothing. And if the route already has a body parser with a size limit, keep it. A prompt built from an unbounded request body is the cheapest way for a user to run up your bill, which the cost section comes back to.

Who does not need any of this?

More teams than the agencies ranking for this query would like to admit.

If the feature is an internal tool, used by your own staff, calling the model a few hundred times a day at most, and never touching customer data, do this instead. Use the provider SDK, set a thirty-second timeout, set a monthly spending limit in the provider's dashboard, and ship it. You do not need streaming, a cost model, an eval suite or a vendor abstraction. You need the button to work by Friday.

If you are pre-launch and the AI feature is the product, most of this page is also premature. Get the prompt right, get users, find out whether the feature is the reason they stay. The cost and rate limit sections become real the day a second customer signs up, and not before.

Come back when one of five things happens. A customer sees the feature. The request handler starts holding connections open for longer than your load balancer allows. The invoice moves in a direction you did not predict. Someone asks what happens to the data you send the provider. Or the feature grows a second step, where the model's first answer decides what the code does next. Those are the triggers for the rest of this page, in roughly that order.

How do you set timeouts and retries so one slow call cannot take the app down?

Change the defaults, because they were chosen for a script that can wait, not for a request handler that cannot.

Both SDKs document the same starting point. The OpenAI Node README says requests time out after 10 minutes by default, and that certain errors are automatically retried 2 times by default with a short exponential backoff: connection errors, 408 Request Timeout, 409 Conflict, 429 Rate Limit and 5xx errors. Anthropic's TypeScript SDK documentation says the same, 10 minutes and 2 retries on the same classes of error, and adds that when you set a large max_tokens without streaming, the default timeout is calculated dynamically and can reach 60 minutes. Both expose a timeout option and a maxRetries option, per client and per request.

Do the arithmetic for a request handler. A slow upstream call, a ten-minute timeout, and two retries is thirty minutes during which one HTTP request is held open, one worker is occupied, and, on the retries, tokens are being charged twice or three times for an answer the user gave up on twenty-nine minutes earlier. Multiply by every user who clicked the button during a provider incident. That is how an AI feature takes down a Node app that was fine before it, and it happens without any error in your own code.

The settings that hold up. For a user-facing route, a timeout of twenty to forty seconds, streamed, with retries off, because a retry on a stream is visible. For a background job, a queue worker, a nightly classification run, keep the two retries and let the timeout be generous, because nobody is waiting and a retry is invisible. Anthropic's SDK also throws an error if a non-streaming request is expected to run past roughly ten minutes, and its documentation says to use streaming for long requests, because some networks drop idle connections. Take the hint. Anything that might run long streams, even if the consumer is a job and not a person.

Two details, one line each. On timeout, Anthropic's SDK throws an APIConnectionTimeoutError, and the timed-out request is retried by the SDK's own default policy, so if you leave maxRetries at 2 a timeout is not one wait but three. And both SDKs attach a request id to every response, on Anthropic as a _request_id property read from the request-id header. Log it on every failure. It is what the provider will ask you for, and without it a support conversation about a bad answer goes nowhere.

What happens when the provider returns 429, and what do you do about it?

The SDK retries it twice with backoff, and then it is your problem. The fix is to read the headers, queue the work you can, and shed the work you cannot.

OpenAI's rate limits guide measures limits in several units at once: RPM, requests per minute, RPD, requests per day, TPM, tokens per minute, TPD, tokens per day, and IPM for images. You can run out of any of them independently, and a feature that makes few requests with long prompts hits the token limit long before the request limit. Anthropic's SDK surfaces a 429 as a RateLimitError, one of the typed subclasses of APIError, with the status and headers attached, so you can catch that class specifically instead of string-matching a message.

The headers are the useful part. OpenAI documents x-ratelimit-limit-requests, x-ratelimit-remaining-requests and x-ratelimit-reset-requests, the same three for tokens, and project-scoped token versions. A route that reads the remaining count on every response knows it is about to be throttled before it is. Its guide says this about the backoff itself: wait at least as long as the reset header says, and add a small random delay so multiple clients do not retry at the same time. That jitter is the difference between a limit clearing and a thundering herd that keeps it pinned.

What to do with the work. User-facing calls should fail fast with a message the user can act on, not sit in a retry loop. Background work should go on a queue with a concurrency limit set below the provider's RPM, so the queue absorbs the burst and the provider never sees it. OpenAI's guide names two more levers that both reduce load and cost: set max_tokens as close to your expected response size as possible, and, when you have token headroom but no request headroom, batch several tasks into one request. For work that does not need an answer today, both providers offer a batch API. Anthropic's SDK exposes it under messages.batches with a custom_id per request and results you iterate once processing has ended. Nightly classification of a backlog belongs there, not in your request handlers.

How do you keep the bill from surprising you in month two?

Measure per request, cap per user and per feature, keep answers short, put the stable part of the prompt first, and send easy tasks to a smaller model. All of it in week one, because none of it is fun to retrofit.

The bill doubles in month two for an ordinary reason: month one was the team testing, month two was customers. Nothing was wrong. Nobody was measuring. Both SDKs return a usage object on every response, Anthropic's documentation shows it as input_tokens and output_tokens, and the single most valuable line of code in an integration is the one that writes those two numbers to your database with a user id, a feature name and a timestamp. Once that exists, every question about cost has an answer, and a cap becomes a query.

Caps go in the route, not in the dashboard. The provider's monthly spending limit is a fuse for the whole company, and when it blows every feature dies at once, usually at the end of the month when it hurts most. A per-user daily cap and a per-feature monthly cap, checked in your own function before the call is made, degrade one user or one feature and leave the rest running. Pair them with a request body limit, because the cheapest attack on an AI feature is a user pasting a book into the summarise box.

Then the levers that reduce the number itself. max_tokens first, because you pay for every output token and a summary that needs two hundred does not need a limit of four thousand. Prompt caching second. OpenAI's guide explains that the provider preserves the model's intermediate state for a reusable prefix, that the minimum prompt length for caching is 1,024 tokens on current models, that cached input tokens are charged at a tenth of the standard rate, that a cache persists for thirty minutes after its last use, and that the usage response reports what was reused under input_tokens_details.cached_tokens. The practical rule is the same on every provider that offers it: system instructions, examples and reference material go first and never change between calls, the user's input goes last. A prompt that puts the changing part first gets no cache hits, and the bill shows it. Model routing third. Classification, extraction and short rewrites do not need the largest model, and a route that picks the model by feature is one line once the call sits behind your own function. Our Claude API guide for SaaS goes deeper on the Claude-specific version of all three, and our OpenAI versus Claude comparison is the place to start if the choice is still open.

What it costs to leave it. Not the invoice. The meeting where somebody who was excited about the feature asks whether it should be switched off, and nobody in the room can say which users or which prompts are responsible.

How do you keep customer data out of prompts and logs?

Decide what a prompt may contain, enforce it in the one function every call goes through, and treat the model's output as untrusted input on the way back.

A live app has customer data in it, and the fastest way to build a summarise feature is to hand the model the whole record. That is also the fastest way to send names, emails, addresses and account notes to a third party, into its logs, and into your own. The fix is a rule, written down, about which fields a prompt may contain per feature, and a function that builds prompts from an allow-list of fields rather than from the whole object. Where a task needs a person's name to read naturally, replace it with a token before the call and put it back after. It is unglamorous and it works.

Your own logs are the second leak, and the quieter one. Anthropic's SDK documentation warns that at the debug log level all HTTP requests and responses are logged including headers and bodies, that some authentication headers are redacted, and that sensitive data in request and response bodies may still be visible. Keep debug logging off in production, and when you log a request for cost or support, log the token counts, the request id, the feature and the user id, never the prompt body. If you need prompts for debugging, store them separately with a short retention and access control, not in the application log that ships to three vendors.

The way back matters as much as the way in. Model output can contain instructions, and a feature that pastes an answer into HTML, runs it as a query, or lets it choose which record to update has handed a stranger a way into your app. Escape it like user input, because it is user input by way of a model. Our guide to prompt injection in AI agents covers the attack in detail, and the single-call version is the same lesson at smaller scale. And if the feature answers questions over your own documents, the retrieval step has its own rules about who may see which document, which our RAG pipeline guide lays out.

One contractual point, because engineering cannot fix it. Read the provider's data retention terms for the API tier you are on, and if you serve customers under a data processing agreement, check that the model call is covered by it. Where it is not, the answer is often a regional or enterprise endpoint, not a different architecture.

How do you know the feature works before you ship it?

Build a small set of real inputs with answers a person has approved, run every prompt change against it, and never ship on the strength of the three examples that looked good in the console.

A model feature fails differently from ordinary code. It does not throw. It returns a confident, well-formed, wrong answer, and it does so on inputs you did not try. The only defence is to try more inputs than you would for a normal function, and to try the same ones every time anything changes. Take thirty to fifty real examples from your data, with the customer data handled as the previous section says, write down what a good answer looks like for each, and run the prompt against all of them in a test you can execute from the command line. When you change the prompt, the model, or the temperature, run it again and read the diff.

Grade with code where you can and with a person where you must. Extraction and classification have exact answers, so the test compares fields. Summaries and drafts do not, so the test records the output and a person reads the ones that changed. Some teams use a second model to grade the first, which is useful for scale and unreliable as the only judge. Keep a person in the loop for anything a customer will read.

Ship with a way off. Put the feature behind a flag, roll it out to a share of users, and watch three numbers: how often the user accepts the output without editing, how often they close it, and the token cost per accepted output. Those three tell you more than any offline score, and they are the numbers the person paying for the feature will ask about in month three.

When does an integration need to become an agent?

When one call plus one tool call cannot finish the job, and the model has to look at what it just learned to decide what happens next. Most features never get there, and the ones that do need a different set of guardrails.

Summarising, classifying, extracting, drafting, translating and answering a question over your documents are single calls, possibly with one tool call for lookup. They are the majority of what a product team asks for, and everything on this page is enough to run them well. An agent is the thing that loops: it calls a tool, reads the result, decides on the next tool, and keeps going until it judges the task done. The moment your feature needs that, it needs budgets on steps and tokens, a wall-clock limit, idempotent tools so a retry cannot send two emails, and schema validation of every argument the model produces, because none of those problems exist in a single call and all of them exist in a loop.

Both provider SDKs will take you to the first step of that road without a framework. Anthropic's SDK ships a tool runner that takes Zod or JSON schemas, passes the model's chosen inputs into the right tool, and hands the result back to the model, and the OpenAI SDK has equivalent helpers. Use them for a single tool call inside a feature. When the loop becomes the feature, read our Node.js AI agent guide, which compares the frameworks, builds the core loop, and covers the coordination and error-handling that a loop demands. This page ends where that one begins.

When it is worth handing this to someone

When the feature is already live, customers are using it, and the questions in the sections above do not have answers anyone on the team can point to in the code.

If the disqualifier section described you, use the SDK, set a timeout, set a spending limit, and ship. If you have one feature and a team that reads READMEs, this page is a checklist and you can work through it in a sprint. The teams that hand it over are the ones with a prototype in production that surprised them, a second and third feature queued behind it, and a quote on the table for a Python service or a platform migration that would solve none of the eight problems above and add a ninth.

That is the work we do at Geminate Solutions. We add AI features to products that already have users, inside the stack they already run, and we do not sell rebuilds or second stacks. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs.

The first step is a written review of your integration as it stands. Which path you are on and whether it fits. What the timeout and retry settings are on every model call. Whether a slow client can grow your memory. What happens on a 429. Where the usage numbers go and what caps exist. What customer data reaches the provider and your logs. And whether the feature has a test set or three good examples. We send it back within 48 hours and it stays yours whether or not we ever talk again.

Frequently Asked Questions

Do I need Python to add AI to a Node.js application?

No. Calling a hosted model is an HTTP request, and OpenAI, Anthropic and Google all ship official Node.js SDKs with the same streaming, retry and timeout features as their Python ones. Python becomes relevant only if you are training or fine-tuning models yourself or running a numerical pipeline, which is not what adding a feature to a live product involves.

Should I use the OpenAI or Anthropic SDK directly, or the Vercel AI SDK?

For one feature on one provider, the provider's own SDK is the smallest dependency and its README documents the defaults you need to change. Use a provider-agnostic layer such as the AI SDK when you already know you will switch or mix providers, or when several features share the same streaming and tool-calling plumbing. Raw fetch is fine for an internal tool with a call cap.

Why does my AI endpoint hang for minutes when the provider is slow?

Because both the OpenAI and Anthropic Node SDKs time out after 10 minutes by default and retry twice, so one slow upstream call can hold a request open far longer than your load balancer or your user will wait. Set the timeout per request to a few tens of seconds, stream the response so the first token arrives early, and abort the upstream call when the client disconnects.

How do I stop the AI bill from growing month over month?

Log usage per request with a user id and a feature name, set a cap per user and per feature and enforce it in the route, keep max_tokens close to the size of the answer you need, put the stable part of every prompt first so provider prompt caching applies, and route simple tasks to a smaller model. Do these in the first week, because they are hard to add after a bill has become a habit.

When does an AI integration need to become an agent?

When the task cannot be finished in one model call plus one tool call, and the model has to decide what to do next based on what it just learned. Summarising, classifying, drafting, extracting and answering questions over your data are single calls. Most features never cross that line, and a feature that does needs budgets, step limits and idempotent tools before it ships.

Send us the repository or a description of the feature and the route it lives in. A senior engineer reads the model calls, the timeout and retry settings, the streaming path, the 429 handling, where usage is recorded and what caps exist, and what customer data reaches the provider. Then writes back with what will hold under real traffic and what will not. No pitch, no commitment.

Whether one slow provider call can hold your request handlers open for minutes
Whether a slow client can grow your memory through an unbuffered stream
Where the usage numbers go, what caps exist, and whether prompt caching is doing anything
An honest answer if the SDK, a timeout and a spending limit are all you need

Get your free integration review

Drop your app s URL and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Lovable SEO: Why Your Live App Is Not Showing on Google, and Which Fix You Actually Need

Not indexed, or indexed and not ranking? Why every SEO scanner reports an empty shell while Google sees the page, why every route shows the same title, which fix each symptom actually needs, and who should do nothing at all.

Lovable Payments or Your Own Stripe: What Breaks the Week Real Money Arrives, and What to Fix First

Lovable Authentication: What Breaks the Week Real Users Log In, and What to Fix First

Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

On-Premise LLM Deployment: Do You Actually Need It?

Supabase Scaling: Which Wall You Actually Hit (2026)

Originally published on Geminate Solutions.

Lovable to Vercel: The 404, and What Else Breaks

Geminate Solutions — Mon, 07 Sep 2026 12:14:52 +0000

Every page about moving a Lovable app to Vercel describes one stack as if it were the only one. There are two, and three states a project can be in. This page tells you which is yours, gives the fix for each, and walks what else breaks after the 404 is gone, so you move once and keep the app you have.

The app works on lovable.app. You synced it to GitHub, imported the repository on Vercel, the build went green, and every route returns 404. Maybe the home page loads and nothing else does. Maybe you found a tutorial, added the vercel.json rewrite it told you to add, and now the home page is gone too. Nothing about the app changed. The host did.

Here is the short version. Lovable has generated two different stacks, and the switch happened on 13 May 2026. Projects from before that date are React and Vite single-page apps, and a static host has to be told to answer index.html for every path. Projects from after it are TanStack Start, which is a server, and a server needs a build in the shape its host expects. For a few weeks after the switch, Lovable's config package built for Cloudflare by default and Vercel got nothing it could run. Since July, Vercel detects a current Lovable project with zero configuration. So there are three states, one fix each, and every tutorial describes exactly one of them as if it were the only one.

Fixing the 404 is the first ten minutes. What comes after it is the rest of this page: the variables that were baked into the build, the secrets that never left Lovable, the database and auth that did not move with the frontend and were never going to, the redirect URLs still pointing at the old domain, the domain hand-over, and whether to keep Lovable as your editor once the code lives somewhere else. Then it tells you who should close the tab and stay exactly where they are, which, in Lovable's own words, is most teams.

Why does a Lovable app 404 on Vercel?

Because the host is serving the wrong shape of build for your stack. That is the whole diagnosis, and the reason it takes people three hours instead of ten minutes is that they do not know there are two stacks to choose between.

Start with the older one, because it is the one every tutorial was written for. A React and Vite project builds to a folder called dist that holds one HTML file and a bundle of JavaScript. Routing happens inside the browser. When a visitor lands on the home page, the bundle loads and React Router takes over, and clicking through to /dashboard never asks the server for anything. Refreshing on /dashboard does. The browser asks the server for a file at that path, there is no such file, and a static host does what static hosts do: it returns 404. Lovable's own guide to hosting outside Lovable states it plainly. Lovable projects use client-side routing with React Router and BrowserRouter, so your web server must return index.html for all routes. It adds a warning worth keeping: do not rely on a storage-level error page for this, because those return a 404 status code and search engines and monitoring tools will read it as one.

A fallback rewrite is the rule that makes a static host return index.html, with a 200 status, for any path that does not match a real file, so the browser gets the app shell and the app's own router can take it from there. Every static host has a one-line version of it. Vercel's Vite guide puts it this way: for a single-page app, deep linking will not work out of the box. It gives the fix as a vercel.json file at the root of the project:

{ "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }] }Netlify's version is a single line in a file called _redirects, which its documentation describes as serving index.html instead of giving a 404 no matter what URL the browser requests:

/* /index.html 200Cloudflare Pages needs nothing at all. Per Cloudflare's docs, if your project does not include a top-level 404.html file, Pages assumes you are deploying a single-page application and routes every path to the root. If you are on the old stack and you are 404ing, one of those three lines is your fix, along with the build settings Lovable's guide lists: build command npm run build, output directory dist, Node 22.

Now the newer stack, and the reason the rewrite made things worse for some of you. A TanStack Start project is not a folder of files. Server-side rendering is the pattern where a server builds each page into finished HTML before sending it, and that needs a process running on the host to answer every request. A rewrite that tells the host to serve index.html for every path is telling it to serve a file that a server build does not produce in that form. Applied to a working TanStack Start project, it does not fix the 404, and if the host was already detecting the framework correctly it can break the detection. That is the state where the home page vanishes after the fix. The fix for a server build is to give the host a server build it recognises, and the next section is how to tell which state you are in.

Which of the three states is your project in, and which fix is yours?

Open the root of your repository and look at the Vite config. That one file tells you the stack in under a minute, and the version number beside it tells you the state.

Lovable's FAQ is the primary source for the split, and it is one sentence: new Lovable apps created from 13 May 2026 use TanStack Start with server-side rendering, and older apps use React and Vite. Lovable did not move existing projects across. Its post announcing the change on 1 June 2026 said there was nothing to migrate, nothing to update and no decision to make, and its upgrade page adds that a published site keeps serving the old version until you publish again. So the date your project was created is a strong hint, and the file is the proof. If you want the full test, including the ten-second View Page Source check on your live site, our guide to what Lovable actually generates walks it. The one-line version is this. A vite.config that imports the React plugin directly and pulls componentTagger from lovable-tagger is the old stack. A config that wraps everything in a call to @lovable.dev/vite-tanstack-config is the new one, and the version of that package in package.json is what decides the rest.

Here is why the version matters. When the new stack shipped, that package chose where the build was for, and it chose Cloudflare. A developer who published a walkthrough on 30 May 2026 quoted the comment sitting in his own generated config, which described Nitro as build-only using Cloudflare as a default target. Nitro is the deployment layer under TanStack Start, and TanStack's own hosting documentation calls it an agnostic layer that lets a TanStack Start application deploy to a wide range of hosts. Lovable's June post confirmed the choice from the other side: Lovable runs the new stack on Cloudflare Workers for its own hosting. So in that window, a Lovable project imported on Vercel built happily for a platform it was not on, and Vercel found nothing it could serve. Two separate developers wrote up the same three hours on dev.to, one on 13 May and one on 30 May, and both landed on the same fix: add the Nitro plugin in the Vite config with the preset set to vercel, which one of them described as the line that tells Nitro to output the build in exactly the format Vercel expects.

Then the window closed. On 9 July 2026 Vercel's changelog announced that Lovable applications deploy with zero configuration, because Lovable projects now use Nitro, the same toolkit that powers zero-config deployment for TanStack Start on Vercel. Vercel's integration page, updated 10 July, adds the one condition that matters for you: zero-configuration detection requires @lovable.dev/vite-tanstack-config version 2.6.2 or higher, and if your project uses an older version, update it before deploying. That is the third state, and it needs nothing from you beyond a current package.

Two notes before you move on. First, a state B project is one package update away from state C, and that is nearly always the better fix than hand-writing a Nitro preset, because it keeps your config identical to what Lovable generates and stops the next sync from arguing with you. Second, Netlify and Cloudflare have their own versions of this for the new stack. TanStack's hosting documentation names an official Netlify plugin for TanStack Start and an official Cloudflare Vite plugin for Workers, and says a plain Node server runs the build with node .output/server/index.mjs. Lovable's own guide to external hosting, as of today, describes only the Vite path, with dist as the output and index.html for every route, and does not mention TanStack Start, server rendering or Nitro anywhere. If you are on the new stack and following that guide, that is why it is not working. It is not wrong. It is describing the other stack.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

What happens to your environment variables and secrets when you leave?

The public ones travel with the build, and the private ones never leave Lovable. Both of those facts will surprise you at the worst moment if you do not know them going in.

Build-time variables are values that the bundler reads once, while building, and writes into the JavaScript it produces, so changing them afterwards changes nothing until you build again. Vite's docs are blunt about it. Variables prefixed with VITE_ will be exposed in client-side source code after bundling, and adds the warning that VITE_ variables should not contain sensitive information such as API keys, because their values are bundled into your source code at build time. Lovable's hosting guide applies that to a Lovable project directly. A project on the built-in backend needs three values from its .env file set on the new host, VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID, and it repeats the point in its own words: environment variables prefixed with VITE_ are embedded at build time, not runtime, and to change them you rebuild.

So the first thing people do wrong is set the variables after the first deploy and wonder why the app still cannot reach its database. The build that is live was made before the values existed. Redeploy. The second thing they do wrong is panic that the publishable key is visible in the bundle. It is meant to be. That key only reaches what your row policies allow, and the one that is an incident is the secret key, which should never have been in a browser in the first place. Our Lovable security guide covers which key is which and what to do if the wrong one is in the bundle, so this page will not repeat it.

The private values are a different story. Lovable's FAQ says secrets and database data are never copied when a project is remixed, and its hosting guide lists environment variables and secrets as a manual step in every migration scenario. The API keys you pasted into the Cloud tab's Secrets section were stored, in Lovable's words, in your Supabase project, and they never appear in your app's code or repository. That is correct behaviour, and it means the repository you just deployed contains none of them. If those secrets are used by edge functions, they are still where the edge functions can reach them, because the edge functions did not move either, which the next section explains. If your new host needs its own copy of anything, for instance a server-side value on the new stack, you set it on the host by hand, and Lovable's guide is explicit that even its Docker generator cannot generate real secrets and leaves placeholders for you to replace.

The new stack adds one distinction the old one never had. A TanStack Start project has code that runs on the server, and Vercel's TanStack documentation treats that server as a Vercel Function. Server-side values do not carry the VITE_ prefix and are never bundled into the browser. Give a server secret a VITE_ prefix and you have published it. Leave the prefix off a value the browser needs and the client will read undefined. The prefix is the line between public and private, and on a server build that line now runs through your own repository.

List every VITE_ value in .env. Lovable's guide names three for a Cloud project. Yours may have more if you added third-party services.
Set them on the host in every scope. Vercel keeps production, preview and development separate. The 13 May write-up on dev.to lost time to exactly this. A preview deploy with no variables of its own points at nothing, and a preview deploy copied from production points real test traffic at real data.
Redeploy after setting them. They are baked in. The build that is live was built without them.
Search the built bundle for anything that is not the publishable key. If a vendor key or the secret key is in there, it was in a VITE_ variable and needs to move server-side.
Set server-only values without the prefix, on the new stack only, and confirm they do not appear in the browser bundle.
Leave the Cloud secrets where they are if your edge functions still use them, which they do.

Can Lovable be self hosted, and what does self hosted actually move?

The app can. The platform cannot. And the phrase self hosted, as most people use it in a search box, describes something that moves about half of what they think it moves.

Lovable's documentation on deployment and ownership is unusually direct on the first half. The Lovable platform itself, meaning the editor and the AI agent, is a managed service and cannot be self-hosted or deployed inside a customer VPC. There is no version of Lovable you run on your own servers. What you own, in the same document's words, is your code and your data, and it lists three independent layers: the code, which syncs to any Git workflow, the frontend, which can run on managed hosting or your own infrastructure, and the backend and data, which can move to a managed Supabase project or a self-hosted one. Lovable's FAQ answers the ownership question in four words, you as the creator do, and our guide to the generated stack covers what that ownership is worth in practice.

Now the half that catches people. Deploying your repository to Vercel, Netlify or Cloudflare moves the frontend layer and nothing else. The database, the authentication, the storage buckets, the edge functions and the secrets all stay exactly where they were, on Lovable Cloud or on the Supabase project you connected, and the deployed frontend keeps calling them at the same URL it always did. That is why a frontend move is cheap and usually works on the first afternoon. It is also why a founder who wanted everything on infrastructure the company controls discovers, a week later, that the users and their data are still on an account they do not hold.

Moving the backend is a separate project with its own rules, and Lovable's documentation is candid about them. Its Supabase integration page says there is no automatic migration between the built-in backend and your own Supabase project in either direction. Its hosting guide lays out what migrates and how: the database schema and the storage buckets move through the SQL migration files in your repository, and everything else is manual. Authentication providers have to be reconfigured. Secrets have to be re-entered. Table data is exported and imported. Storage files are downloaded and uploaded. User accounts move partially, because, in the guide's words, you cannot export user passwords, so every user goes through a password reset. We wrote that half up in Lovable Cloud vs your own Supabase, including what the export actually contains, and this page will not repeat it.

Self-hosting Supabase itself, on your own machines, is the far end of the scale. Lovable's guide supports it and describes applying the migration files from your project's supabase folder to the self-hosted instance, and it adds two warnings that matter. Running only a standalone Postgres database is not sufficient unless you implement equivalent authentication, storage, realtime and edge services. And once you do it, Lovable does not monitor, operate or debug any part of self-hosted infrastructure. A request for first-class self-hosted Supabase support is still open on Lovable's feedback board at the time of writing, which tells you the platform does not treat it as a solved path yet. If the reason you are here is that the built-in backend is running out of room rather than a wish to hold the data, that is a capacity question and our Lovable backend guide answers it without a migration.

What breaks on day two: auth redirects, edge functions and CORS?

Sign-in. Almost always sign-in, and almost always the day after, once a real user tries the magic link or the Google button from the new domain.

The mechanism is a list. Supabase's auth docs define it. The Site URL in URL Configuration sets the default redirect when the code does not specify one, and that any redirect the code does specify should match the Redirect URLs allow list. Your project's list was written when the app lived at a lovable.app address, and possibly at your custom domain on Lovable's hosting. The new host's address is not on it. A magic link or an OAuth callback that tries to land there gets sent to the Site URL instead, or fails, depending on the flow. The fix is to add the new domain and the host's preview pattern to the list, and Supabase allows wildcards in that list precisely so that preview URLs from deployment providers can be covered in one entry. Then check every OAuth provider you enabled, because Google and GitHub hold their own callback list and it still says lovable.app. Lovable's hosting guide notes one more thing you lose if the backend also moves: managed OAuth configuration and automatic token refresh are only available when the backend runs on the built-in backend, so on your own Supabase project, those become yours to configure.

Edge functions do not break, and it is worth understanding why, because it tells you where they live. Lovable's Supabase page says that when it writes a function, it deploys it to your Supabase project and updates your app to call it. Supabase's own deployment documentation shows the result running at your project's supabase.co address under functions/v1. That address did not change when your frontend moved. The function is a server that belongs to the backend layer, its secrets are in the backend layer, and the new frontend calls it exactly as the old one did. The only way an edge function breaks in a frontend move is if it checks the caller's origin and you have not told it about the new one.

Which is the CORS question. Cross-origin resource sharing is the browser rule that a page on one domain may only read responses from another domain if that domain has said it may. Supabase's API answers any origin by default, so most Lovable apps never hit this. If someone hardened your project by pinning an allowed-origins list in an edge function or in a proxy, the new domain has to be added to it, and the symptom is a request that works in a terminal and fails in the browser with a message about the origin. Our production checklist for Lovable apps covers the allowed-origins decision itself, and the hub is the page to read once this one has your site up.

How do you move the custom domain without downtime?

Deploy on the new host first, verify it on the host's own temporary address, then move the domain. People do it in the other order because the domain feels like the finish line, and then the site is down while they debug.

Lovable's custom domain documentation tells you what is sitting at your registrar. A domain connected to Lovable points an A record at a Lovable address and carries a verification TXT record on a host called _lovable, or a CNAME instead of the A record on some setups. Some of those records were created by Lovable and are locked in its interface. Those records, per the same page, show a lock icon, cannot be edited or deleted by you, and that Lovable removes them when you disconnect the domain from the project. Anything else you must clear yourself, and the same page says to clear DNS settings at your domain provider to completely clear the connection.

The order that avoids downtime is short. Add the domain on the new host first, which gives you the records it wants. Confirm the app answers on the host's temporary address with sign-in working, because of the previous section. Then disconnect the domain in Lovable's project settings, which removes the locked records. Then replace the remaining Lovable records at your registrar with the host's, and wait. Both sides issue certificates automatically, Lovable generates and installs one when a domain connects and Vercel does the same, so SSL is not a step you take, it is a step you wait for.

Two things to know before you start. Lovable is explicit that there is currently no way to remove the project's lovable.app address from the project, so the old address keeps answering, and anything that cached it, a bookmark, a link in an email, a share on social, keeps working and keeps sending people to the old build. Decide whether you want that. And if you shipped a progressive web app, Lovable's upgrade documentation warns that cached versions on people's devices may need a manual follow-up, which is just as true of a host move as of a stack upgrade. A user whose phone is holding the old shell will keep seeing it until the service worker updates.

Should you keep Lovable as your editor after you move?

Yes, by default, and for longer than the migration vendors would like. Nothing about hosting elsewhere requires you to stop building in Lovable, and Lovable documents it.

The mechanism is the GitHub integration, and it runs in both directions. Per Lovable's integration page, changes made in Lovable sync to GitHub and changes pushed to the active GitHub branch sync back into Lovable. Vercel's integration page describes the result from its side: once connected, every change you make in Lovable syncs to GitHub and triggers a new deployment. So the loop after the move is the same loop as before it, with your host at the end instead of Lovable's publish button. Lovable's hosting guide extends that to the backend case too. You can continue using the Lovable editor and preview environments during development after moving to your own Supabase.

The limits are the ones in Lovable's GitHub documentation, and they are worth knowing before a developer joins. Each Lovable project connects to one repository. Lovable edits and syncs one branch at a time, so a push to a different branch will not appear in the editor until it is merged or you switch the synced branch. The same file edited in both places at once can conflict. And the integration only runs one way at setup: you can export from Lovable to GitHub, not start a Lovable project from an existing repository. Sync stopping altogether nearly always traces to one of the reconnection cases the documentation lists, a suspended or uninstalled GitHub app, lost access to the repository, or a deleted repository, and the editor prompts you to reconnect.

What you give up is small and specific. Lovable's hosting guide is clear that production previews are not generated for a self-hosted production environment, and Lovable cannot see your host's logs or debug infrastructure it does not control. What you keep is everything else, including the agent. The honest default is to keep the editor connected until someone is working in the repository every day and finding the sync a nuisance, and then to have that person decide. That is a workflow decision, not a migration one.

One last thing, because half the searches around this topic are about getting the code out at all. Lovable's code editor page spells out the routes. On paid plans, anyone with edit access can click Download codebase at the bottom of the file panel and get a zip. A single file downloads on any plan from the file toolbar. The Free plan's editor is read-only. Enterprise admins can restrict downloads to workspace admins and owners. And for ongoing work outside Lovable, the same page tells you to connect the project to GitHub or GitLab instead of downloading snapshots, because sync keeps the repository and the project in step both ways. A zip is a photograph. Sync is the live feed. If you deployed from a zip, you deployed a photograph, and the next change in Lovable will not reach your host.

Who should not leave Lovable hosting at all?

Most of you. That is not our opinion, it is the first thing Lovable's own guide to hosting outside Lovable says, and it is right.

The guide opens by saying it is intended for teams with specific requirements, such as compliance constraints, data residency needs or organisational infrastructure policies, and then says that most teams never need to migrate, and that you can start on Lovable and move components later if and when you hit real constraints. Lovable's hosting includes custom domains, automatic deployments, managed authentication, preview environments and certified infrastructure. If you are a solo founder, no developer is joining, nobody in compliance has asked, and the site works, moving it buys you a weekend of the work on this page and a hosting bill you did not have. Stay.

Move if one of three things is true. A developer is joining and wants an ordinary repository with pull requests and preview deployments on the host they know. The company needs the frontend running under an account it holds, for a policy reason or a procurement one. Or a compliance requirement names where the frontend and the data must run, in which case you are doing the backend move too and the page you need next is the Cloud versus Supabase one.

And do not move for the wrong reasons, because they are common. A leaking table is not fixed by changing hosts, it is fixed by a row policy, and it will leak from Vercel exactly as it leaked from Lovable. A backend that has run out of room does not get more room from a new frontend host. A site that is not being indexed is almost never a hosting problem, and if that is what brought you here, our Lovable SEO guide is the page you want, because the answer there is about rendering and not about where the files sit.

When is a rebuild the honest answer, and when is a 404 being sold as one?

Never for a 404. There is no version of this problem where the right answer is a different codebase, and the people telling you otherwise are usually paid by the rebuild.

Read back through the page. A rewrite rule. A package version. Six variables in the right scope. A redirect URL list. Two DNS records. A decision about the editor. Every one of those is a line of configuration or a setting inside the application you already have, and the application is ordinary React and TypeScript that Lovable's own June post says was chosen to be easy to deploy anywhere. When an agency looks at a screenshot of a 404 and says the app needs to be rebuilt in a proper stack before it can be hosted properly, ask them which line on this page cannot be done to your repository. There is not one.

The one genuine piece of engineering in this whole territory is not about hosting. It is the upgrade from the old stack to the new one, where Lovable's own documentation warns that some code libraries only work in the browser and can break server rendering in ways the upgrade's checks do not catch. That is real, it is a component-loading fix rather than a rewrite, and it is covered in our guide to what Lovable generates. It has nothing to do with which host you are on.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can use them, pay through them and trust them, and we do not sell rebuilds. Your Lovable app stays your Lovable app, on whichever host makes sense for you. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs, and the production checklist for Lovable apps is the hub this page hangs off.

The first step is a written deploy read. Send us the repository and the URL that 404s. A senior engineer names which of the three states you are in, writes the fix, lists every variable, redirect and record that has to change, and tells you honestly whether you should be moving at all. It comes back within 48 hours and it is yours whether or not we ever speak again.

Frequently Asked Questions

Why does my Lovable app 404 on Vercel?

Because the host is serving the wrong shape of build for your stack. Lovable projects created before 13 May 2026 are React and Vite single-page apps, and Lovable's own hosting guide says the server must return index.html for every route, which on Vercel is a rewrite in vercel.json. Projects created or upgraded after that date are TanStack Start, a server-rendered framework. Vercel deploys those with zero configuration when the project carries @lovable.dev/vite-tanstack-config version 2.6.2 or higher. Below that version the package built for Cloudflare by default and every route 404ed on Vercel until the Nitro preset was set to vercel. Adding the Vite rewrite to a TanStack Start project does not fix it and can break a working build.

Can Lovable be self hosted?

The app, yes. The platform, no. Lovable's ownership documentation says the Lovable platform itself, meaning the editor and the AI agent, is a managed service and cannot be self-hosted or deployed inside a customer VPC. The code is yours and syncs to GitHub or GitLab, the frontend can run on any host that serves a static build or a JavaScript server, and the backend can move to a managed or self-hosted Supabase project. Moving the frontend alone leaves the database, auth, storage and edge functions exactly where they were.

Do I need to add a vercel.json rewrite to a Lovable project?

Only if the project is on the older React and Vite stack, where every route must fall back to index.html. A vite.config at the root that imports lovable-tagger or the React plugin directly is that stack. A project whose config wraps @lovable.dev/vite-tanstack-config is TanStack Start, and a rewrite to index.html is the wrong fix for a server build. Delete any rewrite you copied from a Vite tutorial, update the config package to 2.6.2 or higher, and import the repository again.

Does moving my Lovable app to Vercel move my database?

No. Deploying the repository to Vercel, Netlify or Cloudflare moves the frontend only. The database, authentication, storage, edge functions and secrets stay on Lovable Cloud or on the Supabase project you connected, and the deployed frontend keeps calling them at the same URL. Lovable's Supabase documentation says there is no automatic migration between the built-in backend and your own Supabase project in either direction, and its hosting guide says user passwords cannot be exported at all.

Can I keep editing in Lovable after deploying to Vercel?

Yes. Lovable's GitHub integration is two-way on the active branch, so changes made in Lovable commit to the repository and Vercel deploys each commit. Lovable's own hosting guide says you can continue using the Lovable editor and preview environments during development after moving. What you lose is Lovable's production previews for a self-hosted production environment, and Lovable cannot see your host's logs. Keep the editor until a developer is working in the repository every day, then decide.

Send us the repository and the URL that 404s. A senior engineer names which of the three states your project is in, writes the fix, lists every variable, redirect URL and DNS record that has to change, and tells you honestly whether you should be moving hosts at all. No pitch, no commitment.

Which stack and which state your project is in, from the config, not the date
The exact fix for your host, and which tutorial advice to undo
Every variable, redirect URL and record that has to change, in order
An honest answer if the right move is to stay on Lovable hosting

Get your free deploy read

Drop the failing URL and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Lovable Security: Is Your App the Problem, or Is Lovable? Which of the Three Stories Applies to You

A headline says Lovable apps leak, the publish scan flagged something critical, or a user can see someone else s account. Three separate security stories, only one of which was ever Lovable s. What a green scan proves and cannot, the five holes it still passes, and the leaked-key hour. Without a rebuild.

Node.js AI Integration: Adding AI to a Live App Without a Rewrite or a Second Stack

Lovable SEO: Why Your Live App Is Not Showing on Google, and Which Fix You Actually Need

Lovable Payments or Your Own Stripe: What Breaks the Week Real Money Arrives, and What to Fix First

Lovable Authentication: What Breaks the Week Real Users Log In, and What to Fix First

Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

Originally published on Geminate Solutions.

Lovable Security: Which Story Applies to Your App

Geminate Solutions — Mon, 07 Sep 2026 12:14:44 +0000

Every page about Lovable security is written by Lovable, a scanner vendor, or an agency with a rebuild to sell. This one separates the three incidents behind the headlines, says what a green scan does and does not prove, and walks the leaked-key hour, so you fix the right thing once.

A headline said Lovable apps leak. Or your publish dialog came back with a critical finding you do not understand. Or a user emailed to say they can see someone else's account. Three different things just happened to three different people, and every page that answers 'is Lovable secure' treats them as one question. They are not.

Here is the short version. There are three separate Lovable security stories. Two of them were user apps with the database policies left off, which is a thing you can check in twenty minutes and fix in an afternoon. One of them, the April 2026 incident, was Lovable's own platform, and it is the only one a certificate or a trust page has anything to say about. A green scan is a floor, not a verdict, and Lovable's own documentation says so in plain words. The key that everyone panics about, the anon key sitting in your bundle, is meant to be there. The one that is an incident is a different key. And almost nothing on this page is a reason to rebuild.

The rest of this page tells you which story is yours, what the scanner actually checked, what it cannot see, what to do in the hour after a real secret leaks, and, honestly, whether you will ever know if someone already read the table. Then it tells you who should close the tab and go back to building.

The platform, by the usual measures, yes. And that is almost certainly not the question you meant to ask.

Take the platform first, because it is the easy half. In its founder's guide to security, published 24 March 2026, Lovable describes itself as ISO 27001:2022 certified and SOC 2 Type II aligned, with encryption at rest and in transit, a separate Supabase project for every application so tenants are isolated from each other, and no model training on customer data. Lovable Cloud lets you pick a hosting region in the EU, the US or Asia Pacific, and says your data stays there by default. Security issues in the platform go through a HackerOne programme or to a disclosure address. Those are the things an enterprise buyer's questionnaire asks a vendor, and Lovable can answer them.

Now read the scope line on that same disclosure page, because it is the whole point of this article. The programme covers security vulnerabilities in Lovable's own products and infrastructure. Apps built with Lovable are explicitly out of scope and get sent to an abuse form instead. Lovable is telling you, correctly, where its responsibility ends. Your app's tables, the policies on them, the secrets it holds and the checks it runs on the server are not Lovable's products. They are yours, and Lovable's own documentation says the same thing a second way: you are responsible for ensuring the app meets the security requirements appropriate for its use case.

So the honest answer splits in two. Is Lovable, the company and the hosting, run to a standard you would accept from any other vendor? On the evidence they publish, yes. Is the app you built with it secure? Nobody can tell you that from a certificate, because the certificate is about their servers and the question is about your rows. When someone on a sales call answers the second question with the first, they have either misunderstood the question or are hoping you have.

What was the Lovable security vulnerability, and does it apply to an app built today?

There were three, they have different causes, and only one of them applies to a Lovable app built this year without you doing something to reintroduce it.

The first is the one with a CVE number. Matt Palmer, who works in developer relations at Replit, found it on 20 March 2025, reported it to Lovable the next day, got an acknowledgement on 24 March, and published it on 29 May 2025 as CVE-2025-48757 with a CVSS base score of 8.26. His description of the root cause is worth quoting exactly, because every headline since has blurred it: missing or insufficient Row Level Security policies on databases used by Lovable projects, where the generated app makes direct REST API calls against the database from the client using a public and unprivileged anon key. In plain terms, the browser talked straight to the database with a key anyone could read, and the database had no rules about which rows belonged to whom. Superblocks, reporting on the disclosure, attributes a follow-up scan to Palmer that found 303 exposed endpoints across 170 projects. Lovable's response was to ship a security scanner in its 2.0 release in April 2025, one that, again per Superblocks, initially flagged whether Row Level Security was present and not whether it worked.

The second story is February 2026, and it is the same fault line in one app. The Register reported on 27 February 2026 that a researcher, Taimur Khan, examined a single Lovable-hosted application and found sixteen vulnerabilities, six of them critical, with missing Row Level Security and inverted authentication guards at the centre. The app exposed 18,697 user records, 14,928 of them unique email addresses. Lovable's chief information security officer replied that every project gets a free security scan before publishing, that acting on it is at the user's discretion, and that this particular app contained code Lovable did not generate and used a database Lovable did not host. Read that reply carefully. It is a company saying, accurately, this was your app.

The third story is the one that was Lovable's. In its own post of 22 April 2026, Lovable says that between 3 February 2026 and 20 April 2026, the chat history and source code of public projects could potentially be accessed by any Lovable user, because backend regressions in February undid access protections the company had built between March and November 2025. A HackerOne report about it was filed on 22 February 2026 and closed without escalation, in Lovable's words, because its HackerOne partners thought seeing public projects' chats was intended behaviour. A researcher went public on 20 April and Lovable says it shipped a fix within two hours, then made every historically public project private. Lovable does not use the word breach and says private projects and Lovable Cloud were unaffected. The Register's account, published the next day by Jessica Lyons, quotes the researcher's claim that five API calls from a free account reached another user's source code, database credentials, chat history and customer data, and quotes Lovable's initial statement that it did not suffer a data breach. Both accounts are public. You can hold them side by side and decide for yourself what to call it.

Now the question in the heading. Does any of this apply to an app built today? The platform story is closed and was never in your app to begin with, and if your project was public in that window, Lovable says it will contact you. The two app stories are a different matter, because they were never about a date. They were about a table with no rules on it, and Lovable cannot stop you from creating one of those in 2026 any more than it could in 2025. What has changed is the amount of help you get. Lovable's guide says it now enables Row Level Security by default and lints for tables where it is missing. A basic scan has run automatically before every publish since 10 August 2026. Workspace API keys found in public GitHub repositories have been revoked automatically since 25 July 2026. Aikido penetration testing has been available on all plans since 23 June 2026. The floor is much higher than it was. Whether your app is above it is the rest of this page.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

What does the Lovable security scan check, and what does a green result mean?

It checks whether the configuration it can see has a known bad shape. Green means it did not find one. That is useful and it is not the same as safe, and Lovable is the first to say so.

There are two scanners, and the difference matters. The Basic scan is what Lovable's documentation calls a fast configuration and dependency check. It lints your Row Level Security policies, reviews the database schema and audits dependencies, and it runs automatically in the background when you open the publish dialog, in about 10 to 15 seconds. It returns one of three results: it passes, it returns warnings, or it flags critical issues, and workspace admins can set critical findings to block publishing until they are resolved. There is an auto-fix mode which, in Lovable's words, resolves straightforward low-risk findings during normal development and makes only non-breaking changes. The Deep scan is a different animal. Lovable calls it a thorough agentic review of your codebase, it takes about two to four minutes, and on top of everything the Basic scan does it reviews access control, backend endpoint protection, exposed secrets, unsafe input handling such as injection and cross-site scripting, insecure storage settings and information leakage. Wiz and Aikido plug in on top of that if you want a third opinion.

Here is what Lovable says the scanners cannot do, quoted rather than paraphrased so nobody can accuse this page of being unfair. The documentation says the tools cannot guarantee complete security and do not replace a thorough security review. The June 2026 post that describes the publish-time scan says the basic scan does not analyse your application code for logic flaws or vulnerabilities unique to how your app is built. And the very first version of the scanner, per Superblocks' reporting on the 2025 disclosure, flagged whether Row Level Security existed and not whether the policy did anything useful. The tool has grown up a lot since then. The category of thing it cannot see has not changed, because no scanner can know that your policy was supposed to say 'only the row owner' when it says 'anyone who is logged in'.

So read a green result the way an engineer reads it. It means: no table the scanner looked at has Row Level Security off, no obviously dangerous schema shape, no dependency with a known advisory, and, on a Deep scan, no secret it recognised in the client code and no endpoint it could tell was unprotected. It does not mean your policies express your business rules. It does not mean the view your dashboard reads from respects those policies. It does not mean the bucket your users upload to is private. Those are the next section, and they are where a founder with a passing scan and a leaking app usually turns out to be standing.

What can a Lovable app still leak after a passing scan?

Five specific things, and each one has a name you can search for in your own Supabase project, because Supabase ships a Security Advisor that runs automatically in the dashboard and reports them as numbered findings.

A view created as postgres. Supabase's Row Level Security documentation says it plainly: views bypass Row Level Security by default, because they are usually created by the postgres user. If Lovable, or you, asked for a handy view that joins profiles to orders so the dashboard loads in one call, that view can read every row of both tables regardless of the policies on them. The advisor reports this as 0010_security_definer_view, and the fix on Postgres 15 and later is to create the view with security_invoker set to true so it runs as the caller.

A policy that lets everyone through. Row Level Security being on is not the same as it being right. A policy written as using (true) for the authenticated role means every logged-in user can read every row the role can reach, and Supabase's documentation says to use that shape only for data that is genuinely public. Generated apps produce this policy constantly, because it makes the demo work and the scanner sees a policy and moves on. Nothing in the tooling can know that your invoices table was not meant to be a shared feed.

An edge function holding the secret key with JWT verification off. Lovable's guide says edge functions are JWT-protected by default, which is true and good. The trap is the one you switched off. Webhooks from Stripe or a payment provider cannot carry your users' tokens, so the function that receives them has to accept unauthenticated calls, and it very often holds the secret key so it can write to the database. That is a public URL with a key that bypasses every policy behind it. It is fine only if the function verifies the webhook signature before it does anything, and our Lovable backend guide covers how edge functions should be shaped for exactly this.

A public bucket that allows listing. Storage has its own policies, on a table called storage.objects, separate from the ones on your data tables. Supabase's storage documentation says public buckets are already publicly accessible, and the advisor's finding 0025_public_bucket_allows_listing flags a public bucket whose policies let a client enumerate everything in it. A bucket of user uploads that is public and listable is a directory of your customers' files with a URL each.

A policy that trusts what the user typed. Finding 0015_rls_references_user_metadata is the advisor's name for a policy that reads a role or a flag out of user_metadata, which the user can edit themselves. A generated admin check that looks at is_admin in the metadata a user controls is an admin panel with a self-service door. Our Lovable authentication guide covers the roles half of this, including which metadata field cannot be edited by the user, so it is not repeated here.

There is a sixth that has no advisor code, because it is not a configuration. It is the April 2026 pattern, in your app instead of Lovable's: an endpoint or a query that takes an id from the request and never checks that the id belongs to the caller. Security people call it broken object level authorisation. Your users call it changing a number in the address bar and seeing someone else's order. A policy on the table catches most of it. An edge function that queries with the secret key and trusts the id in the body catches none of it, and that is the case the scanner explicitly says it does not analyse.

The 20-minute check: is your Lovable app leaking data right now?

You can answer this yourself, today, without a vendor, in the order that finds the worst things first.

Open the Supabase Security Advisor and read every finding marked ERROR. It is in the dashboard under Advisors and it runs on its own. Look for 0013_rls_disabled_in_public, which means a table is fully open through the API, 0010_security_definer_view, 0002_auth_users_exposed, which means a view is leaking your users table, and 0015_rls_references_user_metadata. If you are on Lovable Cloud rather than your own Supabase, the same checks surface in Lovable's Security view, and the Deep scan is the equivalent step.
Run the Deep scan and read the critical list, not just the count. Two to four minutes. Every critical finding has a description. If one says a secret is in client code, that is step four's job and it jumps the queue.
Do the second-account test. Two real accounts, log in as one, try to load the other's data by changing an id. Our vibe coding security checklist gives the exact steps and the SQL for the policies, so this page will not repeat them. If account two can see account one, you have the CVE-2025-48757 pattern, in 2026, in your app.
Search the shipped bundle for the wrong key. Open the live site, open developer tools, search the sources for sb_secret_ and for service_role. Either one present is an incident and the next section is what to do. Finding sb_publishable_ or anon there is expected and correct, and if a scanner sold you a report that called it a leak, the report is wrong.
List every storage bucket and its public flag. Any bucket that holds user uploads and is public needs a reason. Then check the advisor for 0025 on the ones that are.
List every edge function and note which have JWT verification off. Each one needs a written reason, and if the reason is a webhook, the function must verify the signature before it touches the database. Twenty minutes is honest for someone who has seen a Supabase dashboard before. Double it if you have not. Steps one, two and four tell you whether you are exposed right now. Step three tells you whether the policies you have are the policies you meant. Steps five and six are the ones the scanner does not think about. Write down what you found, because the next two sections depend on it.

One thing to hold onto while you do this. Every finding in that list is fixed by editing the app you have: a policy, a view definition, a bucket flag, a function setting, a key moved to Secrets. The hub page on taking a Lovable app to production has the Row Level Security section with worked policies, and the engineer's checklist has the secrets-to-server fix. Neither involves a new codebase.

Your Lovable API key is exposed. What do you do in the next hour?

First work out which key, because one of the two answers is 'nothing, that key is meant to be public', and a lot of panic starts with not knowing that.

Supabase gives every project two classes of key, and it has been renaming them through 2026, so you may see either name. The publishable key, which older projects call anon, is described in Supabase's key documentation as safe to expose online, in a web page, a mobile app, a GitHub action or source code, because anyone can read it and it only reaches what Row Level Security allows. That key is in your bundle by design. It is how the browser talks to the database at all. If a tool, a tweet or a consultant told you your app is compromised because the anon key is visible, the correct response is to check your policies and then stop worrying about the key. The secret key, which older projects call service_role, is the opposite. Supabase's wording is that it provides full access to your project's data, bypassing Row Level Security, that it must never leave your control, and that you must never put it in a browser, a shipped application or source control. Supabase is retiring the old anon and service_role names by the end of 2026 in favour of keys prefixed sb_publishable_ and sb_secret_, which is why step four above searches for both spellings.

If the secret key is in the bundle, the hour looks like this. Rotate it in the Supabase dashboard, which invalidates the old one immediately. Update the value in Lovable's Secrets so the edge functions that legitimately use it keep working, and redeploy them. Then go straight back to the policies, because rotating the key closes the door and Row Level Security decides what was behind it. A secret key in a bundle for a week is only a disaster if the tables behind it had no policies. If they did, the exposure is far smaller than the headline version, and you should know which it was before you decide who to tell.

Third-party keys follow the vendor. A Stripe secret, an OpenAI key or a Maps key in client code gets rotated at that vendor, moved into Lovable's Secrets, and called only from an edge function. Lovable's documentation says it now detects an API key pasted into the chat and steers you to store it in Secrets rather than in code, which closes the most common way these ended up in the bundle in the first place. And a key for your Lovable workspace itself, if it landed in a public GitHub repository, has been revoked automatically since 25 July 2026 through GitHub's notification system, so check your Lovable account for a revocation notice before assuming it is still live.

The order matters more than the speed. People who rotate a secret key and stop there have fixed the symptom. People who rotate it and then write the missing policies have fixed the thing the key was hiding.

Can you tell whether anyone already read your data?

Usually not, and it is better to hear that from this page than from a lawyer later.

Supabase keeps API Gateway logs for every request through its REST and GraphQL layer, and you can filter them by method and by pathname, so a burst of reads against a table you never query from the app is visible if it is still there. The catch is retention. Per Supabase's published plan comparison, logs are kept for one day on the Free plan, seven days on Pro, twenty-eight days on Team and ninety on Enterprise. A table that sat open for six weeks on a Free project has no record of anything older than yesterday. Even on Pro you have a one-week window, and the reads you are worried about happened whenever a scanner or a curious person found the endpoint, which is not on your schedule.

So what you can honestly do is this. Look at the logs you have, for the tables you found open, and see whether there is anything at all. Then decide what you owe your users by the class of data that was reachable, not by the evidence you happen to have kept. If a table with names, emails and addresses was open through the public key with no policies, the defensible assumption is that it could have been read, and the notification rules that apply to you, which depend on where your users are and what the data was, start from that assumption rather than from a clean-looking log. This page is not legal advice and you should get some if the table held anything a regulator cares about. What this page will say is that the retention numbers are the strongest argument on the internet for fixing policies before the launch rather than after the headline, because afterwards you cannot buy the evidence back.

Who does not need to do any of this?

More people than the scanner vendors on this search result would like, and it is worth saying who, so the rest of you know you are not among them.

If your app is an internal tool and its project has workspace visibility, so nobody outside your company can even load it, run the free scan, fix anything critical, and go back to the product. If your app stores nothing you would call personal, takes no payments and holds no uploads, the twenty-minute check is still worth doing once for the habit, and then you are done until the data changes. If you are pre-launch with a handful of test users who are all you, the same. Lovable's checklist before publishing, which runs to seven lines in its documentation, is the right amount of security for that stage, and nobody needs to be paid to walk you through seven lines.

Come back when one of four things is true. Real people you do not know have accounts and the data in those accounts is theirs. Money moves through the app. A user, a customer or an investor has asked the question in this article's title and you could not answer it. Or the twenty-minute check turned up a secret key in the bundle or a second account reading a first account's rows, and the fixes in the hub page are a step past what you are comfortable doing to a live database.

When is a rebuild the honest answer, and when is it being sold to you?

For a security finding, almost never. And the people telling you otherwise usually charge by the rebuild.

Go back through the list of what leaks after a green scan. A view definition. A policy. A function flag. A bucket setting. A key moved into Secrets. Every one of them is an edit inside the application you already have, made by someone who understands Postgres and reads the generated code before touching it. Not one of them requires a new framework, a new hosting provider or a new codebase. The CVE that started all of this was a missing policy, and the fix for a missing policy is a policy. When an agency looks at a scan report and says the whole thing has to be rebuilt in a proper stack to be secure, ask them which of the findings on the report cannot be fixed in place. There will not be one.

There is one situation that genuinely looks like a rebuild and is not a security problem at all. It is the app that never had a server side. Every check lives in the browser, every write goes straight from the client to the table, and there is no place to put a decision the user cannot see. That app has a backend problem, and adding a backend to a Lovable app, through edge functions or a small service beside it, is a known piece of work with a known shape. Our Lovable backend guide covers when that is needed and what it looks like. It is still not a rewrite, and it is still your app at the end.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can use them, pay through them and trust them, and we do not sell rebuilds. Your Lovable app stays your Lovable app. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs, our AI code audit guide explains how we read a generated codebase before we change it, and the production checklist for Lovable apps is the hub this page hangs off.

The first step is a written security read of your live app. We do the twenty-minute check properly, read the policies rather than counting them, look at every view, bucket and function, and tell you which of the three stories applies to you, which findings are real, which are noise, and whether anything in there is a reason to rebuild. It almost never is, and we will say so in writing. It comes back within 48 hours and it is yours whether or not we ever speak again.

Frequently Asked Questions

The platform, by the usual measures, yes. Lovable describes itself as ISO 27001:2022 certified and SOC 2 Type II aligned, runs a HackerOne disclosure programme, hosts regionally, and gives each app its own Supabase project. None of that describes your app. Lovable's own disclosure page scopes its programme to Lovable's products and infrastructure and puts apps built with Lovable out of scope. Your app's security is its row policies, its secrets and its server-side checks, and those are yours.

Three different stories get called that. CVE-2025-48757 in May 2025 was user apps with missing Row Level Security, not the platform. The February 2026 report was one user app with 18,697 exposed records, and Lovable said its database was not even hosted by Lovable. The April 2026 incident was the platform: between 3 February and 20 April 2026, chat history and source code of public projects could be read by any Lovable user. Lovable does not call it a breach and says private projects and Lovable Cloud were unaffected.

Does a passing Lovable security scan mean my app is safe?

No, and Lovable says so. Its documentation states the scanners cannot guarantee complete security and do not replace a thorough security review, and that the basic scan does not analyse application code for logic flaws. A pass means the configuration the scanner can see has no known bad shape. A view created as postgres, a policy that grants every row to every user, a public bucket that allows listing, or an edge function with JWT verification switched off can all sit behind a green result.

Is it a problem if my Supabase anon key is visible in my Lovable app?

No. Supabase's own key documentation says the publishable key, still called anon on older projects, is safe to expose in a web page, mobile app or source code, because it only reaches what Row Level Security allows. The key that is an incident is the secret key, still called service_role on older projects, which bypasses Row Level Security and must never be in a browser, a shipped app or source control. If that one is in your bundle, rotate it now.

Do I need to rebuild my Lovable app to make it secure?

Almost never. Every common finding is a row policy, a bucket flag, a secret moved server-side or an edge function setting, all of which are edits inside the app you already have. The one case that looks like a rebuild is an app with no server side at all, where every decision lives in the browser, and that is a backend problem rather than a security one. A security finding used as the reason for a full rewrite is usually being sold, not diagnosed.

Send us the live URL of your Lovable app. A senior engineer does the twenty-minute check properly, reads the policies rather than counting them, looks at every view, bucket and edge function, and writes back with which of the three stories applies to you, which findings are real, and whether anything is a reason to rebuild. It almost never is, and we say so. No pitch, no commitment.

Whether any table, view or bucket is readable through the public key right now
Whether the secret key or a vendor key is in your shipped bundle, and the rotation order if it is
Which findings on your scan are real and which are noise
An honest answer if the right move is three policies and an afternoon

Get your free security read

Drop your app s URL and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served

Already built something, and it is starting to break?

Lovable to Vercel and Self-Hosting: Why Every Route 404s, and What Else Breaks When You Leave Lovable Hosting

The app works on lovable.app and 404s on Vercel. Two stacks, three states, one fix each, and what else breaks after the 404 is gone: baked-in variables, secrets that never left, the backend that does not move, redirect URLs and the domain. Who should not move at all. Without a rebuild.

Node.js AI Integration: Adding AI to a Live App Without a Rewrite or a Second Stack

Lovable SEO: Why Your Live App Is Not Showing on Google, and Which Fix You Actually Need

Lovable Payments or Your Own Stripe: What Breaks the Week Real Money Arrives, and What to Fix First

Lovable Authentication: What Breaks the Week Real Users Log In, and What to Fix First

Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It

Lovable Backend Solutions: What You Have, Where It Ends

AI App Builder: Which One to Pick, and What Breaks After

How Do You Stop Prompt Injection in a Production AI Agent?

AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?

React Web App to Mobile: Wrap, Rewrite, or Neither?

Can You Put PHI in an LLM? What a BAA Actually Covers

Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027

Base44 to Production: What You Own and What You Cannot Take

Your AI Pilot Works. Why Is It Still Not Live?

FlutterFlow to Production: What Export Actually Gives You

Single Tenant to Multi Tenant: What Actually Has to Change

Expo Go to Production: What Actually Breaks

Originally published on Geminate Solutions.

Lovable to Mobile App: Wrap, Rebuild, or Neither

Geminate Solutions — Mon, 07 Sep 2026 12:14:27 +0000

Every answer to this question is written by someone selling it. Lovable says wrap the URL. A wrapper vendor sells you the container. A rebuild vendor says wrappers get rejected and offers React Native. This page puts Lovable s docs, Capacitor s docs and Apple s rules side by side so you can see which of them is right about your app, and what it actually takes to get from a working web app to a listing without a rebuild.

Your Lovable app works. Someone asked whether it is in the App Store, you searched, and you got three answers. Lovable's FAQ says wrap it. A wrapper vendor says buy our container, done in a day. A rebuild vendor says wrappers get rejected under Apple's guideline 4.2 and offers to regenerate the whole thing as React Native. Each of them is selling the answer they gave you, which is why you cannot tell who is right.

Here is the short version. Lovable does not build native apps and says so plainly. There are two honest routes to a phone, a Progressive Web App or a native shell around your web build, and one wrong route that Lovable's own publish page happens to point at. The wrap that passes App Review copies your compiled build into the app. The wrap that loads your live URL is the thing Capacitor's own docs call not for production and the thing Apple's rules call a web clipping. Which of those you end up with depends on a config file, and whether you even have a build to copy depends on which of Lovable's two stacks your project is on.

After that, the part every tutorial skips. Sign-in works in the browser and breaks inside the shell, for a reason Supabase documents. Apple wants a Sign in with Apple button next to your Google one before it looks at anything else. You need a Mac. Google Play wants twelve testers for two weeks. And since iOS 16.4 a Home Screen web app can send push notifications, which for a fair number of founders means the store was never the point. None of it is a reason to rebuild anything, and none of it replaces the production checklist your web app still needs before a shell goes around it.

Can Lovable build a mobile app at all?

No. Not a native one. That is not our reading of the product, it is Lovable's own FAQ, and it is worth quoting exactly because half the pages that rank for this question soften it.

Lovable's FAQ says: Lovable builds web applications, and you can design them to be fully mobile friendly. Lovable does not generate React Native projects. Then it gives the two paths. If you want an installable app on phones, there are two common paths: make your published app a Progressive Web App that users add to their home screen, or wrap your published app with a tool like Capacitor to submit it to the App Store or Play Store. The publish documentation says the same thing from the other side. Lovable builds web apps and publishing always deploys to a web URL, your project's lovable.app address or your custom domain.

One thing to clear up before going further, because it pollutes every search on this topic. There is a Lovable mobile app in the App Store and on Google Play. It is Lovable's editor, for prompting and reviewing your projects from a phone. Lovable's own documentation for it says, in effect, if you want to turn a project you built into an app that people install on their phones, go and read the publishing question instead. So when the top results for lovable ios app are Lovable's store listing and a launch story, they are about Lovable's app, not yours. Yours does not exist yet, and this page is about whether it should.

A native shell is a small iOS or Android application whose main screen is a full-screen web view, with a bridge that lets the web code call native features such as the camera, push notifications and biometrics through plugins. Capacitor is the shell Lovable names and the one most of the tutorials use. The web code inside it stays the React that Lovable generated. That is the whole trick, and it is also where the two very different kinds of wrap come from, which is the next section and the one that decides whether you get rejected.

Wrapping the URL or bundling the build: which wrap did Lovable mean?

Bundle the build. Not the URL. Lovable's FAQ says wrap your published app, and its publish page says wrap your published URL in a native shell with Capacitor, and those two sentences describe two different apps. One of them gets approved.

Read Capacitor's configuration reference and the split is right there in two settings. The first is webDir, which Capacitor defines as the directory of your compiled web assets, and adds that this directory should contain the final index.html of your app. Capacitor's workflow guide describes what happens to it: running npx cap sync will copy over your already built web bundle to both your Android and iOS projects. So the app that ships contains your app. It opens without a network round trip, it can show something when the phone is offline, and to a reviewer it is a piece of software that happens to be built with web technology, which is what most apps on the store are.

The second setting is server.url. Capacitor's own words: load an external URL in the Web View. This is intended for use with live-reload servers. And then, on the same line of the reference, this is not intended for use in production. That setting is the URL wrapper. It is a browser with your address baked in and the chrome removed. Offline it is a blank screen. To Apple it is the thing guideline 4.2.2 describes when it says apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links, and the rejection notice that goes with it says the app does not sufficiently differ from a mobile web browsing experience. The URL wrapper is what a founder builds when they follow Lovable's publish page literally, and it is also, as far as their public pages let us tell, what most of the paid wrapper containers that rank for convert lovable to mobile app are. Their whole pitch is that you never touch the code, and you cannot bundle a build without touching the code.

That distinction is the most useful thing on this page, so here it is as a table. The PWA column is included because it is the option Lovable lists first and the one this page will come back to.

One more line on that updates column, because the vendors selling Capacitor tooling lead with it. Over-the-air updates push a new web bundle into an installed app without a store release. Apple's guideline 2.5.2 says apps may not download, install, or execute code which introduces or changes features or functionality of the app. Read that sentence with the product page open and decide for yourself what a bug fix is and what a feature is. We are not going to tell you a vendor's tooling is against the rules, and we are not going to tell you it is fine. We will tell you that 2.5.2 is the sentence a reviewer has in front of them.

Send us the build. We will tell you honestly what needs fixing.

A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.

If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.

Which Lovable stack are you on, and why does it change the wrap?

Because a bundled shell needs a folder of static files to copy, and only one of Lovable's two stacks produces that folder when you run the build.

Lovable's FAQ is the source for the split: new apps created from 13 May 2026 use TanStack Start with server-side rendering, and older apps use React and Vite. Lovable did not migrate the old ones. Our guide to what Lovable actually generates walks the full test, including the View Page Source check on your live site. The one-line version is enough here. If the Vite config at the root of your repository imports the React plugin and lovable-tagger directly, you are on the old stack. If it wraps everything in a call to @lovable.dev/vite-tanstack-config, you are on the new one.

On the old stack this section is short. The build writes a dist folder containing index.html and a bundle of JavaScript, and that is exactly the folder Capacitor's webDir wants. Every Capacitor tutorial on the first page of results, Capgo's included, tells you to set webDir to dist, and for a Vite project that is correct. Set the base path in the Vite config to a relative one so the assets resolve from inside the bundle, build, sync, open Xcode. The mechanics are an afternoon.

On the new stack there is no dist folder to point at, and this is where founders following those same tutorials get stuck without knowing why. A TanStack Start build produces a server, because server-side rendering means a process builds each page into HTML on request, and a server is not a folder of files you can copy into a phone. It is the same shape problem as deploying the new stack to a static host, which we covered in the Lovable to Vercel guide, and TanStack's own documentation gives the two ways out. The first is SPA mode. TanStack describes it as being for applications that do not require SSR for either SEO, crawlers, or performance reasons, where it may be desirable to ship static HTML to your users containing the shell of your application. It writes that shell to a file called /_shell.html, and TanStack is explicit that no SSR doesn't mean giving up server-side features, so your server functions keep working. The second is static prerendering, which TanStack defines as the process of generating static HTML files for your application, switched on with prerender.enabled and written out as /page/index.html files by default. Either gives Capacitor something to copy. Inside a phone, where nobody is crawling you, SPA mode is the one that fits.

One honest gap, and then the point. Those options are set on the TanStack Start plugin, and in a Lovable project that plugin sits behind Lovable's own config package. The npm registry entry for that package carries no README, so we could not confirm from the registry whether it passes the spa and prerender options through or not. A developer opens the config and looks. If the wrapper exposes them, it is two lines. If it does not, the config is unwrapped for the mobile build, which is still not a rewrite of anything. The point is that the tutorials are not wrong. They are describing the other stack, and if your project was created after 13 May 2026, you have been following instructions for an app you do not have.

Does Lovable support React Native, Expo or Flutter?

No, none of them, and the reason it matters is not the missing feature. It is what the people offering to fill the gap are actually selling.

The FAQ closes the question in one sentence, Lovable does not generate React Native projects, and there is an open request on Lovable's feedback board asking for React Native and Expo support, which tells you it has not shipped. There is no Flutter output either, and there never was. Lovable generates React for the browser, either React and Vite or TanStack Start, and both of those render HTML into a DOM. React Native renders native views and has no DOM, no CSS cascade and no div, which is why the two share logic and not screens. Our guide to taking a React web app to mobile walks what ports and what does not, including where the famous 99 percent code-sharing figures actually come from, and this page will not repeat it.

So what would a React Native version of your Lovable app be? A second frontend. It would sign in against the same Supabase project, read the same tables under the same row policies, call the same edge functions, and reuse your validation and formatting logic if that logic was ever separated from your components, which in a generated codebase it usually was not. Every screen would be written again. That is a legitimate project when the phone product is genuinely different from the web product, and a later section says when that is true.

Then there are the services that rank for lovable react native by offering to regenerate your project as React Native and Expo from your GitHub repository or your URL. Understand what that is. It is a new app, generated from a description of your old one, that does not share code with it and does not stay in sync with it. The next change you make in Lovable does not appear in it. You would own two products with one team, or more likely with none, and the tools that do this are competing with Lovable, not extending it. That is fine as a product decision if you have decided to leave Lovable. It is not a mobile version of the app you have.

Will Apple reject a wrapped Lovable app?

It rejects wrapped websites, and it rejects Google-only sign-in, and the second one is the rule nobody selling you a wrapper mentions.

Start with the one they do mention. Guideline 4.2 is titled Minimum Functionality. It asks that your app include features, content and UI that take it past being a repackaged website, and it says that if your app is not particularly useful, unique, or app-like, it doesn't belong on the App Store. 4.2.2 adds the list quoted earlier, with web clippings in it. The rejection notices founders post in Apple's developer forums use the same phrase every time: the app does not sufficiently differ from a mobile web browsing experience. A URL wrapper is that app by construction. A bundled shell is not automatically that app, because Capacitor apps ship on the store in large numbers, but a bundled shell whose whole content is your responsive site with nothing added is still that app. The reviewer is opening it and asking what it does that a Safari tab would not. The generic guide linked above lists the native capabilities that answer the question, push, biometric sign-in, camera wired to a real workflow, offline access to something that matters, and any one of them done properly moves you out of the category.

Now the one they do not mention. Guideline 4.8, Login Services, says that apps that use a third-party or social login service, and it names Google Sign-In, to set up or authenticate the user's primary account must also offer as an equivalent option another login service with the following features: the login service limits data collection to the user's name and email address, it allows users to keep their email address private, and it does not collect interactions with your app for advertising purposes without consent. That is a description of Sign in with Apple. The rule does not apply if your app exclusively uses your company's own account setup and sign-in systems, so email and password alone is fine. But a Lovable app that offers Google login, which Lovable's managed OAuth makes a one-line addition, and nothing else, fails 4.8 before the reviewer has formed an opinion about 4.2. Adding Sign in with Apple to a Supabase project is a documented provider setup plus the button, and it needs the paid developer account this page gets to shortly, so it is not a five-minute fix on submission day.

One more from the same document, 5.1.1, because it catches generated apps constantly. If your app supports account creation, you must also offer account deletion within the app. Most Lovable apps have a sign-up form and no delete button anywhere. That is a screen, a confirmation, and a call that removes the user and their rows, and it is a screen that has to exist before you submit, not after the rejection. Our Lovable authentication guide covers the Supabase side of both of these on the web, and the shell inherits whatever you did there.

Why does sign-in work on the web and break inside the app?

Because the login finishes in a browser that is not your app, and Supabase requires it to finish in the one that started it. This is the failure that turns a working afternoon into a locked-out launch, and it has a documented cause.

PKCE, which is the flow Supabase uses for browser sign-in, works by creating a secret on the client at the start of the flow and proving it at the end. Supabase's PKCE documentation says the code verifier is created and stored locally when the Auth flow is first initiated, and draws the conclusion for you: that means the code exchange must be initiated on the same browser and device where the flow was started. In a normal browser tab that is invisible. You click Google, you go to Google, Google sends you back to the same tab, the tab has the verifier, the session completes. Inside a shell it comes apart. The Google step opens in a browser context outside your app's WebView, Google redirects to the web address on your Supabase allow list, and that address opens in the phone's browser, which has no verifier, no app, and no idea what to do with the code. Magic links and password resets are the same story from an email instead of a button. Supabase's native mobile guide says as much: many Auth methods involve a redirect to your app, and it lists signup confirmation emails, magic link signins and password reset emails as the ones that carry a link.

The shape of the fix is in that same guide. Your app gets a custom URL scheme, the guide writes it as your scheme, two slashes, your hostname, and that address goes into the Additional Redirect URLs list in your Supabase auth settings. Then the flow inside the app changes so the provider opens in an in-app browser rather than kicking the user out to Safari, and the app listens for its own scheme being opened and finishes the exchange itself. In the reader's words, four steps:

Register a scheme for the app in the iOS and Android projects Capacitor generated, and add it to the Supabase redirect allow list alongside your web addresses.
Start the OAuth flow without the automatic redirect so you get the provider URL back instead of being sent to it, and open that URL in the in-app browser plugin.
Listen for the app being opened by URL, read the code or the tokens off it, and complete the session with the client library.
Point every email template that carries a link, confirmation, magic link, reset, at an address the app can catch, or at a small web page that hands off to the scheme, because a mail client opens links in a browser first. Two honest notes. First, the direct-to-scheme redirect from an in-app browser is not reliable on every setup, and developers who have shipped this pattern recommend landing on an https page first that then forwards to the scheme. A developer who documented the Universal Links version of this flow also noted that some browsers, Orion and Brave among them, will not launch a native app from a link at all, so the fallback web page is not optional. Second, Lovable's managed Google login was configured against your web origin when Lovable set it up. It has no idea the shell exists. Lovable's hosting guide says managed OAuth configuration is a feature of the built-in backend, so if you are on Lovable Cloud this is the point where you find out how much of that configuration you can see and change, and if you moved to your own Supabase project it was already yours. Either way the provider console needs the new redirect, and Apple's console needs the Sign in with Apple service set up from the previous section.

What do you need to test on an iPhone and to publish on both stores?

A Mac, two paid developer accounts, twelve people who will keep an app installed for two weeks, and a build that is not the one your tutorial stopped at. None of this is hard. All of it is a surprise to someone who was told the conversion takes an afternoon.

Capacitor's environment guide is where the Mac comes from. To build iOS apps, you will need macOS, and Capacitor 8 requires a minimum of Xcode 26.0. Android is friendlier: Capacitor 8 requires a minimum of Android Studio 2025.2.1 and an Android SDK platform for API 24 or greater, and Android Studio installs the Java toolchain for you. Cloud build services exist for teams with no Mac in the building, and Capgo's own tutorial routes you through one, but signing still happens against Apple's account and Apple's rules, so the Mac is a convenience you can outsource and the account is not.

The account is the Apple Developer Program. Apple's program page lists distributing on the App Store and inviting testers with TestFlight as things membership gives you, and it is a paid annual membership. TestFlight is how you answer the how do I test my Lovable app on my iPhone question. Apple's page says you can designate up to 100 members of your team as internal testers and invite up to 10,000 external testers, and, the part that catches people, that to invite external testers you must have your first build already approved by App Review for TestFlight. Your external test is your first review. Budget for it as one.

Google Play has its own version, and it is the one founders with a personal account hit hardest. For personal developer accounts created after 13 November 2023, Google's policy says you must run a closed test for your app with a minimum of 12 testers who have been opted in continuously for at least 14 days before you can apply for production access, and when you apply, Google reviews your submission and asks about your testing process and production readiness. Twelve real people, two weeks, no shortcuts. If you announce a launch date without knowing this, you miss it.

Then push notifications, which is the native capability most Lovable apps add first to answer the 4.2 question. Capacitor's push plugin says that on iOS you must enable the Push Notifications capability in Xcode and handle the registration callbacks in the app delegate, and the device token you get back is the APNs token. On Android the plugin uses Firebase Cloud Messaging, and all that is required is your Firebase project's google-services.json file added to the app module, plus a permission request on Android 13 and later. Then you need something on the server that actually sends the notifications, which is an edge function and a table you do not have yet. None of that is in the app you exported from Lovable, and all of it is ordinary work.

Last, the two things Capacitor's own deployment pages tell you they will not walk you through. Capacitor's iOS deployment page opens by sending you to Apple's official documentation on submitting apps, and its Android page sends you to Google's launch checklist. Screenshots for every device class, a privacy policy URL, the App Privacy questionnaire, an age rating, review notes with a test account, a signed release bundle and a keystore you must never lose. Process, not code. It is where the weeks go.

When is a PWA enough, and when is it not?

More often than the vendors will admit, and Lovable's FAQ lists it first for a reason. If the store listing itself was never the requirement, this is where you stop.

A Progressive Web App is your published site with a manifest and a service worker, so a phone can install it to the Home Screen with an icon, open it full screen without browser chrome, and load cached parts of it offline. Lovable's publish documentation describes exactly that outcome, installable so users can Add to Home Screen and launch it like a native app, with offline support and a full-screen shell. No Xcode, no Mac, no developer accounts, no review, no twelve testers, no 4.2. The next deploy is the next update.

The objection used to be notifications, and on iPhones that objection expired. WebKit's announcement for iOS and iPadOS 16.4 says a web app that has been added to the Home Screen can request permission to receive push notifications, with the permission request made in response to direct user interaction, such as tapping a subscribe button, and the same release added the Badging API so the icon can show a count. If the reason you wanted an app was so you could notify people and have an icon on their phone, a PWA on a current iPhone does both.

What a PWA cannot do is be found in the App Store. On Google Play it can be listed, through a Trusted Web Activity, which Chrome's documentation describes as a way to open your Progressive Web App from your Android app, where the content rendered comes from the web and is rendered by the user's browser, with the app and site verified as coming from the same developer through Digital Asset Links. Apple has no equivalent. A PWA reaches the App Store only by being put inside a shell, at which point it is a bundled shell and everything above applies. And because a Home Screen web app renders whatever your site serves, a project on the old React and Vite stack is serving an empty shell that fills in after the JavaScript runs, which is the same rendering fact that decides whether Google can read you. That story is in our Lovable SEO guide.

So the honest test is one question. Did someone ask for a listing, or did someone ask for an app? A customer whose procurement team wants a link in the App Store, an investor who wants to see it there, a product that people will only ever find by searching a store, those need the shell. A founder who wants users to have an icon and get notified needs a manifest and a service worker, and can have it by the end of the day, and should not read the rest of this page until something changes.

When is a React Native rebuild the honest answer, and when is it being sold?

Never because a wrapper was rejected. A rejection under 4.2 is fixed by adding a capability, a rejection under 4.8 is fixed by adding a button, and neither has anything to do with which framework rendered the screen.

The rebuild pitch that ranks for these queries goes like this: Apple's guideline 4.2 explicitly targets apps that are simply a website bundled in a native shell, reviewers will reject it, so let us regenerate your project as React Native. The first clause is true and this page quoted the rule. The conclusion does not follow from it. Apple is not detecting a framework. It is opening the app and judging whether it does anything a browser tab would not, and a bundled shell with push, biometric sign-in and a phone-shaped navigation passes that judgement every day. The rebuild vendors know this. Their business depends on you not knowing it.

There is a real case for a React Native product, and pretending otherwise would be its own kind of selling. Build one when the phone product is a different product: gesture-driven interaction, long high-performance lists, offline-first data with real conflict handling, background location, deep integration with the platform, or a business where the app is the primary surface and the website is the brochure. If you can name the capability the web version lacks and it is on that list, you are building a second frontend against your existing Supabase project, and the generic guide linked above tells you how to audit the codebase before you commit to a date. If nobody can name it, the rebuild is a rebuild of what you already own, and the only thing it produces is a second codebase that drifts from the first.

And who does not need any of this. If your product is used at a desk, during working hours, with a connection, and no customer has asked for a listing, you need a better mobile layout and possibly a PWA, and you need to close this tab. A Lovable app that is not in the App Store is not an unfinished product. Most web products are not in the App Store.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can use them, pay through them and trust them, on a phone when a phone is what the business needs, and we do not sell rebuilds. Your Lovable app stays your Lovable app, inside a shell when a shell is right. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, we track 30,000+ vehicles for Pixytan, and we hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs, and the production checklist for Lovable apps is the hub this page hangs off.

What does the path look like, in order?

Decide, identify, build, bundle, fix sign-in, add the one native thing, test, submit. In that order, because every step before the last one is cheaper than the one after it, and the first one might be the last.

Decide PWA or shell, using the one question from the PWA section. Who asked, and did they ask for a listing or an app. If the answer is PWA, add the manifest and service worker and stop.
Identify the stack from the Vite config. Old stack, dist is your build. New stack, turn on SPA mode or prerendering so a static build exists, unwrapping the config if the wrapper does not expose the option.
Bundle the build. webDir pointed at the static folder, relative base path, cap sync. Never server.url for anything that will be submitted.
Fix sign-in for the shell. Custom scheme on the Supabase allow list, in-app browser for the provider, the app catching its own URL, email templates pointed somewhere the app can catch. Add Sign in with Apple beside Google. Add account deletion.
Add the native capability that makes it an app. Push wired to a sender you build, biometric sign-in, camera into a real workflow, or offline access to something that matters. One done properly beats four done badly.
Test on real phones. TestFlight for iOS, knowing the first external build is a review. A closed test on Play with twelve testers for fourteen days if the account is personal.
Submit, with the screenshots, the privacy answers, the test account in the review notes, and a keystore backed up somewhere that is not the laptop. The first step is a written mobile read. Send us the repository and the URL. A senior engineer names which stack you are on, says whether a static build exists or what it takes to make one, reads the sign-in flow and the provider setup against the shell, lists every store gate that applies to your account, and tells you honestly whether you need a shell, a PWA, or nothing at all. It comes back within 48 hours and it is yours whether or not we ever speak again.

Frequently Asked Questions

Can Lovable build a mobile app?

Not a native one, and Lovable's own FAQ says so: Lovable builds web applications and does not generate React Native projects. The FAQ gives two paths to a phone. Make the published app a Progressive Web App that users add to their Home Screen, or wrap the app in a native shell with a tool like Capacitor and submit that shell to the App Store or Play Store. The Lovable mobile app you see in the store is Lovable's editor for building projects from a phone, not a way to publish yours.

Does Lovable support React Native or Expo?

No. Lovable generates React for the browser, either React and Vite for projects created before 13 May 2026 or TanStack Start with server-side rendering after it, and there is no React Native or Expo output. A React Native version of your app would be a second frontend written against the same Supabase project, sharing your data and your logic but none of your screens. Services that promise to regenerate a Lovable project as React Native are building that second product from a prompt. It is not your codebase and it does not stay in sync with it.

Can you publish a Lovable app to the App Store or Google Play?

Yes, through a native shell, and the version that passes review bundles your compiled web build inside the app rather than loading your live URL. Capacitor's own configuration reference says its remote URL option is for live-reload servers and is not intended for production, and Apple's guideline 4.2.2 names web clippings as something the App Store does not accept. Expect the store gates as well: a paid Apple Developer Program membership and a Mac with Xcode for iOS, a Sign in with Apple option beside any Google login, and on Google Play a closed test with at least 12 testers for 14 days before a personal account can publish.

Why does login work on the web but break inside the Capacitor app?

Because Supabase's PKCE flow stores the code verifier in the browser that started the sign-in and requires the exchange to finish on the same browser and device. Inside a shell, the Google or magic-link redirect lands in a browser context that is not your app's WebView, so the verifier is missing and the session never completes. The fix is a custom URL scheme for the app, added to the Supabase redirect allow list, an in-app browser for the provider step, and code that catches the returning URL and finishes the exchange. Lovable's managed Google login was configured for a web origin and does not know the shell exists.

Do you need a Mac to put a Lovable app on the App Store?

Yes. Capacitor's environment guide says building iOS apps requires macOS, and Capacitor 8 needs Xcode 26 or later. You also need a paid Apple Developer Program membership to distribute on the App Store and to use TestFlight, and an external TestFlight build goes through App Review before testers can install it. Android needs Android Studio and a Google Play developer account, which can be done from any operating system. Cloud build services exist for teams without a Mac, but signing and review still run through Apple's account and Apple's rules.

Send us the repository and the URL. A senior engineer names your stack, says whether a static build exists or what it takes to make one, reads the sign-in flow against the shell, lists every store gate that applies to your account, and tells you honestly whether you need a shell, a PWA, or nothing at all. No pitch, no commitment.

Which stack you are on and whether a bundled build exists yet
Whether your sign-in survives the shell, and the exact allow-list and provider changes if it does not
Every Apple and Google gate that applies to your account, in order
An honest PWA, shell, or do-nothing verdict

Get your free mobile read

Drop your app URL and work email. We reply within 48 hours.

Frequently asked questions

Get a free 24-hour review of your website

Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.

4.9 rated · 50+ products shipped · 250K+ daily users served