A perfect-looking screen can hide a broken product. Our five-tool test showed how quickly that happens.

Part 2 of 3: The Readiness Gap
Part 1 used one deliberately vague prompt - "Create a portfolio" - across five AI app builders. The category looked impressive. Every tool could move from a short request toward a visual application. But the benchmark also exposed a harder problem: visual completion and product completion are not the same thing.

---

Beauty is now cheap

This is the uncomfortable truth about the current AI app-builder market.

A polished first screen is no longer rare.

In our test:

• Base44 produced a strong first-look UI in about two minutes;
• Lovable generated a balanced result in about five;
• Emergent produced a visually striking experience;
• Kimi attempted modern motion and visual ideas;
• Replit generated a real editable React/Vite project.

The category baseline has moved.

Fast visual generation is expected.

That is good for users.

It also creates a new risk:

The better the first screen looks, the easier it is to assume the product behind it is equally finished.

Our test showed several reasons that assumption is dangerous.

---

Failure 1: the preview can break before the app exists

Kimi Websites gave us the cleanest example.

The first preview was blank because GSAP failed.

The agent identified the issue.

But the tool limit stopped the automated repair from completing.

Eventually, the project was published after a fix.

That sounds like a small technical incident.

It is actually a product-design problem.

The user asked for a portfolio.

The user did not ask to debug an animation dependency.

The moment a generated dependency can blank the application, three questions become part of the user experience:

1. Who detects the failure?
2. Who can repair it?
3. Can the repair finish before credits, tools or actions run out?

The diagnosis is not the product.

Recovery is the product.

---

Failure 2: a six-minute build can become a 30-minute publish failure

Replit Agent generated the project in roughly six minutes.

Then publishing failed.

Three attempts.

More than 30 minutes.

That one result should change how AI app-builder speed is measured.

If the metric stops at "first build complete," the six-minute number looks good.

If the metric is "usable live result," the experience failed.

This is why the FloNeo benchmark separated speed from publishing and reliability.

The final click is not a minor detail.

For a non-technical user, publishing is where the product either fulfils the promise or hands the project back to them.

A build that cannot complete the last mile is not a completed build.

---

Failure 3: generic content can make an unfinished app look finished

Lovable performed strongly overall.

But with a very short prompt, the output contained fairly generic placeholder content.

This is not unique to Lovable; placeholder generation was common across the category.

It is also easy to underestimate.

A page with a hero section, projects, buttons, contact form and realistic text feels complete.

But placeholder completion can hide functional emptiness.

The screen may contain:

• links that go nowhere;
• forms with no real submission path;
• buttons without business logic;
• data that is visually simulated;
• reports that are only presentation;
• states that were never tested.

Our internal review captured this as:

Beauty does not equal readiness.

The more polished the placeholder, the more important it becomes to show what is real.

---

Failure 4: the tool can understand the problem and still be unable to finish

Kimi's tool-limit issue is different from a model-quality issue.

The agent apparently knew what needed repair.

The execution budget stopped it.

That means application quality can be constrained by:

• tool-call limits;
• credit limits;
• plan limits;
• model routing;
• context limits;
• repair loops.

This matters because users do not buy "correct diagnosis."

They buy completion.

A system that says, in effect, "I know what is wrong, but I cannot take the next action" has reached a product boundary.

That boundary should be visible before the user depends on the result.

---

Failure 5: cost pressure can arrive before the product is ready

Emergent gave us the most comfortable guided experience in the benchmark.

It also made credit burn and upgrade pressure obvious.

That combination is instructive.

A product can be genuinely pleasant to use and still create cost anxiety.

The user starts with a creative task.

Then the mental model changes:

• How many credits are left?
• Will this next correction be expensive?
• Is publishing included?
• If the tool has to repair itself, do I pay for that?
• Should I stop editing because I may need credits later?

This is why the handwritten FloNeo framework does not just say "cost."

It says:

• predictable cost;
• visibility of cost burning.

Those are different requirements.

A visible balance tells you what is left.

A predictable cost model tells you what is likely to happen before you click.

---

The market problems were consistent across different products

Our competitive review summarised six recurring problems.

1. Beauty is not readiness

Attractive UI can still contain placeholder logic, fake links or broken forms.

2. Publishing friction

The "last click" can become the longest part of the build.

3. Credit burn

Users may discover the real cost only after the project begins consuming credits quickly.

4. Tool limits

An agent can correctly diagnose an issue and still run out of actions before it repairs it.

5. Low transparency

It is not always obvious what is truly functional and what is visually simulated.

6. Generic output

Short prompts often produce polished but interchangeable placeholder applications.

Those six problems are what the portfolio test could actually show.

The deeper problem is what it could not show.

---

What happens after the simple test: reliability

The handwritten FloNeo evaluation notes define reliability with three questions:

1. What uptime guarantee or availability target exists?
2. How are dependency updates handled?
3. What failover and redundancy exist when something breaks?

Our portfolio benchmark did not test those at production scale.

That is exactly the point.

A five- or ten-minute demo rarely does.

A generated app can publish successfully today and still have no clear answer for:

• package updates next month;
• provider outages;
• database recovery;
• failed background jobs;
• regional failure;
• backup restoration;
• secrets rotation.

Kimi's GSAP failure was a tiny preview of dependency risk.

Replit's publishing failure was a tiny preview of operational risk.

Neither is proof of long-term reliability for any platform.

They are reminders that reliability cannot be inferred from a screenshot.

---

What happens after the simple test: accuracy

The notes separate accuracy into:

• logic precision;
• prompt precision;
• output accuracy;
• customer delight / expectation match.

That separation matters.

Prompt precision

Did the system understand what the user meant?

Base44 asked no clarification questions in the initial flow, which made the experience fast but gave the user less control before generation.

Emergent and Lovable both performed strongly on questions and planning.

That does not make one universally better.

It shows the trade-off.

The less the system asks, the more it has to assume.

Logic precision

A portfolio does not contain much business logic.

A CRM, approval workflow, onboarding app or finance dashboard does.

The question changes from:

"Does the page look right?"

to:

"Does the system enforce the rule exactly?"

A beautiful permission screen is meaningless if the backend returns the wrong data.

Output accuracy

The generated result needs to match what was approved - layout, behaviour, states and data flow.

Customer delight

The handwritten framework calls this a customer-delight score.

We would frame it more practically:

How closely does the finished result match what the user thought they were buying?

That can be measured across visual match, behaviour, usability and confidence.

A technically functional product can still feel wrong.

---

What happens after the simple test: performance

The notes split performance into two areas:

• development speed;
• heavy concurrent usage.

The benchmark only measured the first one, and even there it exposed a flaw in common reporting.

Base44 built in about two minutes.

Replit built in about six.

But Replit's publishing issue stretched the last mile beyond 30 minutes.

So even "development speed" needs a better definition.

A more honest measure is:

time from prompt to usable, published result.

Then there is runtime performance.

The portfolio test did not measure:

• concurrent users;
• large datasets;
• background workflows;
• slow external APIs;
• burst traffic;
• database contention.

Those become visible only after the demo.

Again: the absence of failure in a tiny test is not proof of production performance.

---

What happens after the simple test: cost model

The benchmark measured cost friction.

The deeper framework asks for predictable cost.

Those are not the same.

In the matrix:

• Emergent scored weak on cost friction in this test;
• Lovable, Base44, Kimi and Replit were rated medium.

But a short benchmark cannot tell you what a larger build will cost across days or weeks.

The stronger product question is:

Before the action

• What will consume tokens or credits?
• What is the likely range?
• Is this a direct edit or an AI task?

During the action

• Is the system rewriting the whole project or one component?
• Is the cost increasing because the project context is larger?

After the action

• What actually consumed credits?
• What changed?
• Did the change succeed?
• Can the user roll it back without paying to recreate the old version?

That is the difference between a credit counter and cost control.

---

Readiness needs its own status

This may be the biggest product lesson from the benchmark.

AI builders are very good at showing visual completion.

Users need a separate signal for functional completion.

A simple readiness model might look like this:

<!-- pagebreak -->

A green preview is only one row.

---

This is why FloNeo should not compete on generation alone

The market already has fast generation.

The benchmark proved that.

The gap is a complete controlled journey.

The earlier FloNeo architecture article, How FloNeo's 4-Layer Architecture Makes AI Prototyping Ultra-Affordable, focused on reducing unnecessary AI work through compression, modular structure, model routing and incremental patching.

The competitive review adds another requirement:

Reducing token waste is not enough if the result is unclear, uneditable, unreliable or impossible to publish.

That leads directly to Part 3.

The next AI app builder does not need more prompts.

It needs better control.

---

References and Source Notes

• FloNeo internal competitive review, August 2026. Same-prompt benchmark across Emergent, Lovable, Base44, Kimi Websites and Replit Agent. Specific examples used here - Kimi's blank preview and tool-limit repair, Replit's failed publish after three attempts and 30+ minutes, Emergent's credit pressure, Lovable's generic placeholders - come directly from that test.
• FloNeo internal evaluation notes, 8 August 2026. Reliability: uptime guarantees, dependency updates, failover and redundancy. Accuracy: prompt/logic/output precision and customer-delight score. Performance: development speed and heavy concurrent usage. Cost model: predictable cost and visibility of cost burning.
• FloNeo. How FloNeo's 4-Layer Architecture Makes AI Prototyping Ultra-Affordable.