What a 20-day MVP actually is

This is MVP development in Saudi Arabia as Fluids sells it on the homepage: idea to launch-ready, fixed scope, real users, grows into the full product. Twenty days is the studio’s own committed offer. It is not a published client result. No case study on this site says we built that product in that time.

Eric Ries wrote that an MVP is the version that collects the most learning with the least effort. Fine. What we sell is a launch-ready first cut of the real product — not a video, not a landing page, not a disposable demo for a Thursday pitch.

The number is an offer

The 20-day MVP is a calendar commitment after Frame, against a written scope. It is not a trophy on a case study. It is not a guarantee that every idea fits. It is not a review-time promise from Apple or Google.

Honest shops often quote eight to sixteen weeks because they are quoting a standard product. Forcoda published that range in 2026. Fluids quotes this offer because Frame is allowed to refuse the standard product. After this heading, the number is the offer. Not a refrain.

What is in the offer

• One job, one primary user, written success criteria.
• A fixed quote before build.
• A Flutter consumer app, or a React web surface — not both as a default, unless Frame says the product is web-only.
• The operator half if the product cannot run without it: a small React admin on the same Supabase project.
• Auth, the core flow, the records that flow needs.
• Weekly builds the client can open — TestFlight, a Play internal track, or a URL.
• Launch-ready: in stores or on a production URL, under their accounts.
• Handover docs and credentials that belong to them.
• A codebase that is the start of the full product.

What a fixed-scope MVP is not

• The full product. That is card 03 on the homepage.
• Two native teams, or Swift plus Flutter “to be safe.”
• iOS, Android, web, admin, payments, a marketplace, and notifications as a default basket.
• Live money movement, ZATCA, government rails, or a partner API with no sandbox on day one.
• A custom design system as a project of its own.
• Charts, a CRM, a second database for the dashboard.
• A throwaway prototype, a no-code experiment, a slide deck.
• Holding the repo, the Apple account, or the Supabase project.
• A promised App Store decision in a number of hours.

If they need the out-list, they need the full product — or they need a no.

Why one stack can be launch-ready and keepable

Flutter is the default when both stores matter. React is the admin. Both sit on one Supabase project. One schema, two clients, no sync job. That is the mechanical reason the first cut can be launch-ready and still be the same codebase six months later.

The React admin is the other half of a keepable first product. Operators do not live inside the consumer app. If the product cannot run without them, the small admin is in the offer. Charts are not.

Swift stays the exception when the product belongs on Apple. That path may fail this offer. That is a Frame conversation, not a brochure asterisk.

Frame is the offer, not a kickoff call

Frame is published on the homepage. Scope, users, and success criteria in writing. A fixed quote before work begins. An honest go or no-go before they spend.

We say no when the first release is really three products. When the value is an integration nobody has approved. When the product should be native Swift and the Apple surface is the product. When they want a disposable demo for a Thursday pitch. When they will not name the one job.

Build and ship, without a fake calendar

We will not write what happens on day three or day fourteen. The published unit is the week. Build arrives in weekly increments they can open. They review the running product, not a status report.

Ship is launch, handover documentation, and credentials that are already theirs — developer accounts, the Supabase project, the domains. Nothing is held hostage. The inventory is its own note. Launch-ready means real users can do the one job. It does not mean every store review is pre-approved. Reviews are Apple’s and Google’s. We do not promise them.

It is supposed to grow

The homepage line is the point. The first build is the first cut of the full product. Same Flutter app, same React admin, same Supabase. Next work is more of the product — a second role, a harder payment, a second organization — not a new vendor and a new repo.

The shape is already on the site. A merchant who publishes an offer: T-CODE. A clinic that confirms a slot: Naqrah.app. This is the kind of product. This is not a timed claim. None of those pages say we built them on this offer.

If the idea is one job and they want it in users’ hands, this is the offer. If it is not, they will hear that first. Write to us with the one job. Not with a basket.