To build an MVP with AI, define the single problem it solves and the one action users must complete, describe that flow in one prompt and share the live link with a handful of real users. Iterate in the same chat based on what they do, adding accounts or payments only when the test needs them.
- An MVP is an experiment, not a small copy of your product. It exists to test your riskiest assumption.
- Pick one user, one problem and one action that proves value. Everything else waits.
- One prompt can produce a live, hosted first version. WisyLink's free plan deliberately builds a lean first slice, which is what an MVP should be.
- Watch five real users before you change anything, then change one or two things per follow-up message.
- Count the core action in the app's own data. Page views and sign-ups alone tell you little.
- WisyLink doesn't export code, so graduating means a rebuild that uses your MVP as a living spec.
What an MVP is, and what it isn't
- Minimum viable product (MVP)
- The smallest working thing you can put in front of real users to find out whether your riskiest assumption is true.
The term comes from the Lean Startup method, which describes a build-measure-learn loop: identify the problem, then develop an MVP "to begin the process of learning as quickly as possible" (Lean Startup principles). The output you care about is learning, not software.
That rules out a few things founders often call an MVP:
- A mockup or clickable prototype. Useful for design feedback, but nobody can actually get value from it, so it can't tell you whether they would.
- Version 1.0 with fewer polish passes. If it has settings pages, profiles and an onboarding tour, it isn't minimum.
- A demo for investors. A demo shows what could exist; an MVP shows what real users did.
"Viable" matters as much as "minimum". The one thing it does must work for real: the booking is actually booked, the request actually reaches you, the payment actually arrives. Behind the scenes, you can do parts of it by hand.
Pick the one job your MVP must do
Start with a sentence you can be wrong about: "[Who] will [do this action] because [this problem], and I'll know it's true when [this many of them] do it within [this time]." If you can't fill in the last part, you don't have a test yet, only a hope. For the school kit-swap example below, it might read: "Parents at one school will list outgrown sports kit because binning it feels wasteful, and I'll know it's true when 20 items are listed and 10 claimed within two weeks of one newsletter mention." Those numbers are yours to choose; what matters is choosing them before launch.
Then name the assumption that would kill the idea if it were false. Usually it is one of four: nobody wants this (demand), it doesn't solve the problem well enough (value), people won't pay (price), or you can't get the supply side (marketplaces). The riskiest assumption picks the MVP type:
| MVP type | What to build | Success signal |
|---|---|---|
| Landing page and waitlist | One page that states the offer and price, a sign-up form, a follow-up email | Sign-ups from strangers in your target group, and replies when you email them |
| Concierge | A request form and an admin queue; you deliver the result by hand | People request it again, or pay for the manual version |
| Single-feature app | The one workflow end to end, with saved data and accounts only if needed | Users finish the core action without help and come back |
| Marketplace pilot | Listings you seed yourself, browse filters, a request or claim button | Completed matches, and both sides return |
If demand is the open question, start with the first row; our guide to building a waitlist landing page with AI covers it. If people clearly want the outcome but you doubt your delivery, a concierge MVP lets you learn the job before you automate it.
Scope it into a single prompt
A good MVP prompt reads like a short brief to a contractor: who it's for, the one job, the pages, the data, the rules, and an explicit list of what to leave out. That last list matters most, because builders, human or AI, fill gaps with features.
Build a first version of [product name] for [specific user]. The one thing it must do: [core action], so that [outcome].
Pages: [a home page that explains the offer], [the core flow], [a confirmation].
Save: [records and their fields]. Rules: [limits, statuses, who can see what].
Leave out for now: [accounts, payments, email, profiles, settings].
Add an admin page where I can see every [request] and a daily count of [core action]. Style: [tone, colors, mobile-first].
A filled-in example for a two-sided pilot:
Build a first version of KitSwap for parents at one school. The one thing it must do: let a parent list outgrown sports kit and let another parent claim it for free. Pages: a home page explaining how it works, a "list an item" form with one photo, sport, size and condition, a browse page filtered by sport and size, and a claim button that asks for name and email. Each item can be claimed once. Leave out accounts, payments and messaging. Add an admin page showing every item and claim, with daily counts of new items and claims. Style: friendly, school colors navy and yellow, big buttons for phones.
Notice what is missing: logins, chat between parents, ratings. If the pilot works, those are follow-up messages. If it doesn't, you saved yourself building them.
Build, test with five real users, iterate in the same chat
This is the whole playbook in seven steps:
- Write the hypothesis and the success signal before you build, so the result can't be reinterpreted later.
- Paste your prompt into a new WisyLink chat. If something material is unclear, Wisy asks one short question; otherwise the build starts and a live task list shows the work. The result is a hosted web app at its own address.
- Read the build's final note. It says what was built and whether anything waits for you under Integrations, such as Stripe or email settings.
- Run the core flow yourself on a phone and a laptop. When something is wrong, describe it precisely in the chat: what you did, what you expected, what happened.
- Put it in front of five real users from your target group, not friends. Watch them use it, in person or by screen share, without explaining anything.
- Write down behavior, not opinions: where they hesitated, what they tried to click, where they gave up, what they asked for unprompted.
- Change one or two things per follow-up message in the same chat, then test again with new people. Each change is a new build, and a failed build leaves the last working version live.
Why five? Usability research by Jakob Nielsen concluded that "the best results come from testing no more than 5 users and running as many small tests as you can afford" (Nielsen Norman Group). Five users show you where the flow breaks. They don't prove demand; for that you need reach, such as a waitlist page shared with strangers.
Recruit outside your own network: the parents' group, trade forum or local community where your target users already talk. Ask for 20 minutes, offer a small thank-you, and schedule the sessions before the build is finished, so the link meets real people while your questions are fresh.
On the free Community plan you get one build per 5-hour window. That pace suits this loop: collect a round of feedback, pick the one or two changes that matter most, and send them in one message.
Add accounts, payments and email only when tests need them
Every one of these adds setup, testing and friction for users. Add each when the hypothesis requires it, not because real products have them.
- Accounts, when users must come back to their own data: saved items, history, a dashboard. Until then, name and email fields are enough. The app runs its own sign-up and login; Google sign-in is possible with your own OAuth credentials.
- Payments, when willingness to pay is the assumption. Money is the strongest signal an MVP can collect. Checkout runs through your own Stripe account (or another provider's), stays inactive until you add your keys under Integrations, and marks an order paid only when the provider's signed webhook confirms it. Test with Stripe's test keys first.
- Email, when the flow needs a confirmation or a follow-up. It goes through your own SMTP account; without one, email steps send nothing and everything else works.
Each addition is one follow-up message, for example: "Add sign-up and login so parents can see the items they listed and claimed. Keep everything else as it is." Never paste a key or password into the chat; the build tells you which Integrations field to fill in.
Measure what users do, not what they say
WisyLink has no built-in analytics dashboard, so plan measurement as part of the build. Use two layers:
- Product events in the app's own data. Ask the app to record each key action, such as item listed, item claimed or order paid, with a timestamp, and show daily counts on the admin page. These numbers are exact and private, and they measure the thing your hypothesis is about.
- Traffic from an analytics provider. For visits and sources, ask for your analytics tool to be connected. If it needs a secret key, the build declares a field under Integrations and you paste the key there.
Track four things: activation (the share of visitors who complete the core action), return (who comes back within a week), conversion (who pays or joins) and drop-off (the step where people quit). Set the threshold that counts as success before you look. For the kit swap, a fair rule is: continue if most listed items are claimed within a week; rethink the offer if items sit unclaimed while visits are high, because that points to the wrong audience or the wrong items. Add one optional question after the core action, such as "What almost stopped you?", and keep the admin dashboard to a few numbers.
Time and cost: realistic expectations
How long does it take to build an MVP with AI? A live first version can come out of a single chat session, and you watch the build happen. The calendar is set by everything around it: deciding the one job, recruiting five real users, running the sessions and making changes. Plan the test as a fixed window of a week or two with a decision at the end, rather than an open-ended build. Paid plans shorten the wait between builds and let several apps build at once, which helps once you run more than one experiment.
How much does an MVP cost? On WisyLink:
- Community: free, with a usage allowance that refills over a 5-hour and a weekly window. Enough for a first slice.
- Starter $7, Growth $20, Scale $100 a month for fuller builds, more usage and links that don't expire while you're subscribed.
- Outside costs: a domain if you want one (at your registrar's price; connecting it works on any plan), your payment provider's processing fees if you charge, an email provider for SMTP, and any analytics tool.
- Your time, which is the largest cost in every route.
For the developer-built comparison, see what it costs to build a web app and AI app builder vs hiring a developer. One timing trap: free links stay live for 30 days, then spend a week marked for deletion before they are deleted with their data. If your test outlasts that, or you've printed the link on flyers, upgrade first.
Common MVP mistakes, and when to graduate
Mistakes that waste a test
- Building the second feature before anyone has used the first.
- Testing with friends. They are kind, and kindness is noise.
- Counting sign-ups instead of the core action. A sign-up is a promise; the action is the proof.
- Changing five things at once, so you can't tell which change mattered.
- Adding logins on day one when name and email would have done.
- Polishing visuals while the flow still confuses people.
- Letting the free link expire mid-test, taking your data with it.
When to graduate: hire developers or rebuild
If the MVP works, it can keep serving real customers on a paid plan; there is no rule that says you must rebuild. Graduate when a requirement doesn't fit what a hosted AI-built web app does:
- You need a native App Store or Google Play app, not a web app.
- You need full-text search across large amounts of data.
- Enterprise customers demand single sign-on, a specific hosting location or compliance reports.
- The product depends on long-running processing or minute-precise schedules.
- An engineering team needs to own and change the code directly.
WisyLink doesn't export source code, so graduating means developers build a new version. That is less painful than it sounds: your MVP is a living spec of the flows, the data model, the copy and, most valuable, the evidence of what users actually did. Ask early for a CSV export of your key records, so your data moves with you. A useful handover pack has four parts: the live link, a written list of every flow and rule, the exported data, and your notes from user sessions. For the founder side of this, read shipping without a technical co-founder, and for why some versions are meant to be replaced, disposable software.
Build your MVP this week
Write your hypothesis, fill in the prompt template with your one job and your leave-out list, and book five user sessions before the build finishes. If you want to understand what runs under the hood before trusting it with customers, the product page explains isolation and reliability, and the plans show what changes when you upgrade.
Describe your MVP in one message and get a live link: start free on Community, no card required.
F.A.Q.