I Gave 5 AI Website Builders the Same Prompt: Lovable vs v0 vs Bolt.new vs Replit vs Base44

An original first-generation test of Lovable, v0, Bolt.new, Replit, and Base4

Disclosure: This article contains referral links for Bolt.new and Replit. Depending on the program's terms and your eligibility, I may receive referral rewards or credits if you sign up through these links. These relationships did not determine the scores or conclusions in this comparison. Other links in the Sources & Test Builds section lead to official pricing pages or my test builds.

Experiment date: September 26, 2026

Live retest: October 7, 2026

The original applications were generated from the same first-generation prompt in June 2026. I later retested the published Bolt.new and Base44 builds in the browser in October 2026 to verify functionality that could not be fully confirmed during the original audit.

There’s a point in using an AI website builder where the magic wears off.

The first few seconds are impressive.

You describe a product. The AI writes code. A layout appears. Cards slide into place. A dashboard suddenly exists where there was nothing five minutes ago.

Then you click something.

That is where the real test begins.

A search box that doesn't search, a “View details” button that never opens a page, a contact form that says “Message sent” without sending anything — those are very different from a website that merely looks good in a screenshot.

So I ran a simple experiment.

I gave Lovable, v0, Bolt.new, Replit, and Base44 the exact same prompt and asked each one to build the same product:

AI Stack — “Tell us the goal. We’ll build the stack.”

I then looked at the first-generation results and tested the resulting apps as far as the available browser and testing tools allowed.

The goal was not to find out which company has the longest feature list.

It was much simpler:

What happens when you give five AI builders the same job and actually use what they make?

The Experiment

The product brief was deliberately practical.

The generated site had to let a visitor:

• choose a goal
• choose a monthly budget
• choose a technical level
• receive a personalized AI-tool stack
• browse an AI tools directory
• search and filter tools
• open tool detail pages
• compare up to three tools
• use a contact form
• use the site on mobile

Every builder received the same core prompt.

The prompt

Build a polished, production-style web application called “AI Stack”.

Tagline:
“Tell us the goal. We’ll build the stack.”

The product helps people discover the right combination of AI tools for a specific goal instead of browsing a huge directory.

TARGET USERS:
- Students
- Content creators
- Freelancers
- Developers
- Small business owners
- Non-technical beginners

CORE EXPERIENCE:

The homepage should immediately ask:

“What are you trying to accomplish?”

Provide selectable goal cards:

- Study smarter
- Start a YouTube channel
- Create content
- Build a website
- Build a SaaS product
- Start a business
- Freelance
- Grow a blog
- Automate repetitive work
- Design faster

Then ask:

“What is your monthly budget?”

Options:
- Free
- Under ₹500
- ₹500–₹2,000
- ₹2,000–₹5,000
- I don’t mind paying for the right tools

Then ask:

“How technical are you?”

Options:
- I don’t code
- Beginner
- Comfortable with technology
- Developer

After the user submits the questionnaire, generate a personalized “AI Stack” result.

RESULT PAGE:

Show:
- Stack name
- Short explanation
- Estimated monthly cost
- Estimated setup time
- Difficulty level
- Number of tools

Display the recommended workflow visually:

Step 1 → Step 2 → Step 3 → Step 4 → Step 5

Each recommended tool should have:
- Tool name
- Category
- Short description
- Free/Paid badge
- Why it was selected
- Estimated price
- “Try Tool” button
- “View Details” button

Create realistic sample data for at least 15 AI tools across different categories.

Include example tools such as:
ChatGPT, Claude, Gemini, Perplexity, Canva, ElevenLabs, CapCut, Lovable, v0, Bolt.new, Replit, Midjourney, NotebookLM, Gamma, and Notion AI.

IMPORTANT:
The recommendation engine should actually change the results based on:
- Goal
- Budget
- Technical level

Do not show the same stack for every user.

PAGES:
- Home
- Find My Stack
- Stack Results
- AI Tools
- Tool Details
- Compare
- About
- Contact

AI TOOLS DIRECTORY:

Create a searchable and filterable directory.

Filters:
- Category
- Price
- Free/Paid
- Beginner friendly
- Use case

Tool cards should open real detail pages.

COMPARE PAGE:

Allow users to compare up to 3 tools.

Show:
- Pricing
- Main use case
- Free plan
- Key features
- Difficulty
- Best for

DESIGN:

Create a premium SaaS-style interface.

The design should feel like a modern startup product rather than a generic AI tools directory.

Use:
- Strong typography
- Excellent spacing
- Clean cards
- Subtle animations
- Clear visual hierarchy
- Responsive layouts
- Accessible contrast
- Professional icons

Avoid:
- Excessive gradients
- Neon AI clichés
- Excessive glassmorphism
- Generic template appearance
- Unnecessary animations

FUNCTIONALITY:

The following must actually work:
- Goal selection
- Budget selection
- Technical-level selection
- Recommendation logic
- Search
- Filters
- Tool detail navigation
- Compare functionality
- Mobile navigation
- Contact form validation
- Buttons and links

Do not create decorative controls that do nothing.

Use realistic content rather than lorem ipsum.

The website should feel like a real product that could be launched publicly.

Prioritize:
1. Useful user experience
2. Functional interactions
3. Visual polish
4. Responsive design
5. Clean architecture

The Five Builders

Each site was generated from the same prompt. No builder was given a custom follow-up instruction during the first-generation experiment.

How I Judged Them

I deliberately separated visual polish from working functionality.

A site could look fantastic and still lose points if its controls didn't work.

The comparison focused on:

The scores below are editorial scores based on the evidence collected in this experiment, not scores published by the companies.

Testing limitation: The original experiment used a mixture of live/browser testing, visual inspection, builder self-audits, and source-code/logic audits. Bolt.new and Base44 were initially assessed more heavily through implementation evidence. On October 7, 2026, I performed additional live browser testing on both published builds using the same recommendation, directory, comparison, contact-form and mobile checks. Where a finding comes from the later retest rather than the original experiment, I identify it as a live retest finding. The retest reflects the behavior of these specific generated applications at the time of testing; it is not a benchmark of the builders’ current products as a whole.

Lovable

Test build: View my test build ↗

Official website: Visit Lovable ↗

First impression

Lovable produced a polished, recognizably modern SaaS interface.

The core journey is easy to understand:

Goal → Budget → Technical level → AI Stack

The homepage is focused on the recommendation flow rather than overwhelming the user with a giant directory.

That focus is a real strength.

What the first-generation app did well

The Lovable audit found the major user journeys working end to end.

The three recommendation profiles produced different stacks.

SaaS + ₹500–₹2,000 + Developer

Perplexity → Claude → Replit → v0 → n8n

Displayed cost: ₹1,650/month

Setup: 8 hours

Difficulty: Advanced

YouTube + Free + Beginner

Perplexity → Claude → ElevenLabs → Descript → Canva

Displayed cost: ₹0/month

Setup: 8 hours

Difficulty: Beginner

Website + ₹2,000–₹5,000 + I don't code

ChatGPT → Claude → Canva → Gamma

Displayed cost: ₹3,050/month

Setup: 6 hours

Difficulty: No-code

The audit also found working search, filters, tool pages, comparison, navigation, contact validation, USD/INR switching and a functioning mobile menu.

That is a lot of application behavior for a single generation.

Where Lovable struggled

The recommendations weren't always semantically sensible.

For example, its no-code SaaS stack could omit a dedicated app-building tool even though Lovable itself was in the database.

The website stack could include Gamma, a presentation-oriented tool, as part of the website-building workflow.

The mobile homepage also had overlapping floating cards.

The contact form was another interesting case: it displayed a successful submission state, but the test found that the message was not actually sent or saved anywhere.

Lovable also reported that its tool prices were still marked “Not yet verified.”

One more caveat: after its audit, Lovable reported making a small fix after a blank-screen issue appeared on the stack-results page. That means the post-audit state should not be described as completely untouched.

Lovable score

Evidence: Original live/browser testing and audit

What stood out: a very complete first-generation product with unusually broad functionality, but recommendation semantics and a few trust/UX details still need work.

v0

Test build: View my test build ↗

Official website: Visit v0↗

v0 was the biggest contrast in this experiment.

The interface can look polished, but the first-generation product was noticeably less complete than the others in the functionality we could verify.

What worked

The homepage loaded correctly.

The AI Stack branding and main call-to-action were present.

The recommendation wizard advanced through its initial path.

The directory supported search.

For the tested SaaS profile:

v0 → Lovable → ChatGPT → Gamma

with an estimated ₹1,200/month.

Where things broke down

The most significant issue was that several requested product areas were missing or unreachable.

The audit found:

• no discoverable Contact page
• a mobile hamburger that did not reveal a usable menu
• the “View details” action did not open a real detail page in the tested state
• advanced directory filters were not exposed
• comparison and contact testing could not be completed

There was also a questionable pricing presentation.

The SaaS recommendation showed ₹1,200 estimated monthly, while the listed tools were displayed as free in that result.

And the explanation under the tools was essentially a repeated template:

“fits your build a saas product”

rather than a tool-specific reason.

Another issue discovered in the audit was that the site used client-side state changes rather than normal anchor navigation for its main interactions, limiting ordinary deep-link behavior.

The recommendation engine also needed more testing. Only one full profile was completed in the self-audit, so we cannot honestly claim a complete three-profile comparison for v0 based only on that audit.

v0 score

Evidence: Original live/browser testing and self-audit

What stood out: v0 showed how easy it is for a generated interface to feel like a product before all the requested product surfaces are actually there.

Bolt.new

Test build: View my test build ↗

Official website: Visit Bolt ↗

Bolt produced one of the most ambitious implementations in the test.

Its code-level audit showed a substantial application structure rather than a simple mockup.

Recommendation results

SaaS + Developer

ChatGPT → Claude → Lovable → Bolt.new → Make

YouTube + Free + Beginner

ChatGPT → Canva → ElevenLabs → CapCut → Suno

Website + No-code

ChatGPT → Lovable → NotebookLM → Claude → Gemini

The recommendation engine did produce different stacks for different goals and technical levels.

The directory implementation also included:

• search
• category filtering
• price filtering
• beginner filtering
• use-case filtering
• combinations
• clearing filters

Tool detail pages and comparison were implemented as well.

Five tools, four workflow steps

This was confirmed during live testing. Bolt displayed 5 tools in the generated stack, but the workflow section displayed only 4 numbered steps. The result therefore had one tool without a dedicated workflow role.

This matters because the prompt explicitly requested a five-step workflow. The issue isn’t simply presentation: assigning every recommended tool to a meaningful step is part of the product’s core recommendation experience.

The contact form only simulated a successful submission

I tested the public contact form and received a “Message sent” confirmation. I then repeated the test while monitoring the browser’s Fetch/XHR requests. No network request was generated by the submission.

I also inspected the generated ContactPage.tsx implementation. The submit handler validates the fields, changes local React state to show the success screen, and clears the form, but it does not call an API, database, email service, webhook, or other backend destination.

Result: the form looked functional and reported success, but the submitted message was not actually transmitted or stored in the tested build.

Other issues

Other issues included identical icons for the goal cards, duplicate Compare navigation, placeholder-style contact information, and potentially misleading aggregate “Free” cost labeling for freemium stacks. The later live mobile retest at 390 × 844 did not reproduce a general responsiveness failure.

Live retest

The original Bolt assessment relied heavily on a source-code/logic audit. I later retested the published build in the browser using the same core scenarios and feature checks used for Base44.

The live retest confirmed that Bolt generated different recommendation results for different goals, its directory search and filters worked, its tool detail and comparison flows worked, and its three-tool comparison limit was enforced.

The retest also confirmed two important issues from the original audit: the application displayed five recommended tools but only four meaningful workflow steps, and the contact form displayed a successful submission state without actually sending or storing the message.

Bolt score

Evidence: Original audit + October 2026 live retest

*Based largely on implementation evidence rather than a full independent live-browser sweep.

What stood out: a broad, technically ambitious app whose interface and code structure were ahead of its recommendation semantics.

Want to try the builder yourself? Try Bolt.new (referral link) ↗

Replit

Test build: View my test build ↗

Official website: Visit Lovable ↗

This was the most visually impressive result in the experiment based on the screenshots we captured.

It looked like someone had spent time polishing the product rather than simply filling a template.

The result page had clear hierarchy, useful stats, tool cards and a convincing workflow presentation.

But this was also where the experiment produced one of its best lessons:

a beautiful product can still have logic bugs underneath it.

Recommendation results

SaaS + ₹500–₹2,000 + Developer

The audit recorded:

Bolt.new → Replit → v0 → Claude

with an estimated ₹499–₹1,700 and a flexible/advanced-style workflow.

YouTube + Free + Beginner

ChatGPT → Canva → ElevenLabs → CapCut

Website + ₹2,000–₹5,000 + I don't code

Lovable → Canva → ChatGPT → v0

The goal generally changed the stack, but paid budget bands and more technical levels didn't always change the actual tool list.

The cost problem

One of the clearest findings was that the displayed estimated monthly cost did not reliably match the selected tools.

For one SaaS result, the listed tools had individual prices that added up to much more than the aggregate range shown by the interface.

The audit traced that to a hard-coded budget range rather than an actual sum of selected tools.

That is a serious trust issue for a recommendation product.

The mobile bug

At approximately 390 × 844, the results page expanded to 461px wide, creating horizontal scrolling.

That's a concrete, measurable mobile defect.

The contact-form problem

The form displayed a success state, but the audit found no network request or persistence behind the submission.

In other words:

the interface said the message was sent; the application did not actually send it.

Other issues

The audit also found:

• only four workflow steps shown despite the five-step brief
• a stale Compare count after removing an item
• default Replit metadata still in the page head
• directory search not covering all metadata
• budget and technical-level personalization weaker than the product implied

Replit score

Evidence: Original visual/live observations and detailed audit

What stood out: the most polished visual result we saw, paired with several genuinely important implementation and recommendation issues.

Want to try the builder yourself? Try Replit (referral link) ↗

Base44

Test build: View my test build ↗

Official website: Visit Base44 ↗

Base44 came surprisingly close to Replit in the overall polish of the result.

Its first-generation app also had a very complete product structure.

Recommendation results

SaaS + Developer

Perplexity Pro → Claude → v0 → Replit → Gamma

₹1,700/month · 57 min · Moderate

YouTube + Free + Beginner

Perplexity → ChatGPT → ElevenLabs → CapCut → Canva

₹0/month · 47 min · Easy

Website + ₹2,000–₹5,000 + No-code

ChatGPT Go → Framer → Canva → Grammarly → Perplexity

₹4,449/month · 70 min · Easy

One of Base44's strongest characteristics was that its recommendation engine genuinely used goal, budget and technical level as inputs in the implementation audit.

What changed when I controlled the inputs?

I also ran two controlled recommendation tests.

First, I kept the goal as Build a SaaS product and the technical level as Developer, then changed the budget from ₹500–₹2,000/month to Free. The underlying five-tool workflow remained the same, but the paid plan selection and displayed cost changed.

Second, I kept the goal as Build a SaaS product and the budget as ₹500–₹2,000/month, then changed the technical level from Developer to I don’t code. This produced a different tool stack.

This suggests that, in the tested build, technical level directly changed the recommended tools, while budget affected plan selection and total cost without necessarily changing the underlying workflow.

Directory

The code-level audit found all five requested filter types:

• category
• use case
• price
• free/paid
• beginner-friendly

It also supported combinations and clearing filters.

Search for writing returned relevant tools, while xyzabc123 produced an empty state.

Tool pages and compare

Tool details were comprehensive.

The compare system supported:

• adding tools
• removing tools
• replacing tools
• maximum three tools
• comparison persistence
• comparison table

The application also had recovery states for invalid routes, missing answers and nonexistent tools.

Three-tool limit confirmed live

The application explicitly enforces a maximum of three comparison tools. When three tools were selected, the remaining Compare controls were disabled. After removing one selection, another tool could be added successfully.

This behavior was verified directly in the live application.

Where Base44 struggled

Its price filter had an important semantic problem.

The implementation used the first paid tier as the “starting price,” meaning a tool with a free usable plan could still be excluded from a low-price filter.

The search also didn't cover the full description field.

And the budget recommendation could be greedy.

In the SaaS profile, for example, it spent most of the user's ₹2,000 budget on Perplexity Pro while leaving ₹300 unused.

That is not necessarily a bug, but it shows the difference between:

budget-aware

and

budget-optimized

Contact submission was actually persisted

The public form displayed its success state after submission. Unlike Bolt.new, I was able to verify the submitted record in the Base44 dashboard.

The ContactMessage entity contained the submitted name, email, topic and message, with the record created by an anonymous user.

This confirms that the contact form was not merely displaying a simulated success message in the tested build.

Live retest

The original Base44 report was primarily a static/code audit, but I later performed live browser testing of the published build. The live retest verified the recommendation flow, directory search and filters, comparison behavior including the three-tool limit, contact-form persistence, and responsive behavior at 390 × 844. Browser Back/Forward behavior and every possible external-link destination were not exhaustively tested.

Base44 score

Evidence: Original audit + October 2026 live retest

*Some categories rely on code-level evidence rather than a complete independent live-browser run.

What stood out: strong recommendation/data architecture, good cross-page consistency, and a surprisingly complete application generated from the same single brief.

The Results Side by Side

Here is the clearest way to look at the first-generation builds.

The Three Recommendation Tests

This was one of the most revealing parts of the experiment because every builder was asked the same three scenarios.

Profile A

Build a SaaS product

Under ₹2,000/month

Developer

*Where a self-audit did not complete all profiles, this row should be treated as the observed/available result rather than a complete three-profile measurement.

Profile B

Start a YouTube channel

Free

Beginner

Profile C

Build a website

₹2,000–₹5,000

I don't code

The interesting part isn't simply that the stacks are different.

It's how intelligently the roles line up.

A stack can contain the “right kind” of tools while still attaching them to the wrong workflow steps.

What This Experiment Actually Taught Me

The easiest thing for an AI website builder to generate is a convincing homepage.

The hard part is everything behind it.

A static directory is easy to fake.

A search box is easy to draw.

A contact form is easy to style.

A “Compare” button is easy to place.

The difficult part is making those pieces behave correctly together.

That's why some of the most interesting findings in this experiment were not visual at all.

Lovable's contact form could report success without actually sending the message.

Replit's contact form had a similar problem.

Bolt's workflow could contain a correct-looking five-tool stack while attaching tools to semantically wrong steps.

Base44 could be budget-aware without necessarily optimizing how the budget was spent.

v0 could present a clean interface while missing several requested product surfaces.

The lesson is straightforward:

A generated website should be tested as an application, not judged as a screenshot.

So Which One Actually Built the Best Website?

There isn't one meaningful answer for every kind of user.

But the experiment does reveal some clear patterns.

Replit produced the strongest visual first impression

The screenshots made this the standout from a pure interface/design perspective.

The product looked polished, coherent and close to something you might expect from a real SaaS landing page.

But that polish was hiding meaningful logic and data problems, particularly around cost calculations, budget behavior, contact persistence and mobile overflow.

Base44 produced one of the strongest recommendation/data implementations

The recommendation engine responded to goal, budget and technical level, and the application used a shared data source across its major views.

Its weaknesses were subtler: price-filter semantics, search coverage and budget optimization.

The later live retest strengthened that conclusion: its recommendation flow produced distinct stacks across user profiles, its directory and comparison features worked as expected, and its contact submissions were actually persisted. The remaining limitation is that changing the budget alone did not change the underlying SaaS tool list in the controlled test.

Lovable produced one of the strongest end-to-end first generations

The live/browser audit gave us a lot of confidence that its core user journeys were actually functioning.

Its weaknesses were mostly around the quality and semantics of recommendations rather than missing major product surfaces.

Bolt built a broad and ambitious application

The live retest confirmed that Bolt’s generated application has a substantial amount of working functionality. Search, filtering, tool details, external tool links, comparison and the three-tool limit all worked in testing.

However, two issues were especially important. The application displayed five recommended tools but only four workflow steps, leaving one tool without a meaningful role. More seriously, the contact form reported a successful submission without actually transmitting or storing the message in the tested build.

The result is therefore more functional than a simple mockup, but its polished interface still hides important application-level gaps.

v0 was the least complete first-generation product in this particular test

It demonstrated a polished starting point but left several explicit requirements missing or unreachable in the tested state.

That doesn't mean v0 is incapable of building them.

It means this exact one-prompt run did not produce them reliably enough for this experiment.

The Biggest Surprise

Before running the experiment, it would have been easy to assume the builder with the prettiest result would also have the strongest application.

That wasn't what happened.

The experiment repeatedly showed a gap between:

“This looks finished.”

and

“This is finished.”

That gap is probably the most useful thing to know before using any AI website builder.

Should You Build a Real Website With One Prompt?

Yes — but treat the first generation as a starting point.

A good AI builder can get you dramatically closer to a working product than starting from an empty editor.

But before you publish a real business application, test:

• every important button
• search
• filters
• forms
• navigation
• mobile layouts
• external links
• error states
• pricing calculations
• authentication, if applicable
• SEO metadata
• accessibility
• performance
• security

And most importantly:

Don't trust the success message. Test the action behind it.

Free Plans and the Cost of Experimenting

The five builders use different pricing and usage models, so their free tiers are not directly comparable. Some measure usage through credits, while others use messages, tokens, or daily usage limits.

As of October 8, 2026, the official pricing pages show:

Lovable has a Free plan with a daily grant of 5 build credits, capped at 30 per month. Free workspaces also receive monthly Cloud and AI credits.

v0 has a Free plan with a 7-message-per-day limit. Its Free plan also includes monthly credits and lets users deploy apps to Vercel.

Bolt.new offers a Free plan with a 300,000-token daily limit and a 1 million-token monthly limit, plus hosting and Bolt branding.

Replit has a free Starter plan with daily Agent usage and the ability to publish one app. Its paid Core plan adds more usage and monthly credits.

Base44 has a Free plan with 25 message credits and 100 integration credits per month. Message credits are used while building, while integration credits are consumed by actions in live apps.

Because these systems meter usage differently, the raw numbers are not an apples-to-apples comparison. The more useful question is:

How much useful work can I get done before I hit the free-tier limit?

Pricing checked: October 8, 2026. Pricing, usage limits, and plan features may change after publication.

Affiliate Disclosure

Some links in this article may be affiliate links. If you purchase through one of those links, TechAffiliate may earn a commission at no additional cost to you. Affiliate relationships did not determine the experimental scores or conclusions in this article.

Final Take

AI website builders have crossed an important threshold.

You no longer need to know how to write every line of a web application before you can get a serious prototype on screen.

But this experiment also made something very clear:

Generating a website is becoming easy. Verifying a website is still work.

Five builders received the same prompt, and all five produced something recognizable.

All five could create a polished-looking product.

But they made different assumptions.

Some were stronger visually.

Some were stronger structurally.

Some were better at carrying the user's inputs through the recommendation system.

Some looked finished while still leaving important interactions incomplete.

That's why I wouldn't judge an AI website builder from its first screenshot.

Open the site.

Click the buttons.

Change the inputs.

Try the search.

Submit the form.

Open it on your phone.

Then decide whether the result is actually useful.

The first generation is the demo. The behavior is the review.

FAQ

Can AI website builders really build a website from one prompt?

Yes. In this experiment, all five produced a working website/application prototype from the same natural-language brief. The quality and completeness of the resulting functionality differed.

Which AI website builder produced the best-looking result?

In this particular experiment, Replit produced the strongest visual first impression based on the screenshots we captured. That does not mean its generated application had the fewest technical issues.

Which AI website builder had the strongest recommendation logic?

Base44 showed the clearest evidence that goal, budget and technical level could all influence the generated stack in the implementation audit. Other builders also changed recommendations, but with different limitations.

Are free plans enough for a test like this?

Yes, although the limits vary. Free plans are sufficient for an initial experiment, but a complex multi-page project can consume a meaningful portion of the available usage.

Is a one-prompt website ready for production?

Not automatically. You should independently test functionality, mobile behavior, SEO, accessibility, security, forms, links and content before publishing a production site.

Should I choose an AI website builder based on appearance?

Appearance matters, but it shouldn't be the only criterion. A polished interface can contain broken or simulated functionality.

Methodology and Limitations

This article combines several types of evidence:

Original live/browser testing, where available.

Screenshots and visual inspection of the generated applications.

Builder self-audits, where supplied.

Source-code/logic audits, where live verification was unavailable or incomplete.

Follow-up live retesting of the published Bolt.new and Base44 builds on October 7, 2026.

These evidence types are not equivalent. A source-code finding can show that a behavior is implemented, but it does not necessarily prove that a user can successfully complete the action in a live browser. Conversely, a live success message does not prove that a backend operation actually occurred.

For that reason, this article distinguishes between what was live verified, what was implementation evidence, and what remained unverified.

The scores are editorial scores for this experiment, not standardized industry benchmarks.

The websites were generated from the same prompt, but the underlying AI systems are probabilistic and can produce different results between runs.

Sources & Test Builds

Official product/pricing sources

• Lovable Pricing: Official pricing page
• v0 Pricing: Official pricing page
• Bolt.new Pricing: Official pricing page
• Replit Pricing: Official pricing page
• Base44 Pricing: Official pricing page

Test builds

• Lovable: Open my test build ↗
• v0: Open my test build ↗
• Bolt.new: Open my test build ↗
• Replit: Open my test build ↗
• Base44: Open my test build ↗