DEV Community: Tushar Bhendarkar

How to Build an MVP with AI Tools, and Where to Stop

Tushar Bhendarkar — Sat, 10 Oct 2026 03:30:11 +0000

The part of an MVP that AI app builders get right is rarely the part that breaks. I went through 752 public reports of apps built with Lovable, Base44 and Replit going wrong, and sorted each one by its cause. Most of them weren't about the screens. They broke when the app went live, at logins and stored data, over money, and when the platform itself went down.

That matters if you're deciding how to build an MVP today. AI builders really do get you to a working product in days, and that's the right way to start. The mistake is assuming the part you can see is the part that's finished.

I build SaaS apps myself. Launch Check and Client Approvals both run on Next.js, Supabase and Stripe subscriptions, and I fix apps people built with AI tools. This is the order I'd build an MVP in: what to let the AI do, and the specific points where I'd stop and bring in an engineer.

What an MVP is, and what it is not

Eric Ries, who popularised the term, defines a minimum viable product as the version of a product that gets the most validated learning about customers for the least effort. He also warns that it isn't about building a minimal product for its own sake. The point is to learn something, which means putting it in front of people and watching what they do.

Y Combinator's Michael Seibel puts it more bluntly: the MVP is something ridiculously simple you give your first users, his advice is to launch something bad quickly, and it should take weeks, not months. Reid Hoffman, who coined the line about being embarrassed by your first version, adds the caveat people forget: launching fast isn't permission to cut corners, and if your launch alienates users, you launched too soon. That's exactly where AI-built MVPs get into trouble.

Step 1: pick one job and your first ten users

Before you open any builder, write down the one job your product does and who it does it for. YC's essential startup advice says ten customers with a burning problem beat a thousand with a passing annoyance, and quotes Paul Buchheit's rule: find the version that gets 90% of the value for 10% of the work.

Timebox it. Seibel's suggestion is to include only what you can build in three weeks, write that down, and cut features when the date slips rather than moving the date.
Do things by hand. Paul Graham describes how Stripe's "instant" merchant accounts were set up manually behind the scenes, and says that with few users you can be your software. Anything you can do by hand for the first ten users doesn't need building yet.
Find the users yourself. Graham's point is that you have to go out and get your first users; nobody arrives because the app exists.

Step 2: build the screens with an AI app builder

This is where AI builders shine. Each of them will build working screens, a database and logins from a description, and they differ mostly in what you can take with you. Here's what each one says in its own docs and pricing pages, as of October 2026.

Builder	What it builds on	Free plan	Paid from
Lovable	Lovable Cloud (built on Supabase), Git sync on every plan	5 credits a day	100 credits a month
Bolt	Bolt Cloud (Netlify and Supabase)	1M tokens a month	$25 a month
Replit	Full stack, separate test and live databases	1 app, offline after 30 days	$20 a month
Base44	All in one: database, logins, payments	25 messages a month	$16 a month, yearly
v0	Next.js on Vercel, with Supabase or Neon	7 messages a day	$30 per user a month

Whichever you pick, connect it to GitHub on the first day, so a copy of the code lives in an account you own. Lovable's plans page includes Git sync on every plan; on Base44 it needs the Builder plan. If you build with Lovable, I wrote up how to export a Lovable project to GitHub and keep the sync working.

Where AI-built MVPs break: 752 real reports

For three earlier guides I collected public reports of apps built with Lovable, Base44 and Replit breaking: 752 in total, from Reddit, the platforms' own forums, Trustpilot and Hacker News. Each platform names things differently, so I grouped them by the same causes.

Most of it was not the screens. It broke going live, at logins and data, over money, and when the platform went down.

Outside researchers found the same pattern, mostly around data. Matt Palmer scanned 1,645 Lovable apps and found weak database access rules in 170 of them. Escape.tech checked over 5,600 AI-built apps and found more than 2,000 vulnerabilities and 400 exposed secrets. And in July 2025, a Replit agent deleted SaaStr's production database during a coding session. Replit's CEO promised to separate test and live databases, and every Replit app now has both.

When to stop and bring in an engineer

None of this means you shouldn't use AI builders. It means there are specific moments when the MVP stops being a demo, and each of them lines up with a group in the reports.

Each stop sign lines up with a group in the 752 reports.

Strangers sign up and store their data

This is the one I'd never skip. In one of my own products, any logged-in user could see other customers' private data, because the app checked that you were logged in but not that the data you asked for was yours. Nothing crashed, which is why nobody noticed. OWASP found broken access control in every app it tested, and Supabase's production checklist includes row level security on every table. When I built Client Approvals, I wrote a test that checks one workspace can never see another's requests. The quick version: sign up as two users and try to open each other's records. More on this in connecting Lovable to Supabase safely.

It goes live on your own domain

"Works in the preview, breaks live" was the second biggest group, and domains added 56 more. The preview and the live app often differ in settings, secrets and even databases. Replit keeps separate test and live databases, and its free plan's one published app goes offline after 30 days. Open the live address in a private window and sign up as a new user before you send anyone the link.

You take money from customers

The payment usually works. What breaks is the app hearing about it. Stripe's webhook docs say your endpoint must verify each request came from Stripe, and that live events are retried for up to three days, so the same event can arrive twice. I wrote up the whole path in Lovable Stripe integration. Before your first real customer, buy your own product with a real card on the live site.

Running costs start to matter

Seventy-four reports were apps taken offline by credits running out, spending limits or unpaid invoices. One of my own products had AI features with no spending limit, so one bad day could have cost any amount; I added a hard cap and a switch to turn the feature off. Set limits and alerts on every service that bills by usage before launch, not after the first surprise.

Every AI fix breaks something else

Sixty-nine reports describe the loop where a small fix breaks two working things. Replit's pricing page itself warns that its agent may make mistakes, and Bolt's docs say bigger projects make the AI process more of the code on every message. When the second fix fails, stop prompting and read the actual error, or hand it to someone who will.

The business depends on it staying up

Eighty-seven reports were the platform itself having an outage. You can't fix that from inside the builder, but you can make sure you could leave. Lovable says you're never locked in, and its ownership guide lists what becomes yours if you move: hosting, backups, logins, secrets and monitoring. Keep the code, the domain and the database in accounts you own; my guide to transferring a GitHub repo covers the order.

What 146 live AI-built apps were missing

For the same guides I ran 146 live apps built with these tools through my free checkers, reading only what any browser receives. The platforms handle the basics well: all 143 apps that answered in time were on HTTPS. What's left to the app was mostly missing. 134 of those 143 sent no Content-Security-Policy, the header that limits which scripts a page may run, and 78 of the 146 sent an empty page until JavaScript ran, which hurts link previews and search.

You can check your own app in a minute with the security headers checker, or run the full Launch Check before you share the link.

What an MVP costs to build and run

Building it with an AI tool costs the subscription plus your time. Building or finishing it with an engineer is hours times a rate: in the model behind my app development cost calculator, a simple web tool with login is about 120 hours, and a SaaS first version with login, subscriptions and an admin dashboard is about 320. If most of the screens already exist, finishing is usually far cheaper than starting over.

Running it is cheaper than most people expect, from each provider's own pricing page:

Database and logins: Supabase is free to start, but free projects pause after a week without activity; Pro is $25 a month with daily backups.
Hosting: Vercel's free Hobby plan is for non-commercial use only, so a business that charges money belongs on Pro at $20 a month. Netlify and Cloudflare have free plans too.
Email: Resend is free up to 3,000 emails a month.
Payments: Stripe takes 2.9% plus 30 cents per successful US card payment, with no monthly fee.
Domain: a .com is about $11 a year at registrars like Porkbun.

The order I'd build it in

Write down the one job, the first ten users, and a three-week limit.
Build the screens and the main flow in an AI builder, and connect GitHub on day one.
Walk the first users through it, and do everything else by hand.
Before strangers sign up: access rules on every table, then the two-account test.
Before going live: your own domain, production settings and secrets, and a private-window test.
Before taking money: verified webhooks and one real purchase on the live site.
Set spending limits and alerts on everything that bills by usage.

An MVP is for learning, not for launching twice

The fastest way to build an MVP today is to let an AI builder do the screens and spend your own time on the users. The slowest is to launch an app that loses someone's data and have to win their trust back. Use the AI for speed, and treat the stop signs as the moment the MVP becomes a product.

If you're already past that point, the platform guides go deeper: Lovable, Base44 and Replit. And if you'd rather hand it over, I take MVP builds and finishing work on as client projects: send me what you're building and where it stands.

Common questions

What is an MVP?
A minimum viable product is the smallest version of your product that lets you learn whether real users want it. Eric Ries, who popularised the term, defines it as the version that gets the most validated learning about customers for the least effort. It is a way to learn, not a smaller copy of the full product.

How long should it take to build an MVP?
Weeks, not months. Y Combinator's Michael Seibel suggests timeboxing the spec, for example to what you can build in three weeks, writing it down, and cutting features rather than moving the deadline. Some startups begin with nothing more than a landing page and a spreadsheet.

Can I build an MVP with AI tools like Lovable or Replit?
Yes, for the screens, the main flow and your first users. Bring in an engineer before strangers store their data, before you go live on your own domain and before you take money: those are where 752 public reports of Lovable, Base44 and Replit apps show things break.

Which AI app builder is best for an MVP?
It depends less on the builder than on what you can take with you. Lovable, Bolt, Replit, Base44 and v0 all build working web apps; check what each exports, whether GitHub sync is on your plan, and where your data lives. Connect GitHub on day one, whichever you pick.

How much does it cost to run an MVP?
Often under $60 a month at the start: Supabase Pro is $25 (the free plan pauses idle projects), Vercel Pro is $20 for a business that charges money, email is free up to 3,000 a month on Resend, a .com is about $11 a year, and Stripe takes 2.9% plus 30 cents per US card payment.

When should I hire a developer for my MVP?
When strangers start storing data in it, when it goes live on your own domain, when you take money, when running costs start to matter, when every AI fix breaks something else, or when the business depends on it staying up. Before that, an AI builder is usually enough.

Is an AI-built MVP secure?
Not by default. Lovable says its scans do not replace a thorough security review, and Base44 says you are responsible for your app's security settings. Turn on row level security for every table and test with two accounts: neither should be able to open the other's records.

This post first appeared on tusharbhendarkar.com. I write about the engineering behind what I ship. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.

n8n Not Working? Why Workflows Stop, and the Fix for Each Cause

Tushar Bhendarkar — Fri, 09 Oct 2026 06:40:00 +0000

Most broken n8n workflows aren't broken by n8n. I read 398 public reports from n8n's community forum and Reddit where someone's automation stopped working, and in 317 of them the thread found the cause. Only about 1 in 10 was a bug in n8n. The rest were a setting, another app's rules, or the workflow itself.

That sounds like good news, but it's also why these problems drag on. n8n can't warn you about a setting it doesn't know is wrong, and many of these failures make no noise at all: a schedule that never fires, a webhook pointing at an address nobody can reach, a Google sign-in that expires every seven days.

The templates most people start from don't help much here. I ran the 200 most-viewed workflows on n8n's template library through my n8n workflow checker: of their 368 HTTP Request steps, 333 have no retry and no error handling, so one failed call ends the whole run.

Below are the causes in the order I'd check them, each with the fix from n8n's own documentation, and what I found in those templates at the end.

What 398 broken n8n workflows had in common

The reports run from January 2025 to September 2026: 340 threads from n8n's community forum and 58 from Reddit's r/n8n. I sorted each one by the cause the thread gave, from the poster, an accepted answer, an n8n staff member or another reply, or by the main symptom when nobody found one.

Self-hosting and webhooks lead. Of the reports with a stated cause, about 1 in 10 was a bug in n8n.

Two things stood out. Self-hosting problems were the biggest group, and most of them weren't about n8n's code at all: they were about memory, Docker and the proxy in front of it. And the group that hurts most, workflows that work when you click the button but never run on their own, was also the least solved: 16 of those 34 threads never found a cause.

It works when you click it, but never runs on its own

Start here, because the most common reason changed recently. Since n8n 2.0 in December 2025, the old Active toggle is gone. Your edits save automatically as a draft, and nothing goes live until you click Publish. Live runs keep using the last published version, so a workflow can show "Published, has changes": it's running, but not the version you fixed. A publish can also partly fail, with some triggers switched on and others not.

Then check what starts it, and when:

A real trigger. The Manual Trigger only runs when you click. A workflow needs a Schedule, Webhook or app trigger to run by itself, and since 2.0 n8n won't publish one without it.
No pinned test data. Data you pinned while testing is ignored in live runs, so a workflow that only worked because of pinned data behaves differently once published.
The right timezone. The Schedule Trigger uses the workflow's timezone, or the instance's if none is set, and self-hosted n8n defaults to New York time. Set it under Workflow settings, or with GENERIC_TIMEZONE on your server. Changing the schedule after publishing does nothing until you publish again.
Runs missed while n8n was down are gone. By default, schedules live in memory, so a run whose time passes during a restart or crash is skipped, not caught up. A durable scheduler that can catch up arrived in n8n 2.36, but it's off unless you turn it on.
Email triggers that check for new mail. Several Gmail threads came down to the "only unread emails" filter, or to checking for new mail every minute. Polling less often, every five minutes, fixed one of them.

The webhook worked in testing, then stopped

Every Webhook node has two addresses. The test URL, with /webhook-test/ in it, only listens for 120 seconds after you click Listen for test event. The production URL, with /webhook/, only works while the workflow is published, and its runs appear in the Executions tab rather than on the canvas. A webhook that worked in testing and then went quiet is very often still pointing at the test address.

On a self-hosted server, the bigger problem is the address itself. In 22 webhook reports, the cause was n8n not knowing its own public address, so it handed out links like http://localhost:5678 that nothing outside your server can reach. n8n builds webhook addresses from N8N_HOST, which defaults to localhost. Behind a reverse proxy, n8n's proxy guide says to set N8N_WEBHOOK_URL to your public https address and N8N_PROXY_HOPS to 1. Most guides still say WEBHOOK_URL: that name is deprecated from version 2.35, though it still works with a warning.

Setting the variable isn't always enough. In several threads it was written in an .env file that never reached the program: a Docker Compose file with no env_file line, or n8n started as a system service without its environment file. Telegram and WhatsApp were involved in about 30 of the webhook reports: both only accept a webhook address they can reach over https, and both allow one webhook per bot or app, so a second workflow quietly takes over from the first. And on n8n Cloud, a webhook that takes longer than 100 seconds to answer fails with a 524 error, so long jobs should answer right away and do the work afterwards.

Self-hosting: memory, Docker and "Connection lost"

Self-hosting was the biggest group, with 70 reports. Running n8n yourself is cheap, but you become the person who looks after the server, and these are the problems that came up again and again:

"Connection lost" in the editor. It was the most common error message in the whole set, and in about 10 threads the cause was a proxy like NGINX not passing WebSocket connections through. If it appears in the middle of a run instead, the instance may have crashed.
Running out of memory. n8n puts no cap on how much data a step loads, so one big spreadsheet or file can crash it, often showing up as "Connection lost" or a 503 rather than a clear memory error. n8n suggests working in smaller batches, such as 200 rows per run instead of 10,000. Testing by hand uses more memory than live runs, because n8n keeps a copy for the editor.
Data gone after an update. The official Docker setup keeps everything in a volume at /home/node/.n8n. In one thread the volume pointed at /root/.n8n instead, so every update started from a blank setup screen.
"Credentials could not be decrypted." n8n encrypts your saved logins with a key it creates on first launch and stores in that same folder. Lose the folder, or start n8n with a different key, and every saved credential becomes unreadable. Even if your data lives in Postgres, keep that volume and back up the key.
Runs stuck in "queued". In queue mode, workers do the actual work. In the most-viewed thread of this group, the extra containers had been started without their worker command, so jobs waited forever. Workers also need the same encryption key as the main instance.

Google sign-in that keeps expiring

Credentials were 45 reports, and most involved Google. Two causes came up again and again. The first, in 15 threads, was a redirect address mismatch, which Google reports as redirect_uri_mismatch: it only accepts the exact address you registered, so copy the OAuth Redirect URL from n8n into Google Cloud Console character for character, including https and the port. On a self-hosted server that address often said localhost, for the same reason webhooks do.

The second is a Google app left in Testing mode. n8n's Google docs note that apps in Testing with External users lose their sign-in after seven days, so a workflow runs for a week and then stops. Publishing the app in Google Cloud Console ends that. On n8n Cloud, many Google nodes offer a managed "Sign in with Google" that avoids building your own Google app at all.

It broke after an n8n update

Forty-three reports were workflows that broke after updating, and about 23 of them involve the 2.x versions that started in December 2025. n8n called 2.0 a hardening release, and it changed defaults on purpose:

Code nodes can no longer read environment variables.
The Execute Command node is switched off, and file nodes can only reach one folder.
OAuth callback addresses now need authentication, and the old Python Code node was removed.
Activate became Publish, so saving no longer changes what's live.

The rest were plain regressions, and the fix that worked most often was moving to a newer Stable release (about 13 threads), with three people rolling back instead. Two n8n Cloud users were on a Beta version without knowing it, which broke every Code node they had. n8n recommends the Stable track for anything important, pinning an exact version, updating at least monthly so the jumps stay small, and a full backup first. Since 2.0 there's also a Migration Report under Settings that lists what will break before you upgrade.

If you self-host, plan for the next one now. n8n says version 3.0 is due in October 2026: it supports only Docker for self-hosting, cuts the Code node time limit from five minutes to one, and removes the old Cron, Interval and Function nodes along with the first version of the AI Agent node.

The AI Agent doesn't use its tools

Fifty reports were about the AI Agent node, and the biggest group was an agent that answered without using its tools, or called them with empty values. n8n's agent docs and the accepted answers point to the same fixes:

Describe each tool. The description is how the agent decides when to use it, so say plainly what it does and when to call it.
Let the model fill the inputs. When a tool always got empty input, the fix an n8n staff member gave was $fromAI(), which lets the model supply that value.
Use a model that calls tools well. Small local models sometimes write the tool call as plain text instead of making it. A larger model fixed it in one thread, and n8n 2.40 added a Force Tool Call on First Iteration option for exactly this.
Look at what it actually did. When a tool fails, the error goes back to the agent as text and can disappear inside its friendly answer. Turn on Return Intermediate Steps to see every tool call.
Store memory somewhere real. Simple Memory doesn't last between sessions and doesn't work in queue mode. For a chat that should remember people, use a database-backed memory, and give it a session ID, which a Telegram trigger doesn't provide by itself.

An agent that answers confidently without checking its tools is the same problem I wrote about in why AI chatbots give wrong answers: the fix is usually in what the model is given, not in the model.

Outside APIs, rate limits and n8n Cloud limits

A 429 error means the other service is telling you to slow down, and n8n shows it as "The service is receiving too many requests from you." The HTTP Request docs give two fixes: turn on Retry On Fail in the node's settings, or send requests in batches, such as one per second. Not every 429 is about speed, though. In one thread it was an OpenAI account out of credits, and in another a provider cut the limit when the account balance dropped.

On n8n Cloud, the plan limits are the other surprise. When you hit your monthly execution limit, n8n's help center says new runs fail at once with "Execution limit reached". They aren't queued and they aren't re-run later, even though your triggers keep firing. The limit resets on the first of each calendar month, not your billing date. Memory is small too: the Starter plan gets 320 MiB, and n8n itself uses about 180 of that, so a few large files or several AI steps at once can crash the workspace. About 8 Cloud users in the reports hit exactly that.

What I found in the 200 most-viewed n8n templates

Most people don't start from a blank canvas. They import a template, so I took the 200 most-viewed workflows on n8n's public template library, with 11.7 million views between them, and ran each one through my free n8n workflow checker, which reads the same workflow file you import into n8n.

Templates show the happy path. Retries and alerts are the part you have to add yourself.

To be fair to the authors, templates are starting points, and an error alert usually lives in a separate workflow, so it wouldn't be part of a template anyway. But that's the point: when you import one, nothing in it tells you what will happen when a step fails. Of 368 HTTP Request steps, only 12 retry, and 333 have neither a retry nor any error handling. Thirty-seven templates only run when you click, and 13 still carry pinned test data that live runs ignore.

Three templates had an expression pointing at a step that had been renamed. In one, the step was now called "Appointment Scheduling Agent1" while the expression still asked for "Appointment Scheduling Agent", so that step fails as soon as it runs. The good news: none of the 200 contained a real API key. Keys live in credentials, which never travel with a workflow, so after importing you connect your own.

What keeps an n8n workflow running

Almost every cause in this post is quiet. The workflow doesn't crash in front of you. It stops firing, or fails at 3am, and the run sits in the Executions list where nobody looks.

I learned that on one of my own products. It ran a daily job that published broken content about nine days a month, and nobody was told, because it never threw an error. What fixed it wasn't a smarter job: it was checking the result before publishing, and sending an alert when it failed.

In n8n, that means three things. Create one error workflow that starts with an Error Trigger and emails or messages you, and select it in each workflow's settings; one error workflow can serve all of them. Turn on Retry On Fail for every step that calls another service. And where a run can fail without an error, like an empty result or a half-written record, add a check that stops the run with a Stop And Error node, so it reaches your alert too. Since version 2.5, n8n emails the owner once on the first live failure if no error workflow is set, but only once, so don't rely on it.

If you'd like a quick look first, paste your workflow into the n8n workflow checker. It runs in your browser, so the workflow never leaves your computer. There are more guides on automations in Automate and connect your tools.

And if you'd rather hand it over, I take these on as client projects: send me the workflow and where it stops.

Common questions

Why is my n8n workflow not running automatically?
Since n8n 2.0, edits are saved as drafts and only go live when you publish, so check for "Published, has changes". The workflow also needs a real trigger, not the Manual Trigger. If it runs at the wrong hour, set the timezone, and remember that scheduled runs missed while n8n was down are skipped by default.

Why does my n8n webhook work in test but not in production?
The test URL (/webhook-test/) only listens for 120 seconds after you click Listen for test event. The production URL (/webhook/) only works while the workflow is published, and its runs show up in the Executions tab, not on the canvas. Make sure the other app calls the production URL.

Why does my n8n webhook URL show localhost?
Self-hosted n8n builds webhook addresses from N8N_HOST, which defaults to localhost. Behind a reverse proxy, set N8N_WEBHOOK_URL (WEBHOOK_URL on versions before 2.35) to your public https address and N8N_PROXY_HOPS to 1, then restart. In Docker, check that the variable actually reaches the container.

What does "Connection lost" mean in n8n?
The editor lost its live connection to the server. Behind a reverse proxy like NGINX it usually means WebSocket upgrade headers are not being forwarded. If it appears in the middle of a run, the instance may have crashed, often from running out of memory.

Why does my n8n AI Agent not call its tools?
Give each tool a clear description of when to use it, and let the model fill tool parameters with $fromAI(). Small models sometimes write the tool call as plain text instead of making it; try a stronger model or the Force Tool Call on First Iteration option added in n8n 2.40. Turn on Return Intermediate Steps to see what it actually called.

Why do my n8n Google credentials keep expiring?
If your Google Cloud app is in Testing mode with External users, Google expires the sign-in after seven days. Publish the app in Google Cloud Console. A redirect_uri_mismatch error is different: copy the OAuth Redirect URL from n8n into Google exactly, including https and the port.

What happens when n8n Cloud hits its execution limit?
According to n8n's help center, new executions fail immediately with "Execution limit reached", they are not queued, and they do not re-run later. Triggers keep firing, so you lose those runs. The limit resets at the start of each calendar month, not on your billing date.

Why did n8n break after I updated it?
Version 2.0 (December 2025) changed defaults on purpose: Code nodes can no longer read environment variables, Execute Command is disabled, and file nodes can only reach one folder. Check the Migration Report under Settings before upgrading, back up first, and pin a Stable version rather than updating to the newest Beta.

This post first appeared on tusharbhendarkar.com. I fix and build automations in n8n, Zapier and Make, and I build the free n8n workflow checker. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.