I know you try to couch this for "simple" projects, but <i>if done correctly</i> I believe that something like this can be useable for complex applications as well.<p>From a super high level, we have "structure" and "components". Using anything computer generated for application structure is risky and a bad idea. BUT, for components, I believe there are certain contexts where a "react component" which is autogenerated, by makers.so for example, might work. While I acknowledge some components are foundational and need to be flexible, robust, interactive, configurable, and clean, there are some which don't. There are some components which level in "application space" which are one-offs, experimental, and somewhat rigid in their usage. For these types of components, as long as the computer generated html/css is encapsulated into the component, it <i>might</i> not matter what the implementation details are.<p>If you just need to set it and forget it, you can save time by using a "Makers.so figma group => react component" process. Later on, if you do need that component to be "productized", then upgrade it to handwritten html/css later.<p>Notes:<p>* I built a proof of concept single page application with this approach (Sketch + www.animaapp.com) and it looked promising. Most of the wrinkles in that workflow are being solved at the figma level with variants and "flexbox" support.<p>* Unless you use more advanced css approaches/sandboxing, you need to make sure the css boundary between your application and the autogenerated components aren't in conflict. This might mean that makers.so baseline css assumptions (reset, whitespace, etc) might drive the baseline css for your application. Which is a bit of the tail wagging the dog. Hence, the high level of experimentation with this approach.<p>* And yes, I have been around long enough to have "created applications using Microsoft FrontPage" and done a "Photoshop export to HTML" to be very disappointed with the results. :)