DEV Community: Geminate Solutions

What Is Agentic AI? How It Works and Where It Fails

Geminate Solutions — Wed, 30 Sep 2026 10:56:25 +0000

What Is Agentic AI?

Agentic AI is software in which an AI model plans and carries out multi-step work toward a goal, instead of producing a single answer. It decides which steps to take, uses tools such as your APIs, databases and email to take them, checks the results and adjusts, all inside limits that people set.

Four parts show up in every agentic system: a goal, tools it is allowed to use, memory of what it has done so far and a control loop that decides the next step and knows when to stop or ask a person.

At Geminate Solutions we build these systems for clients, and the pattern is consistent: the model is rarely the problem. Tool design, limits and hand-offs to people decide whether an agentic system is useful or dangerous. That is the focus of this guide.

Agentic AI vs Generative AI vs AI Agents

	Generative AI	AI agent	Agentic AI system
What it does	Produces content on request	Completes one task using tools in a loop	Coordinates one or more agents across a process
Takes actions	No	Yes, within its tools	Yes, across several tools and agents
Example	Drafts a reply to a ticket	Reads the ticket, checks the order, replies	Routes every ticket to the right specialist agent or person
Main risk	Wrong content	Wrong action	Errors that compound across steps

If you want the single-agent view first, including how the agent loop works step by step, start with what is an AI agent.

The Four Patterns Used in Production

Most real agentic systems are one of these four shapes, or a mix:

1. Single agent with tools. One agent, a narrow job, two to five tools. The simplest and most reliable pattern, and where almost every project should start.

2. Router and specialists. A router agent reads the request and hands it to a specialist agent (support, billing, operations), each with its own small tool set. Easier to test and safer than one agent that can do everything.

3. Planner and executor. One agent breaks a large task into steps, another carries them out and reports back. Useful for research and multi-system jobs, but it costs more and needs strict step limits.

4. Human in the loop. The agent does the work and a person approves before anything irreversible happens: sending money, deleting data, emailing a customer. This is a layer on top of the other three rather than an alternative.

For code-level detail on routing, tool calls and memory in Node.js, see building production AI agents in Node.js.

Real Examples

Systems we have shipped to production, each deliberately narrow:

Support triage. Reads incoming tickets, pulls account data, answers routine questions and routes the rest to the right person with a summary. Around 8,000 tickets a month.

Hiring screener. Scores resumes against a role and explains each score. 300 resumes in about 4 minutes.

Fleet anomaly detection. Watches live GPS data and flags unusual behaviour that fixed rules miss. Our fleet platforms track more than 30,000 vehicles.

Code review assistant. Checks pull requests for an EdTech platform serving 250,000+ daily active users against patterns that caused past incidents.

Lead qualification. Researches inbound leads, checks fit and drafts a first reply for a person to approve.

Where Agentic AI Fails

These are the failure modes we design against on every project:

Compounding errors. A small mistake in step two becomes a large one by step eight. The more steps, the more this matters.

Runaway loops. An agent that cannot finish keeps trying, and every attempt costs money. One of our early builds looped more than 80 times on a single task before we added a hard cap.

Prompt injection. An email, web page or document the agent reads contains instructions, and the agent follows them. See AI agent prompt injection.

Too much permission. An agent that can do anything eventually does something it should not.

Invisible decisions. Without logs nobody can explain why the agent did what it did, so nobody can fix it.

Unclear value. Some processes are cheaper and more reliable as plain automation. Agentic AI is the wrong tool when every step is predictable.

The Guardrails That Make It Safe

Least privilege. Each agent gets only the tools and data its job needs.

Step and time limits. A cap on iterations, a timeout on every tool call and a retry ceiling.

Approval gates. A person signs off on anything that moves money, deletes data or contacts customers until the agent has earned trust on that case type.

Untrusted input handling. Content the agent reads is data, never instructions.

Full logging. Every decision and tool call is recorded and searchable.

Evaluation sets. Real past cases the system is tested against before every change.

A kill switch. One setting that stops all agent actions immediately.

Our AI agent development guide covers architecture and team choices in more depth, and moving an AI pilot to production covers the step most teams find hardest.

Is Your Process Ready for Agentic AI?

A quick test. The more of these are true, the better the fit:

The task happens often, at least daily.

The inputs vary enough that fixed rules keep breaking.

The data the agent needs is reachable through an API or database.

A wrong step can be spotted and reversed before it causes harm.

Someone can define what a good result looks like, with real examples.

If most are false, start with integration or plain automation. That work usually has to happen first anyway.

How to Start

1. Choose one process that passes the readiness test.

2. Build one agent with two or three tools, not a multi-agent system.

3. Test on 50 to 100 real past cases before it sees live work.

4. Run in suggest-only mode next to a person and measure how often it is right.

5. Grant autonomy case by case where it has proven reliable, and add a second agent only when the first is stable.

If you want help designing or reviewing an agentic system, our AI integration team builds and hardens these for production.

FAQ

What is agentic AI in simple terms?

Agentic AI is software where an AI model does not just answer but plans and carries out multi-step work toward a goal. It decides the steps, uses tools such as APIs and databases to take them, checks the results and adjusts, with limits and human checkpoints set by the people who built it.

What is the difference between agentic AI and generative AI?

Generative AI produces content when asked: text, images, code. Agentic AI uses a generative model as its reasoning engine but adds tools, memory and a loop, so it can take actions and complete a task over many steps. Generative AI writes the email. Agentic AI finds the right customer, writes the email, sends it and logs the reply.

What is the difference between agentic AI and an AI agent?

An AI agent is one unit: a model with a goal, tools and a loop. Agentic AI is the wider approach and usually means systems built from one or more agents, for example a router agent that hands work to specialist agents, plus the orchestration, memory and guardrails around them.

What are examples of agentic AI?

Systems we run in production include a support triage setup handling around 8,000 tickets a month, a hiring screener that filters 300 resumes in about 4 minutes and a GPS fleet anomaly detector. Common patterns elsewhere include coding agents that open pull requests, research agents that gather and summarise sources, and operations agents that reconcile data between systems.

Is agentic AI safe for business use?

It can be, with the right design. Give each agent the smallest permissions it needs, require human approval for irreversible actions, treat everything the agent reads as untrusted input, cap how many steps it can take and log every decision. Most failures we see come from skipping these, not from the model.

How do I start with agentic AI?

Pick one repetitive process where the inputs vary and a wrong step can be caught before it does damage. Build a single agent with two or three tools, test it on real past cases, run it in suggest-only mode alongside a person and only then give it autonomy for the cases it reliably gets right.

Originally published on Geminate Solutions.

What Is Vibe Coding? Meaning, Tools and Limits

Geminate Solutions — Wed, 30 Sep 2026 10:55:53 +0000

What Is Vibe Coding?

Vibe coding is building software by describing what you want to an AI tool in plain language and accepting the code it writes, usually without reading that code closely. You judge the work by trying it. If the button works and the page looks right, you move on. If not, you describe the problem and let the AI try again.

The shift is who does the understanding. In normal development a person reads and owns every line. In vibe coding the person owns the idea and the outcome, and the AI owns the code. That trade is what makes it so fast, and it is also where every risk comes from.

Where Did the Term Come From?

The phrase comes from Andrej Karpathy, a founding member of OpenAI and former head of AI at Tesla. In a post in February 2025 he described a new way he was building small projects: fully giving in to the vibes, letting the AI write the code and not really reading the diffs anymore.

It named something many people were already doing, and it spread fast. By the end of 2025 Collins Dictionary had picked it as its word of the year. Today it covers everything from a weekend side project to founders building a whole startup MVP in an AI app builder.

How Vibe Coding Works in Practice

A typical session looks like this:

1. Describe the app. "A booking app for a yoga studio with classes, a calendar and Stripe payments."

2. The tool generates it. Screens, database tables, login and often a live preview within minutes.

3. Try it and react. "The calendar should start on Monday." "Add a waitlist when a class is full."

4. Paste errors back in. When something breaks, the error message goes straight back to the AI.

5. Publish. One click puts it on a live URL.

For a first version this loop is remarkable. What it skips is everything nobody asked for: who can read which rows in the database, where the API keys live, what happens when a payment webhook arrives twice, and how the app behaves with a thousand users instead of one.

Which Tools Do People Use?

Type	Examples	Best at
App builders	Lovable, Bolt.new, v0, Replit	Going from a prompt to a running app with hosting and a database
AI code editors and agents	Cursor, Claude Code	Working inside a real codebase, where a developer can review changes
Model playgrounds	Google AI Studio	Quick experiments and single-feature prototypes

If you are choosing between the builders, our comparison of AI app builders and what breaks after each goes through them one by one.

What Vibe Coding Is Genuinely Good For

It would be wrong to dismiss it. Vibe coding is the fastest way we know to:

Test an idea with real people before spending on a build.

Build internal tools that a small team uses and nobody outside ever sees.

Make a clickable demo for investors or a first customer conversation.

Explore a design by trying five versions in an afternoon.

Unblock non-developers who would otherwise wait months for engineering time.

The common thread: low stakes if it breaks, and no sensitive data. Inside those limits it is a genuine superpower.

What Breaks When Real Users Arrive

The problems are predictable, because they sit in the parts nobody looked at:

Database access rules left open. Many builders use Supabase, where row-level security decides who can read what. In 2025 researchers found many Lovable-built apps exposing user data because those rules were never turned on. See Lovable security.

Secrets in the browser. API keys for payments or AI models end up in front-end code where anyone can copy them.

Payments that half work. Checkout succeeds in testing, but refunds, failed renewals and duplicate webhooks were never handled.

No error handling or monitoring. When something fails, users see a blank screen and you find out from a complaint.

Performance cliffs. Queries that were instant with ten rows take seconds with ten thousand.

Code nobody can change safely. After hundreds of prompts, each fix risks breaking something else.

We cover the fixes step by step in taking a vibe-coded app to production, the tools that catch these problems in vibe coding security tools, and what the clean-up tends to involve in the real cost of vibe coding.

Vibe Coding vs AI-Assisted Engineering

The tools overlap, so the labels get blurred. The difference is not which tool you use. It is whether anyone understands what shipped.

In vibe coding, code is accepted because the result looks right. In AI-assisted engineering, an engineer uses the same AI tools to move faster but still reads every change, writes tests and owns the architecture. Our own team writes a large share of its code with AI tools every day. What we do not do is ship code nobody has read.

Both have a place. Trouble starts when a prototype built the first way is treated as a product built the second way.

How to Vibe Code Without Getting Burned

1. Decide what it is. A prototype, an internal tool or a product. Only products need the full hardening, but you have to know which one you are building.

2. Keep sensitive data out until someone has checked the access rules. Test with fake users and fake payments.

3. Export to a real repository early. Most builders can sync to GitHub. That gives you history, backups and a way for an engineer to review.

4. Get a review before launch. A few hours of an experienced engineer reading the database rules, secrets and payment flow catches most of the serious problems. Our 10-point production check is a good self-test first.

5. Plan the handover. If the idea works, the app will need to grow. Decide early whether you will harden what you have or rebuild the core, and do it before the first big customer, not after.

If you have a vibe-coded app that is about to meet real users, our AI builder to production team does exactly this hardening work.

FAQ

What is vibe coding?

Vibe coding is building software by describing what you want to an AI tool in plain language and accepting the code it writes, often without reading that code closely. You steer by trying the result and asking for changes, rather than by writing or reviewing the code yourself.

Who coined the term vibe coding?

Andrej Karpathy, a founding member of OpenAI and former head of AI at Tesla, used the phrase in a post in February 2025. He described giving in to the vibes, letting the AI write the code and not really reading the diffs. The term spread quickly and Collins Dictionary named it its word of the year for 2025.

What tools are used for vibe coding?

Full app builders such as Lovable, Bolt.new, v0 and Replit, which turn a prompt into a running app. AI code editors and agents such as Cursor and Claude Code, which work inside a real codebase. And model playgrounds such as Google AI Studio for quick experiments.

Is vibe coding good or bad?

It is good for prototypes, internal tools, demos and testing an idea with real people quickly. It is risky for anything that stores personal data, takes payments or has to stay up, because the parts that fail in production, such as access rules, secrets and error handling, are exactly the parts nobody reviewed.

Can a vibe-coded app go to production?

Yes, if someone who reads code checks it first. The usual work is turning on database access rules, moving secrets to the server, adding input validation and error handling, setting up backups and monitoring, and testing the flows real users will hit. Some apps need a few days of hardening, some need parts rebuilt.

Is vibe coding the same as AI-assisted coding?

No. In AI-assisted coding an engineer uses AI to write faster but still reads, understands and owns every change. In vibe coding the person accepts code they have not reviewed. The tools can be the same. The difference is whether anyone understands what shipped.

Originally published on Geminate Solutions.

What Is an AI Agent? A Builder's Explanation

Geminate Solutions — Wed, 30 Sep 2026 10:55:14 +0000

What Is an AI Agent?

An AI agent is software that is given a goal rather than a fixed script. It uses a large language model to decide what to do next, calls tools to do it, looks at the result and decides again, until the goal is reached or it hits a limit you set.

Three parts make something an agent and not just a model call: a goal ("qualify this lead", not "answer this message"), tools (your APIs, database queries, email, a search index) and a loop that lets the model choose the next action based on what the last one returned.

At Geminate Solutions we have shipped five agents into production, and the honest summary is this: the model is the easy part. The loop, the tool design and the guardrails are where the engineering goes. That is what the rest of this page explains.

AI Agent vs Chatbot vs Automation

These three get mixed up constantly, so here is the plain difference:

	Chatbot	Rule-based automation	AI agent
What it does	Answers messages	Runs fixed steps	Decides steps and takes them
Handles surprises	In conversation only	No, it breaks or stops	Yes, within its tools and limits
Takes actions	Rarely	Yes, the same ones every time	Yes, chosen per case
Best for	FAQs, guided help	Predictable, high-volume tasks	Varied tasks that need judgment

A useful test: if you can draw the whole process as a flowchart with no "it depends" boxes, you want plain automation. It is cheaper, faster and easier to trust. Agents earn their cost when the inputs are messy and the right next step changes from case to case.

What Is Agentic AI?

Agentic AI is the umbrella term for systems where models plan and carry out multi-step work with some independence. A single AI agent is one building block. Agentic AI usually means several of them working together.

The common shape in production is a router agent that reads the request and hands it to specialist agents: one for support, one for billing, one for operations. Each specialist has a small, focused tool set, which makes it more reliable and easier to test than one agent that can do everything.

When a vendor says "agentic", ask two questions: what tools can it call, and what stops it when it goes wrong? The answers tell you more than the label. For the full picture, see what is agentic AI.

How Does an AI Agent Work?

Almost every production agent runs the same loop, often called ReAct (reason plus act):

1. Read the goal and context. The agent gets the task, any memory from earlier runs and the list of tools it may use.

2. Decide. The model picks the next action: call a tool, ask a question or finish.

3. Act. Your code runs the tool call, not the model. That is where permissions and validation live.

4. Observe. The result goes back to the model.

5. Repeat or stop. The loop ends when the goal is met, when a human is needed or when it hits the iteration cap.

That iteration cap is not optional. One of our early hiring screener builds looped more than 80 times on a single stuck task before we added it. Every agent we ship now has a hard ceiling, usually 10 steps for simple jobs and 25 for complex ones.

For the code level, including tool calling and memory in Node.js, see our guide to building production AI agents in Node.js.

Examples of AI Agents We Have Shipped

Real systems, not demos. Each one is narrow on purpose:

Hiring screener. Reads resumes against the role, scores them and writes a short reason for each score. Filters 300 resumes in about 4 minutes, work that took a recruiter roughly 45 seconds per resume.

Support triage agent. Reads incoming tickets, pulls the customer's account data, answers the routine ones and routes the rest to the right person with a summary. Handles around 8,000 tickets a month.

GPS fleet anomaly detector. Watches live vehicle data and flags patterns a fixed rule would miss, such as a vehicle stopping somewhere it never stops. Our fleet platforms track more than 30,000 vehicles, so noise control mattered as much as detection.

Code review assistant. Reviews pull requests for an EdTech team whose platform serves 250,000+ daily active users, checking the patterns that caused past incidents.

Sales lead qualifier. Researches inbound leads, checks fit against the ideal customer profile and drafts the first reply for a person to approve.

Notice what they have in common: one job each, a small tool set, and a person still in the loop wherever a mistake would be expensive.

When Should a Business Use an AI Agent?

An agent is a good fit when three things are true: the task repeats often, the inputs vary enough that fixed rules keep breaking, and a wrong answer can be caught before it causes damage.

It is a poor fit when the process is fully predictable (use automation), when every mistake is costly and irreversible, or when the data the agent needs is scattered across systems with no API. In that last case the first project is the integration, not the agent.

If you already have a prototype that worked in a demo, our note on moving an AI pilot to production covers the gap most teams hit next.

What It Takes to Run an Agent in Production

The demo takes a week. Production is the rest. These are the parts we add to every agent before real users touch it:

Limits. An iteration cap, a timeout on every tool call and a retry ceiling, so nothing runs forever.

Least privilege. Each tool can do only what that agent needs. A support agent can read orders, but it cannot issue refunds without approval.

Prompt-injection defense. Anything the agent reads, from emails to web pages, is treated as untrusted. More on this in AI agent prompt injection.

Observability. Every decision and tool call is logged, so when an agent does something odd you can see exactly why.

Human hand-off. A clear path to a person for edge cases and anything irreversible.

Evaluation. A fixed set of real past cases the agent is tested against before each change ships.

For architecture choices and team sizing, our AI agent development guide goes deeper.

How to Build Your First AI Agent

1. Pick one narrow job with a clear finish line, such as "route every support ticket to the right queue with a one-line summary".

2. List the tools it needs, usually two or three to start. Write each one as a small function with strict input checks.

3. Write the loop with an iteration cap and logging from day one.

4. Collect 50 to 100 real past cases and test the agent against them before it sees live traffic.

5. Launch in shadow mode. The agent suggests, a person decides. Switch on autonomy only for the case types where it has been reliably right.

If you want a second pair of eyes on an agent you are building, or help taking one from demo to production, our AI integration team does exactly this work.

FAQ

What is an AI agent in simple terms?

An AI agent is software that is given a goal instead of a script. It uses a language model to decide the next step, calls tools such as your APIs or database to take that step, checks what happened, and repeats until the goal is met or it hits a limit you set.

What is the difference between an AI agent and a chatbot?

A chatbot replies to messages. An agent takes actions. A chatbot can tell a customer how to reset a password. An agent can check the account, trigger the reset and confirm it worked. The difference is tool use plus a loop that decides what to do next.

What is agentic AI?

Agentic AI is the broader label for systems built from agents: software where a model plans and carries out multi-step work with some independence. An AI agent is one unit of that. A system with a router agent handing work to specialist agents is agentic AI.

What are examples of AI agents in business?

Ones we have shipped: a hiring screener that filters 300 resumes in about 4 minutes, a support triage agent handling around 8,000 tickets a month, a GPS fleet anomaly detector, a code review assistant for an EdTech team and a sales lead qualifier.

How do you build an AI agent?

Start with one narrow job and the two or three tools it needs. Write the loop: send the goal and tool list to the model, run the tool it picks, feed the result back, stop on success or on an iteration cap. Then add what production needs: timeouts, retries, logging of every step, memory and a human hand-off.

Are AI agents safe to connect to company data?

Only with guardrails. Give each agent the smallest set of permissions it needs, treat everything it reads as untrusted input because of prompt injection, require a human approval for irreversible actions and log every tool call so you can see what it did.

Originally published on Geminate Solutions.

Kubernetes Cost Optimization for Startups: What Actually Moves the Needle

Geminate Solutions — Tue, 29 Sep 2026 15:30:15 +0000

The average engineering team running Kubernetes is wasting between 30% and 50% of their cloud spend. Not because they're careless. Because every tutorial teaches you how to deploy to Kubernetes, and almost none of them teach you what the bill looks like six months later.

We've been running production Kubernetes clusters for client SaaS products for the past three years. Two of the systems we manage regularly come up in this conversation: a 250K daily active user EdTech platform, and a real-time GPS fleet tracking system with 30K active vehicle streams. We've made the mistakes. We've fixed them. Here's what actually moved the needle.

The #1 Source of Wasted Kubernetes Spend

Before you install any FinOps tool or switch to spot instances, look at your pod resource requests.

Resource requests are what Kubernetes uses to schedule your pods onto nodes. If your pods request more CPU or memory than they actually use, nodes fill up with "reserved but unused" capacity. You're paying for the node. You're not using the node.

# What we often find when we inherit a cluster
resources:
  requests:
    memory: "1Gi"
    cpu: "500m"
  limits:
    memory: "2Gi"
    cpu: "1000m"

That pod might actually be using 80MB of memory and 30m CPU at steady state. The node was reserved at 1Gi and 500m. You're paying for 12x the memory you need.

This is almost always the root cause, and it compounds fast. Ten pods like this means you're running a cluster that needs to be one-third the size it is.

How to find it:

# See actual CPU and memory use per pod
kubectl top pods --all-namespaces --sort-by=memory

# Compare to what's requested
kubectl describe pod <pod-name> | grep -A5 "Requests:"

Run that comparison. If your actual usage is consistently below 40% of your requests, you have a right-sizing problem.

Right-Sizing: The Vertical Pod Autoscaler Does the Math For You

Manually right-sizing 50 deployments is a week of work you don't have. The Vertical Pod Autoscaler (VPA) watches your actual usage over time and recommends better values.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Off"  # Recommend only, don't auto-apply yet
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: 10m
        memory: 32Mi
      maxAllowed:
        cpu: 4
        memory: 4Gi

Set updateMode: "Off" first. Let it observe for a week. Check the recommendations:

kubectl describe vpa api-server-vpa -n production

You'll see a recommendation block with lowerBound, target, and upperBound values. In our experience with production SaaS clusters, the recommended values are typically 50-70% lower than what teams initially set. Apply those recommendations to your deployment specs manually and you'll see a meaningful drop in node count within hours.

Spot Instances: The Biggest Lever You're Not Pulling

Spot instances (AWS) or preemptible VMs (GCP) can cut your compute cost by 60-90%. The tradeoff is that the cloud provider can terminate them with a 2-minute warning.

Most startups avoid spot because they're afraid of downtime. Here's the thing: if your application can't handle a pod being killed, you have a reliability problem that Kubernetes is supposed to solve for you anyway.

The right pattern: run your stateless workloads (API servers, workers, web apps) on spot, and your stateful workloads (databases, caches, queue processors that shouldn't be interrupted mid-job) on on-demand nodes.

# Node group for stateless workloads
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: production-cluster
  region: us-east-1
nodeGroups:
  - name: stateless-spot
    instancesDistribution:
      maxPrice: 0.08
      instanceTypes: ["t3.medium", "t3a.medium", "t2.medium"]
      onDemandBaseCapacity: 0
      onDemandPercentageAboveBaseCapacity: 0  # 100% spot
      spotAllocationStrategy: "capacity-optimized"
    labels:
      workload-type: stateless
    taints:
      - key: spot
        value: "true"
        effect: NoSchedule

Then in your deployment, tolerate spot nodes:

spec:
  tolerations:
  - key: spot
    operator: Equal
    value: "true"
    effect: NoSchedule
  nodeSelector:
    workload-type: stateless
  # Ensure pods spread across availability zones
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: api-server

Set a minimum of 2 replicas on anything running on spot. When a spot node is terminated, Kubernetes reschedules the pods in under 60 seconds. The short interruption is barely visible to users in practice.

For the GPS fleet tracking system, we run everything except the TimescaleDB cluster on spot. That single change (moving the Node.js API servers and workers to spot) cut the cluster compute cost significantly, and the system has been running cleanly through months of node terminations.

Namespace Quotas: Stopping Cost Sprawl Before It Starts

One engineering team's "quick test" deployment that nobody cleaned up is a classic story. Quotas at the namespace level stop it:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: staging-quota
  namespace: staging
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    count/pods: "20"
    count/persistentvolumeclaims: "5"

Now kubectl apply in staging fails gracefully when limits are hit instead of silently spawning more compute. Add LimitRanges so that pods without explicit resource declarations get sensible defaults:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: staging
spec:
  limits:
  - default:
    cpu: 200m
    memory: 256Mi
  defaultRequest:
    cpu: 100m
    memory: 128Mi
  type: Container

This one change alone caught a situation for us where a misconfigured CI/CD pipeline was creating new pods on every commit without cleaning up the old ones. Within 20 minutes, the namespace quota was throwing errors. Without it, those pods would have run for weeks.

Horizontal Pod Autoscaling: Scale Down Aggressively at Night

If your SaaS product has predictable traffic patterns (and most do, with usage peaking in business hours and dropping at night), you should be scaling your pod count accordingly. HPA does this:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # Wait 5 min before scaling down
      policies:
      - type: Pods
        value: 2
        periodSeconds: 60

The scaleDown.stabilizationWindowSeconds is important. Without it, HPA can flap, scaling down too fast when traffic briefly dips, then scaling back up under the next request spike. A 5-minute stabilization window smooths this out.

For the EdTech platform, traffic drops to under 10% of peak between midnight and 6am. We set minReplicas: 2 for overnight and maxReplicas: 40 for peak. The cluster runs 4-6 nodes at night and 12-15 during the day. The arithmetic on that gap is significant over a month.

For workloads that should scale to near-zero (background workers, batch processors), look at KEDA. It can scale a deployment to 1 replica when a queue is empty, which HPA alone can't do.

Two Things Nobody Writes About

Image sizes compound infrastructure costs

A 2GB Docker image means a 2GB pull every time a pod starts on a new node. On Kubernetes at scale, that's bandwidth charges plus slower startup times that force you to keep more replicas "warm."

Multi-stage builds typically cut Node.js images from 800MB to under 150MB:

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Runtime stage
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

That's an 80% reduction in image size. Faster pod starts, lower bandwidth, cheaper container registry storage. Small fix, visible in the bill.

Monitoring tools aren't free to run

Prometheus with default retention settings can quietly consume hundreds of gigabytes of persistent storage. Set retention policies:

# In your Prometheus values.yaml (Helm)
server:
  retention: 15d  # down from default 90d
  retentionSize: "10GB"
  persistentVolume:
    size: 15Gi

You probably don't need 90 days of metrics in your operational monitoring store. Ship longer-term metrics to a cheaper storage layer (S3 + Thanos or Grafana Cloud's free tier) and keep hot storage lean.

Cluster Autoscaler: Make Sure It's Actually Scaling Down

Most teams enable Cluster Autoscaler (CA) for scale-up but don't configure the scale-down properly. The defaults are conservative: CA waits 10 minutes before removing a node, and only removes a node if it's been underutilized for that entire window. That's fine. But several settings override this and keep nodes alive longer than necessary.

# In your Cluster Autoscaler deployment args
- --scale-down-enabled=true
- --scale-down-delay-after-add=10m
- --scale-down-unneeded-time=10m
- --scale-down-utilization-threshold=0.5  # default is 0.5 (50%)
- --skip-nodes-with-local-storage=false   # Set false if you're not running DaemonSets with storage
- --expander=least-waste                  # Don't always spin up the largest node

The expander=least-waste setting is the one people miss. By default, CA picks a node type based on random or a configured priority. least-waste picks the smallest node that fits the pending pod. For a startup with variable workload sizes, this can meaningfully reduce the average node size provisioned during scale-up events.

One pattern that trips people up: PodDisruptionBudgets that are set too conservatively block CA from evicting pods on underutilized nodes. If you have maxUnavailable: 0 on a 1-replica deployment, CA literally cannot drain that node. Check your PDBs:

kubectl get pdb --all-namespaces

Any PDB with ALLOWED DISRUPTIONS: 0 is a potential blocker for scale-down. Fix it to allow at least 1 disruption, or increase the replica count above 1.

The Quarterly Checklist

These are the specific questions we run through every quarter on the clusters we manage:

Resources:

[ ] Any namespace where actual CPU/memory usage is below 40% of requests?
[ ] Any deployments not touched in 60+ days that might be abandoned?
[ ] Any PersistentVolumeClaims not attached to any pod?

Nodes:

[ ] What percentage of workloads could run on spot without reliability risk?
[ ] Are node sizes matched to workload shapes, or are we running m5.large for workloads that fit on t3.small?

Autoscaling:

[ ] Do all production deployments have HPA configured?
[ ] Do staging environments scale to near-zero outside business hours?

Storage:

[ ] Are Prometheus and logging retention policies set?
[ ] Any snapshots or backup volumes that can be cleaned up?

Run this once a quarter and you'll catch waste before it compounds into a surprise on your AWS bill.

Where to Start

If you're picking one thing to fix first: right-size your resource requests using VPA recommendations. It's the highest-leverage change and it costs you nothing except a week of observation data.

If you want the full picture (cost allocation across teams, charge-backs, proper FinOps practices), that's a bigger conversation. Our DevOps engineering team has run this process on production clusters serving millions of requests a day, and the patterns above are what we start with every time.

If you're at the stage of designing your infrastructure before it becomes expensive, our AWS cloud architecture services covers how we set up clusters to stay cost-effective from day one, including VPC layout, node group design, and GitOps pipelines.

The infrastructure decisions you make in the first six months of running Kubernetes are much easier to fix at the start than at $15,000/month. Most of the companies we work with wish they'd audited their resource requests in month two instead of month fourteen.

Yash Korat is the CEO and Co-Founder of Geminate Solutions, a custom software development company that has shipped 50+ products for startups across the US, UK, and Australia.

Originally published on 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.