The Next Wave of Mobile Apps is The Instant Prototype

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?