Can Google Opal Build Your MVP? A Founder's Verdict

Google Opal can build a working AI mini-app in an afternoon, and it cannot build the MVP you raised money to ship. Both are true, and the gap between them is the entire decision.

Opal is the fastest way in years to turn a prompt into something that runs. That is exactly why it is easy to mistake for a shortcut around building your product. It is not one. Opal is a genuinely good tool for a specific job, and a founder who reaches for it at the wrong moment loses a quarter rebuilding. This is the honest read: what it ships, where it stops, and the rule for which side of that line your idea sits on.

The verdict

Use Opal to prototype an AI workflow, prove a concept, or build an internal productivity app. Do not use it to build the product your customers will pay for and your investors will diligence.

An MVP, here, is the smallest version of your product that proves one core workflow with real paying users, not a slideshow and not a demo. Opal is built to produce the demo. A fundable product needs a database you own, authentication you control, a way to charge money, and code you can take anywhere. Opal, by design, gives you none of those. That is not a knock on the tool. It is a category difference, and reading it correctly is worth more than any feature comparison.

What Opal actually is

Opal is an experimental no-code AI mini-app builder from Google Labs. You describe what you want in plain English, and Opal chains together prompts, AI model calls, and tools into a visual workflow you can edit by dragging nodes or by just typing the change you want. When an app is ready, you share it and other people run it with their own Google account. Google launched it on July 24, 2025 as a US-only public beta, and pitches it to "accelerate prototyping AI ideas and workflows, demonstrate a proof of concept with a functional app, build custom AI apps to boost your productivity at work." Read that sentence carefully: every use case Google names is a prototype, a proof, or a productivity helper. None of them is "your company's product."

In February 2026 Opal got more capable. A new "agent step" replaced manually picking a model: the agent works out the path to your goal on its own and reaches for the right tools, Web Search for research or Veo for video, without you wiring each one. It also gained Memory, so an app can remember a user's preferences across sessions, and dynamic routing, so an agent can follow different branches based on rules you describe. This is real progress, and it widens what a mini-app can do. It does not change the category. A smarter workflow is still a workflow.

What it genuinely ships well

For the right job, Opal is excellent, and dismissing it would be as wrong as overtrusting it. Three jobs where it earns its place:

• An AI workflow prototype. You have an idea, "take a product description and a target audience, generate ad copy, a video script, and a draft video." In Opal that is an afternoon: describe the steps, let it build the chain, remix a template that already does something close. You get a functional artifact to react to instead of a doc describing one.
• An internal productivity app. A repeatable task your team does by hand, summarizing weekly notes into an executive briefing, profiling a company from its website, turning a video into a quiz. These live comfortably inside Google's ecosystem, run for a handful of internal users, and never need to scale or take payment. Opal is a good home for them.
• A proof of concept for a pitch. You need to show an investor or a stakeholder that an AI idea works, not just that you can describe it. A shareable Opal app that actually runs is a stronger artifact than a mockup, and you built it in hours.

Where it stops being enough

The moment an Opal app has to behave like a product, five limits show up. None is a bug Google will patch away, because each follows from what Opal is.

Usage quotas you cannot see the edges of. Builders report burning through opaque daily and session limits fast, one described exhausting the quota "in 10 minutes," with little visibility or control. That is survivable for light prototyping and disqualifying for anything real users hit repeatedly.

Lock-in with no exit. Apps and their content stay inside Google's environment. There is no clean way to export your app, connect external APIs freely, or deploy it somewhere you control. When you outgrow Opal, you do not migrate; you rebuild from scratch, and the work you did does not come with you.

Performance that suits demos, not load. Practitioners describe slower, less consistent execution as tasks get heavier, fine for a demo, wrong for a product handling real traffic and expecting steady behavior.

All-or-nothing data access. Opal wants broad access to Gmail, Drive, and your other Google services, without granular controls like scoping it to one folder. That is a hard conversation to have with your own users when your product is the thing asking.

A complexity ceiling. Opal is built for simple mini-apps. Custom UI and interactions, heavy backend logic, real-time features, non-Google integrations, anything genuinely unique, sit above what it is meant to do. Even Google's own framing puts advanced functionality outside its lane.

The line between a demo and a product

Here is the cleanest way to see it. A fundable MVP owns four things that Opal, structurally, cannot hand you:

• A database you control. Your data model, your queries, your ability to move it. Opal keeps app state inside its environment with no export path, so you never actually own the data your product runs on.
• Real authentication and roles. "Sign in with a Google account to run my Opal" is not the same as accounts, permissions, password resets, and roles that you own and can shape to your product.
• A way to charge money. No payments, no billing, no subscription logic. A product that cannot take money is a demo with users.
• Portable code. The single most important asset a funded startup owns is a codebase it can take to any engineer or any host. Opal gives you a shareable app, not source you own.

This is also the difference a diligence review looks for. An investor or an acquirer does not ask whether your app works in a demo; they ask what you own. "It runs inside a Google Labs experiment we can't export" is not an answer that survives that room. We have seen founders arrive with a slick prototype and no owned product underneath it, and the rescue is always more expensive than scoping it right the first time. If you want the same test applied to any AI-built MVP, our launch test for AI-built products walks the checklist, and the same demo-to-production gap shows up in our review of Google AI Studio for MVPs.

The decision rule

You do not need to agonize over this. One pass through these questions settles it.

1. 1

   Prototype in Opal when the answer to all four is yes

   Is the goal to learn or to show, not to sell? Will it run for you or a small internal team? Does it live happily inside Google's tools? Is "we'd rebuild it later" an acceptable outcome? If yes across the board, Opal is the fastest path, use it today.

2. 2

   Scope a real build when any of these is true

   Strangers will sign up and depend on it. Money changes hands inside the product. You need custom UI, roles, real-time behavior, or non-Google integrations. You must own the code and data for scale, a raise, or an exit. Any one of these means Opal is the wrong destination, even if it is a fine place to prototype first.

3. 3

   Use Opal to de-risk the build, not replace it

   The strongest move is both. Prototype the AI workflow in Opal to prove the idea and sharpen the scope, then build the product properly with what you learned. The prototype makes the real build cheaper and more certain, which is exactly what a tight scope is for.

Is Google Opal free?

It is in an experimental public beta with no published paid pricing, so today it costs nothing to try. Expect opaque usage and rate limits rather than a clear paid tier, and check Google's official channels for the current state before you rely on it.

Is Opal available outside the US?

It launched as a US-only public beta. Availability may widen over time, but plan around US-only access for now.

Can I export an Opal app or host it myself?

No. Apps and their content stay inside Google's environment, with no clean export, external API freedom, or self-hosting. Moving off Opal means rebuilding, which is the core reason not to push it past prototyping.

Is Opal legit for real work?

Yes, for the work it is built for: AI mini-apps, internal productivity tools, and proof-of-concept demos. It is not built to be the product your customers pay for and your investors diligence, and treating it as one is where founders lose time.

Opal or a real build for my MVP?

Prototype in Opal if the goal is to learn or to pitch and a small internal audience is fine. Scope a real build the moment you need paying users, custom features, or code and data you own.

Book the Scoping Sprint

Prototype in Opal, then scope the real build with senior engineers. In one focused sprint we turn your idea into a fixed-scope plan for an MVP you own: the core workflow, real auth and payments, and code that's yours from day one.