The Next Wave of Mobile Apps is The Instant Prototype

Editor’s Note: Sanket Sahu, co-founder of GeekyAnts and creator of gluestack, recently made waves with a deep dive on the Expo blog about building a development server entirely in the browser. It was a technical masterclass, but we wanted to dig into the why behind the code. We sat down with Sanket to talk about what his new build means for the everyday founder and how "browser-native" tools are actually changing the game for enterprise AI.

Conversation is edited for clarity and easy perusal.

Amrit Saluja (AS): We’re hearing a lot about "vibe-coding" lately, Sanket. Does this move toward browser-native architecture mean the local IDE is becoming optional, or is it a hybrid future?

Sanket Sahu(SS): Vibe-coding is on the rise because browser-based tools make building apps more accessible by reducing friction. The world of development is definitely moving toward a hybrid model.

AS: Let us talk about that friction. For those who have not read the Expo piece, what exactly did you build to solve it?

SS: In short, I rebuilt an entire development server inside the browser. In RapidNative, there’s no npm run dev, no CLI, and no external server. The code updates in the preview in under 100ms with your state fully preserved.

AS: What was wrong with the previous approach?

SS: The earlier version ran a sandbox in the cloud. It worked, but when you're building an AI tool that streams code in real-time, every millisecond of latency breaks the magic. That round-trip to the cloud was noticeable. I didn't want "fast"—I wanted instant.

AS: You compared your approach to a traditional dev server. How did you manage to move those heavy functions into a browser tab?

SS: A traditional server (like Metro) watches the file system, transpiles code, bundles modules, and serves them via HTTP. We found browser-native replacements for all of it. Service Workers replace the HTTP server. IndexedDB with a Virtual File System (VFS) replaces the physical file system. Babel Standalone handles transpilation, and Import Maps eliminate the need for bundling.

AS: That sounds very Vite-like. Was Vite the inspiration?

SS: Absolutely. Both share the same insight: modern browsers support ES modules, so why bundle during development? The difference is that Vite still needs Node.js and a CLI. RapidNative takes Vite’s philosophy to its logical extreme—everything happens in the browser.

AS: Why was the "dual VFS architecture" necessary for this to work?

SS: We use two file systems in tandem. The Source VFS stores your raw TypeScript/JSX code. When a file changes, it triggers a transformation, and the result goes into the Destination VFS as plain JavaScript. The Service Worker always serves from the Destination VFS. This separation keeps the pipeline clean and lightning-fast.

AS: For a founder or a CFO with zero tech skills, how does this 100ms preview actually help them raise a seed round?

SS: Faster iteration speed keeps you in the creative flow. That results in better MVPs and getting your first paid user faster. Getting your dream app running on your phone in less than 2 minutes is the "aha-moment" for our users.

AS: How is this different from something like Expo Snack for a founder?

SS: They are different tools. Snack is a browser-based REPL for developers to test snippets. RapidNative is a platform for building full apps. While Snack is optimized for running on actual devices, RapidNative is optimized for instant browser feedback during AI-assisted development. We give you that sub-100ms update that is critical when an AI is streaming code changes in real-time.

AS: Who should be using RapidNative today? Is it for startups or enterprises?

SS: Currently, it’s ideal for individuals and startups with an idea. But with features like customization, teams, and compliance in the works, we are making it compatible for agencies and enterprises as well.

AS: What’s left on the technical roadmap?

SS: Three big things: A TypeScript Language Server for proper autocomplete in the editor, browser-native Git operations via isomorphic-git, and adding native device support through Expo Go so you get the best of both worlds.

AS: Now to summarize, you’ve built NativeBase, gluestack, and now RapidNative. Looking back, has your goal shifted as AI entered the picture, or are you still solving the same core problems?