How to Build an MVP as a Solo Founder (No Funding, 2026)

Short answer: Pick the one workflow a paying customer would actually use, and cut everything else into "should" and "later" lists. Build it with whatever you can finish fastest: code you already know, an AI app builder, or no-code. Ship it in two to six weeks with real login, payments, backups and error alerts, charge from the first day, and decide by a date you set in advance whether to keep going.

That is the whole method. The rest of this guide turns it into steps: a scoping framework, a build path decision table, an illustrative week-by-week plan, the production basics checklist, a cost table with prices checked on 7 Nov 2026, a definition of done, how to get first users, kill criteria and the mistakes that eat months. The prices and quotes come from the linked vendor and founder pages. The advice in between is ours and is marked as such.

TL;DR#

• Scope to one workflow. An MVP is the smallest complete path from "I have this problem" to "it is solved and I paid for it". Not a mini version of the full product.
• Pick the build path you can finish. Code you know beats a shiny framework. An AI app builder such as Lovable or Bolt (each $25/mo on its entry paid plan) beats learning to code from zero. No-code or a manual service beats both when the value is a process.
• Plan two to six weeks. If the plan does not fit, cut scope, not sleep.
• Ship the production basics anyway. Auth, payments, backups, error alerts, uptime checks and three to five analytics events. Most cost $0 at MVP scale.
• Budget around $65 a month once you charge. Vercel's Hobby plan is "for personal, non-commercial use" (Vercel pricing), so a paying product moves to Pro at $20/mo. Add Supabase Pro ($25/mo), an AI coding assistant such as Claude Pro ($20/mo) and Stripe's 2.9% + 30¢ per US card charge.
• Write done and kill criteria first. Both with numbers and a date.

Disclosure: ZeroRaised publishes this guide and runs a launch site for bootstrapped products. ZeroRaised has no commercial relationship with any vendor named here and no links are affiliate links. Prices and limits come from the linked pages as checked on 7 Nov 2026 and can change; check them on the day you sign up.

MVP (minimum viable product) here means the smallest version of your product that a real customer can use end to end to get the core result, and pay for, so you can learn whether people want it from behaviour rather than opinions.

Before you build: validation in one paragraph#

Building is the expensive part, even when the tools are cheap, because the cost is your weeks. So before you open an editor you want some evidence: a handful of conversations with people who have the problem, a clear description of what they do today, and ideally a few who said yes to paying or joined a waitlist with a specific promise. We cover that process in detail in how to validate a SaaS idea before building, so we will not repeat it here. This guide assumes you have done at least the basic version and have a short list of people to show the MVP to.

Our read: if you cannot name five specific people who would try the MVP the week it ships, you are not ready to build. You are ready to do more conversations.

Step 1: Scope the MVP to one core workflow#

Most solo MVPs fail on scope, not code. The founder plans a product, then calls the first version an MVP while it still contains a dashboard, settings, team invites, three integrations, a mobile layout and an admin panel. Six months later, nothing is live.

The fix is to scope around a workflow, not a feature list.

Find the core workflow#

Write one sentence in this shape:

A [specific customer] uses [product] to [do one job] so they get [one result] without [the painful thing they do now].

Then list the steps that customer takes from arriving to getting the result. For a fictional invoice-chasing tool for freelance designers (illustrative):

1. Sign up with email.
2. Connect or paste in unpaid invoices.
3. Pick a reminder schedule.
4. Reminders send automatically.
5. See which invoices got paid.
6. Pay for the service.

That is the MVP. Every screen and every line of code should serve one of those six steps. Anything else goes on a list.

Sort everything into must, should and later#

Take every feature idea you have and put it in one of three buckets. Be harsh: if you hesitate, it is not a must.

Rules we use:

• Must is capped. If the must list has more than about seven items, the scope is too big. Merge or cut.
• Manual counts. If a must item can be done by you by hand for the first ten customers (importing their data, sending a report, approving accounts), do it by hand and build it later.
• Should items get one slot. You may pull one should item into the MVP if it is cheap and customers asked for it by name in validation. Only one.
• Later is a parking lot, not a promise. Keep it in a file so you stop worrying about forgetting ideas. Do not show it to customers as a roadmap.

Cut the usual suspects#

These almost never belong in a solo founder's first version:

• Settings pages. Hard-code sensible defaults. Change them for a customer on request.
• Team and role management. Sell to one user per account first.
• Admin panels. Use your database's table editor.
• Native mobile apps. A responsive web page is enough to learn.
• Multiple pricing tiers. One plan, one price.
• Integrations. Unless the integration is the product, use email, CSV or copy and paste.
• Custom design systems. Use a component library and one font.

Our read: the test of good scoping is that the MVP feels slightly embarrassing to you and complete to the customer. They should be able to get the whole result, even if it looks plain.

Step 2: Choose your build path#

You have three realistic paths. The right one depends far more on what you can finish than on what is technically best.

The three paths#

1. Code you already know. If you can already build web apps in a stack, use it. Learning a new framework for your MVP adds weeks and a lot of decisions. AI coding assistants make this path faster: Claude Pro is $20/mo billed monthly, or $17/mo with the annual discount ($200 up front), and its plan includes Claude Code (Claude pricing).

2. An AI app builder. Tools such as Lovable and Bolt generate a working web app from prompts, with hosting built in.

• Lovable's free plan includes 5 build credits a day (up to 30 a month) plus 20 Cloud credits a month. Its Pro plan starts at $25/mo billed monthly, or $250 a year, from 100 credits a month, and adds custom domains (Lovable plans, Lovable credits).
• Bolt's free plan includes 1M tokens a month with a 300K token limit per day. Pro is $25/mo billed monthly and starts at 10M tokens a month, with custom domain support and no Bolt branding (Bolt pricing).

3. No-code or concierge. If the value is a process (matching, curation, reporting, a done-for-you service), you may not need custom software yet. A form, a spreadsheet, an email tool and Stripe Payment Links can deliver the first version while you do the middle part by hand.

Build path decision table#

This is our editorial advice.

If you use an AI app builder, keep ownership#

AI app builders are fast, but a paid SaaS needs a few things you must understand and control:

• Export or sync the code to GitHub so you are not locked in.
• Know where the data lives (which database, which account) and that you can back it up.
• Check access rules. Generated apps can ship with database rules that let any logged-in user read every row. Before real users arrive, log in as two different test users and confirm neither can see the other's data.
• Wire payments yourself, carefully. Test the full checkout, cancellation and failed payment flows in Stripe test mode.

Our read: AI builders are a fine way to build an MVP and a risky way to run a business you do not understand. Spend an evening reading the code they generate for login and payments, even if you never write a line yourself.

Pick a boring stack and stop#

If you are coding, decide the stack in one sitting and do not revisit it until you have paying users. A typical boring choice for a solo SaaS is a full-stack web framework you know, a managed Postgres database with auth built in, hosted on a platform that deploys from Git, with Stripe for payments. Our SaaS tech stack for solo founders goes tool by tool through hosting, databases, auth, email and the rest, so this guide only covers what you need to launch.

Step 3: A week-by-week MVP plan#

This plan is illustrative: a template for a single-workflow web app built by one person working focused hours, not a promise of how long yours will take. Squeeze it to two weeks for a simple tool or stretch it to six if you are building around a job. If your scope does not fit in six weeks, go back to Step 1.

Two rules make this plan work:

1. Deploy on day one. Production surprises (environment variables, email deliverability, webhooks, domains) are cheaper in week one than in launch week.
2. Every week ends with something usable on the live URL. If a week ends with only local code, the next week starts by fixing that.

Our read: for someone with a job, a realistic version is the same six steps spread over evenings and weekends. Protect two longer blocks a week for the hard parts (payments, the core logic) and use short evening sessions for copy, emails and small fixes.

Step 4: The production basics an MVP still needs#

"Minimum" applies to features, not to reliability. A customer who pays you and loses their data, or hits an error you never see, will not give you a second chance. These are the basics we would not skip, even for a first version.

Production basics checklist#

A few notes on the less obvious lines:

• Backups. The free tier of your database may not back anything up. On Supabase, Free projects also "are paused after 1 week of inactivity" (Supabase pricing). That is fine for building, not for customers. Upgrade before real data arrives, then restore a backup into a test project once, so you know it works.
• Payments webhooks. The checkout page is the easy part. The webhook that marks an account as paid, and the one that handles cancellations and failed renewals, is where solo MVPs break. Test each case in Stripe's test mode.
• Analytics. Track a few events on purpose instead of capturing every click. "Signed up", "completed the core workflow", "paid" and "came back within a week" tell you nearly everything at MVP stage.
• Hosting terms. Vercel's fair use guidelines say "Hobby teams are restricted to non-commercial personal use only" and that "All commercial usage of the platform requires either a Pro or Enterprise plan", with examples that include "Any method of requesting or processing payment from visitors of the site" (Vercel fair use guidelines). If you host on Vercel, plan to move to Pro when you switch on checkout.

Our read: the whole checklist is roughly two to four days of work for someone who has done it before and about a week for someone who has not. Put it in the plan instead of hoping to add it after launch.

Step 5: What it costs (verified prices)#

Here is what the common pieces cost, from each vendor's own page on 7 Nov 2026. Swap tools freely; the shape of the budget is what matters.

Cost table#

Lovable's docs note that part of its current pricing is described as a temporary offer, so check the plan page before you rely on the credit numbers.

Three illustrative monthly budgets#

These are illustrative examples built from the table above, not quotes. They exclude taxes and usage overages.

A. Coded MVP while building, before taking payments: about $0 a month plus the domain. Vercel Hobby, Supabase Free, Sentry Developer, Resend Free, PostHog Free, UptimeRobot Free. Add an AI assistant if you want one ($20/mo for Claude Pro billed monthly). Fine for building and for free beta users who know the data may be wiped. Not fine for paying customers.

B. Coded MVP taking payments: about $65 a month plus fees.

C. AI app builder MVP taking payments: about $25 a month plus fees. Lovable Pro or Bolt Pro at $25/mo with hosting included, plus the domain and Stripe fees. Add Supabase Pro ($25/mo) if your builder's app uses your own Supabase project and you want backups. Heavy prompting can use up credits or tokens faster than the entry plan includes, so watch usage in the first month.

What Stripe takes from a $19 subscription (illustrative)#

Take a fictional $19/mo plan paid with a US domestic card through Stripe Billing:

• Card processing: 2.9% of $19 = $0.55, plus $0.30 = $0.85
• Billing: 0.7% of $19 = $0.13
• Total fees: about $0.98, so you keep about $18.02

At 10 customers that is about $180 a month after Stripe fees, which covers budget B with room to spare. That is the point of charging from day one: a small number of paying users makes the MVP self-funding.

Our read: the money is rarely what stops a solo MVP. The real budget is weeks. Spending $20 a month to save a week is almost always worth it.

Step 6: Define "done" before you start#

Without a definition of done, an MVP is never finished, because there is always one more feature. Write this list in week zero and treat it as the finish line.

The MVP is done when:

1. A stranger from your target customer group can sign up on the live domain without help.
2. They can complete the core workflow end to end and get the promised result.
3. They can pay, and paying unlocks the product automatically.
4. They can cancel, or at least email you to cancel and you can do it in a minute.
5. You get an alert within an hour if the site is down or the core workflow throws errors.
6. Their data is backed up and only they can see it.
7. You can see, in your analytics, how many people signed up, completed the workflow and paid.
8. There is a privacy policy, terms and a support email.

Not part of done: a pretty design, settings, a mobile app, onboarding tours, integrations, a blog, a perfect landing page, SEO, a referral program, a second pricing tier, or anything from the later list.

Our read: if you have ticked all eight and still feel the urge to keep building before showing anyone, that is fear, not quality control. Ship it.

Step 7: Get your first users#

The MVP is a tool for learning, and you only learn when people use it. Paul Graham's advice to early founders still applies: "The most common unscalable thing founders have to do at the start is to recruit users manually." And: "You can't wait for users to come to you. You have to go out and get them." (Paul Graham, Do Things That Don't Scale).

Do this in order:

1. Go back to the people you validated with. Email or message each one personally with a short note: what you built, the one problem it solves, a link, and an offer to set it up with them on a call. These are your warmest users.
2. Onboard the first five by hand. Watch them use it (on a call with screen sharing, or with session replay). Every place they hesitate is a fix for this week.
3. Charge from the start. A price, even a low one, is the cleanest validation signal you will get. If you offer a discount, give a reason ("founding customer price for the first 20") and a date.
4. Go where your customers already are. The communities, forums and newsletters you found during validation. Answer questions, share what you learned building, and link the product where it is welcome.
5. Launch in public once the basics work. A launch is a traffic spike, not a strategy, but it is a good way to get your first strangers. Our guide on how to launch a bootstrapped app covers the launch week, and where to launch a SaaS lists the sites worth your time.

For a step-by-step on turning these first users into revenue, see how to get your first 10 paying customers.

Our read: do not wait for the launch to get users. The first five should come from direct, personal outreach before any public launch, so the launch shows a product that already works for someone.

Step 8: Set kill criteria (and respect them)#

Bootstrapping means your scarcest resource is time. The worst outcome is not a failed MVP. It is a zombie MVP that you keep polishing for a year because nothing clearly told you to stop.

So write kill criteria before you launch, with numbers and a date. A template (the numbers are illustrative; set your own):

And a date: "By [date, six to eight weeks after the first real users], if I do not have [number] paying customers who used the core workflow more than once, I will stop or pivot."

What "change something" usually means:

• Narrow the customer. The product might be right for a smaller group than you targeted.
• Change the core workflow. Users may be using one part and ignoring the rest. Make that part the product.
• Change the price or packaging. Rarely the main problem, but worth one test.

What it does not mean: adding the next five features from the later list. If the core workflow does not pull people back, features on top will not either.

Our read: stopping an MVP after a fair test is a good outcome. You spent weeks, not years, and you keep the code, the audience and the lessons for the next one.

What solo founders say about their own MVPs#

These examples come from each founder's own post, or in one case a published interview, fetched on 7 Nov 2026. The quotes are verbatim. We have not added figures they did not state.

Pieter Levels: test demand before building the site#

Pieter Levels, the maker of Nomad List, describes how the product began in his post on reaching number one on Product Hunt and Hacker News: "Instead of building a site first, I simply made public Google spreadsheet to collect the first data and see if there'd be interest for this at all" (levels.io).

In a separate post on how he builds his MVPs, he explains his tooling: "I have a very basic stack." He adds: "Except for jQuery, I don't use any frameworks." And on why: "Why? Because many times, they just make things more complex." (levels.io).

The lesson for your MVP: the first version can be the cheapest thing that tests interest, and the stack can be the simplest one you know. Both posts date from 2014, so the specific tools are old; the principle is not.

Tony Dinh: a weekend build that solved his own problem#

Tony Dinh wrote up the launch of TypingMind on his newsletter. He built a new interface on top of OpenAI's newly announced API: "On Monday, 6th March, 5 days after OpenAI announced their API, I finished the first version and shared it on Twitter." The architecture was minimal: "No backend, no server, and no database." Four days later, by his own account: "By 10th March, I hit $10K in revenue from my weekend project." (Tony Dinh).

The lesson: removing whole layers of the product (here, a backend) is a legitimate scoping move, not a shortcut. Our read: timing mattered a lot here (he shipped days after the API launched), so treat the revenue as his result, not a benchmark.

Marc Lou: a headline, a buy button and one feature#

Marc Lou's guide to building a startup in 24 hours reduces the MVP to "A headline, a buy button, and 1 feature." He is blunt about validation: "You can only validate an idea if people pay for it." And: "A waitlist isn't enough." (Marc Lou).

The lesson: a buy button belongs in the first version, which is why payments are on our must list and in the definition of done.

Danny Postma: speed, then focus on what worked#

In an interview with Unite.AI, Danny Postma describes his earlier product ProfilePicture.AI: "I quickly developed and launched my product within 30 hours, beating a competitor to market." Later, about his headshot product: "Seeing the demand for AI-generated headshots, I decided to focus more on HeadshotPro." (Unite.AI interview).

The lesson: ship fast, then follow the demand. The "change something" column in the kill criteria table above is exactly this move: double down on the part customers actually want.

Our read: none of these founders started with a full product. Each started with one narrow thing people could use or pay for quickly, and grew from what customers did with it.

Common mistakes solo founders make with MVPs#

1. Building before talking to anyone. The most expensive mistake, because everything after it is built on a guess. Validate first, even briefly.
2. Scoping a product instead of a workflow. If your must list has a settings page, team invites and an admin dashboard, start again from the core workflow sentence.
3. Learning a new stack for the MVP. A new framework, a new database and a new hosting platform at once means you are running three learning projects and no business.
4. Deploying at the end. Leaving deployment until launch week turns small configuration issues into a crisis. Deploy on day one.
5. Skipping payments "until it is ready". Free users tell you what they will use. Paying users tell you what is worth money. You need the second answer.
6. Running customers on free tiers with no backups. Fine while building, a real risk once customers trust you with data. Upgrade the database before the first paying user.
7. Trusting AI-generated code blindly. Read the login, access rules and payment code, or have someone you trust read it. Test with two accounts to make sure neither can see the other's data.
8. Over-instrumenting. Fifty tracked events and three dashboards nobody reads. Track the handful that answer "did they get the result, did they pay, did they come back".
9. Polishing instead of selling. If you have spent a week on the landing page and have not messaged a single potential user, swap the order.
10. No kill date. Without one, every week of no traction feels like "almost there". Set the date before you launch.

A one-page MVP checklist#

Copy this into your notes and tick it off.

Week 0

• Core workflow sentence written
• Must list of about seven items or fewer; should and later lists parked
• Build path and stack chosen (and not revisited)
• Done criteria and kill criteria written, with a date
• Domain bought, five named people ready to try it

Build

• Deployed to the real domain on day one
• Login and password reset working
• Core workflow works end to end in production
• Stripe checkout, webhook, cancellation and failed payment tested in test mode
• Transactional emails sending from your domain

Production basics

• Database on a plan with automatic backups, one restore tested
• Access rules tested with two accounts
• Error monitoring and uptime alerts going to your phone
• 3-5 analytics events firing
• Privacy policy, terms and support email live

Ship

• First five users onboarded personally
• Live payments switched on, price shown
• Launch plan ready
• Decision date in the calendar

Frequently asked questions#

How long should it take a solo founder to build an MVP?#

Our working range is two to six weeks of focused building for a single-workflow software MVP. If your plan needs longer than about six weeks, the scope is usually too big: cut features until one complete workflow fits. Pure no-code or AI app builder projects can be faster; products with real compliance or hardware needs take longer and are outside this guide.

How much does it cost to build an MVP without funding?#

It can be close to $0 while you build, because Vercel Hobby, Supabase Free, PostHog, Sentry Developer, Resend and UptimeRobot all have free plans. Once you take payments, Vercel's Hobby plan no longer fits because it is for personal, non-commercial use, so a typical coded stack becomes about $65 a month (Vercel Pro $20, Supabase Pro $25, Claude Pro $20) plus a domain from about $11.81 a year at Porkbun and Stripe fees of 2.9% + 30¢ per US card charge. Prices checked 7 Nov 2026.

Should I use no-code, an AI app builder or write code for my MVP?#

Use code if you already know a stack, because you will ship faster and avoid a rewrite. Use an AI app builder such as Lovable or Bolt (both from $25 a month on their entry paid plans) if you cannot code and your product is a fairly standard web app. Use no-code or a manual concierge service if the value is in a process rather than software. The deciding question is which path gets one workflow live and charging in the fewest weeks.

When is an MVP done?#

When a stranger from your target customer group can sign up, complete the core workflow, get the promised result and pay, without you on a call, and when you would notice within an hour if it broke. Polish, settings pages, extra integrations and a mobile app are not part of done.

When should I stop working on an MVP?#

Decide before you launch. A simple version: if, after a fixed window such as six to eight weeks of real outreach, you cannot get a set number of target users to use the core workflow more than once, or nobody will pay, stop or pivot. Write the numbers and the date down in advance so you judge the result against a plan rather than hope.

Ship it, then launch it#

ZeroRaised is a launch directory for products built without institutional VC. When your MVP passes the done checklist, submit it to ZeroRaised for free and get it in front of other bootstrapped makers. For more build and launch guides for solo founders, join the ZeroRaised newsletter.

Sources#

• Vercel pricing, last checked 7 Nov 2026
• Vercel fair use guidelines, last checked 7 Nov 2026
• Supabase pricing, last checked 7 Nov 2026
• Stripe US pricing, last checked 7 Nov 2026
• Stripe support: manually entered card payments (confirms the 2.9% + 0.30 USD standard US card fee), last checked 7 Nov 2026
• Stripe Billing pricing, last checked 7 Nov 2026
• Claude pricing, last checked 7 Nov 2026
• Lovable subscription plans, last checked 7 Nov 2026
• Lovable plans and credits, last checked 7 Nov 2026
• Bolt pricing, last checked 7 Nov 2026
• Sentry pricing, last checked 7 Nov 2026
• PostHog pricing, last checked 7 Nov 2026
• Resend pricing, last checked 7 Nov 2026
• UptimeRobot pricing, last checked 7 Nov 2026
• Cloudflare Registrar docs, last checked 7 Nov 2026
• Porkbun .com pricing, last checked 7 Nov 2026
• Pieter Levels: Nomad List on Product Hunt and Hacker News, last checked 7 Nov 2026
• Pieter Levels: How I build my minimum viable products, last checked 7 Nov 2026
• Tony Dinh: Making $22K in 7 days, the story, last checked 7 Nov 2026
• Marc Lou: How to build a startup in 24 hours, last checked 7 Nov 2026
• Unite.AI: Danny Postma interview, last checked 7 Nov 2026
• Paul Graham: Do Things That Don't Scale, last checked 7 Nov 2026