Bloom Lets You Build a Real App on Your Phone Before Your Coffee Gets Cold

The Macro: Mobile App Development Is Still Too Hard for Most People

Building a web app in 2026 is borderline trivial. Between Vercel, Supabase, and whichever AI coding assistant you prefer, a competent developer can go from idea to deployed product in an afternoon. A non-developer with Cursor or Replit can get surprisingly far. The barriers have dropped so fast that the phrase “weekend project” now means something real.

Mobile apps are still stuck in 2019. You need Xcode or Android Studio. You need to understand build configurations, provisioning profiles, platform-specific APIs, and the submission process for app stores that treat every upload like a customs inspection. React Native and Flutter brought cross-platform development to a reasonable state, but “reasonable” still means weeks of setup for someone who hasn’t done it before.

The no-code movement made a run at this. Adalo, FlutterFlow, and Thunkable all tried to make mobile app building accessible. They work for simple apps. They break down when you need real backend logic, user authentication, database operations, or anything that involves state management across sessions. The gap between “I built a prototype” and “I built something people can actually use” is where most no-code mobile tools lose you.

The vibe coding wave, where you describe what you want and AI writes the code, has mostly been a web phenomenon. Bolt, Lovable, and Replit’s agent are all doing interesting work, but their output is web apps. If you want a native mobile app, you’re still largely on your own.

That’s the gap Bloom is targeting. Not “no-code for mobile” in the Adalo sense. More like “vibe coding for mobile” with a backend included, native testing on your phone, and cross-platform output that actually runs.

The Micro: A Designer and a Developer From Zurich

Bloom is a two-person team based in Zurich. David Oort Alonso and Sirian Maathuis are the founders. Maathuis describes himself as a “designer that also builds things,” which is a good combination for a product that needs to make app development feel approachable. They’re part of YC’s Spring 2025 batch.

The core pitch is that you can go from idea to native mobile app on your phone without writing code. You describe what you want, Bloom generates it, and you can test it natively on your device in seconds. Not a web preview pretending to be mobile. Actually on your phone. That distinction matters because the whole point of building a mobile app is the mobile experience, and testing in a browser simulator is never the same.

The backend deployment piece is what separates this from a toy. Most AI app builders generate frontend code and leave you to figure out the server, database, and API layer yourself. Bloom deploys a backend for you automatically, which means the apps can actually do things. User accounts, data storage, API calls. Functional MVPs, as they put it, not just demos.

They’re hiring aggressively for their size, with listings for founding engineers, a mobile engineer, a head of production, and ops and growth roles. The engineering salaries are $150K to $250K with meaningful equity, which signals they’re funded well enough to hire seriously. The internship listing suggests they’re building a pipeline too.

The product has user authentication, a sign-in flow, and what appears to be a real account system, not just a landing page. Intercom is running for support. Sentry is running for error monitoring. These are signals that the product is live and being used by real people, not just being demoed at events.

What I find compelling is the phone-native testing loop. Every mobile developer knows that the gap between “it works in the simulator” and “it works on the device” is where bugs live. If Bloom can close that gap to seconds instead of minutes, the development velocity advantage is real. It also means non-technical founders can actually feel their app working in their hand while they’re still iterating on it, which changes the feedback loop completely.

The competitive landscape is getting crowded, though. Bolt and Lovable are both adding mobile capabilities. Replit is moving toward app deployment. If the vibe coding platforms extend into mobile before Bloom scales, the window for a mobile-first player narrows quickly.

The Verdict

I think Bloom is solving a real problem with a smart approach. Mobile app development has been left out of the accessibility wave that hit web development, and the phone-native testing loop is a genuinely differentiating feature. Building from Zurich with YC backing and hiring at Silicon Valley comp levels suggests the founders are thinking at the right scale.

The question is timing. The vibe coding market is moving fast, and the major platforms are all looking at mobile as the next frontier. Bloom’s advantage is being mobile-first while everyone else is mobile-adjacent. That’s a real advantage today. It might not be a real advantage in six months if Bolt or Lovable ships native mobile output that’s good enough.

The other question is the “functional MVP” claim. There’s a wide spectrum between “app that technically has a backend” and “app that’s production-ready.” If Bloom’s output is good enough to ship to an app store, that’s a different product than if it’s good enough to test an idea with friends. Both are valuable, but they attract different users and support different price points.

Thirty days, I want to see what people are building with it. The best signal for a development tool is the projects that emerge from it. If users are sharing real apps that do real things, the product is working. If they’re sharing screenshots of apps they couldn’t finish, it’s not. Sixty days, the question is retention. Do people come back after the first app, or is this a one-time novelty? Ninety days, I want to know whether they’ve decided to compete with Bolt or complement it. The mobile-first positioning is clear now, but the market is going to force a choice between platform and feature.