I see one use case for Stackblitz: Collaborative editing
Imagine having a design sprint, making a mockup of a new application. Participants in the design sprint are a developer, a designer and a client who has data that needs to be in the application. This group has achieved the ideal workflow. The developer starts by going to Stackblitz and pressing the button to start a project, and then quickly fills in some code in the component that comes included in the new project, and the preview soon shows something that is starting to take the form of a real working application. The URL is shared so everyone can see the preview and interact with it at the same time.
The designer drops some pictures into the project, immediately available for the developer to use. The designer also starts editing the CSS file. Although the designer doesn't know much about CSS, with changes instantly previewed, the designer can see how everything turns out, and with collaborative editing, the designer and the developer can work together, editing the same code without waiting for the other person to finish their work and commit and push their changes. The designer feels empowered and even starts editing the JS code for the components. With no difficult technology like Git and an IDE to set up, the designer can easily see how the components are structured, and keep extending them, without knowing any programming, looking at the live preview to see how it turns out.
The client also starts editing the JS files, first starting with copy edits. Although the client would never learn anything about Git or programming, the client can edit texts in the JS files as easily as using Google Documents. The developer creates a JSON file for the data to show in the app, and imports it to use in the component. The client starts editing the JSON file, filling in real data. Although the client doesn't know anything about data structures, the linter instantly tells when data is entered in an invalid format, and the preview instantly shows what the app looks and feels like with the updated data, allowing a non-technical person to do something they could never do before.
The mock application is tested on users. The user's don't notice it's a mock. It works exactly like a real application, even though it was made as fast as making a paper prototype with other prototyping software. Instead of having to ask the users to pretend it's a real application, they can observe how users interact with a real application. Users can take any path they want though the application, not restricted to which slides are included in a paper prototype.
When the design sprint is over, the project is exported, and all of the code is used in the real application. No time is lost recreating things that have already been created in the prototype.
Unfortunately, there's just one thing that makes this scenario impossible: Stackblitz doesn't support collaborative editing. Everything else is already possible.
A project on Stackblitz can only be edited from one computer. When it's opened from another computer, it cannot be saved. It can only be forked. Forking splits the team, making it impossible for more than one person to collaborate on the project. It is technically possible to edit the same project on two computers by signing in with the same Github account an both computer, but you can't changes saved from the other computer without reloading everything, and saving from one computer overwrites the edits saved from the other computer.
The design sprint team is now forced to use traditional prototyping methods. The designer has to draw every screen of the application, manually filling in data on each screen. The designer has to duplicate all screens that can be displayed with different sets of data, manually editing each copy with different data. When the data is changed, the designer has to manually redraw all screens to fill in the new data. Since it would be impossible to draw screens for all possible paths that can be taken through the application, only a few chosen paths can be selected. When testing on users, if the user chooses another option than the one selected to be drawn, the interviewer has to tell the user that because this is not a real application, only one option is possible. The team doesn't learn much about how the user would interact with the real application. When the design sprint is over, the prototype will be thrown away, and all code must be written from scratch.