The latest articles on DEV Community by Kayra (@opening-butterfly73). https://dev.to/opening-butterfly73 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4133051%2F5bba5aed-dc54-4404-a3c1-98ed9a15504a.png https://dev.to/opening-butterfly73 en Kayra Sat, 19 Sep 2026 15:03:15 +0000 https://dev.to/opening-butterfly73/why-i-built-a-local-first-visual-builder-instead-of-another-cloud-saas-162a https://dev.to/opening-butterfly73/why-i-built-a-local-first-visual-builder-instead-of-another-cloud-saas-162a <p>Most modern visual builders and rapid prototyping platforms take the exact same path: they <strong>lock your application into a proprietary browser runtime</strong>, charge per-seat or per-usage cloud fees, and emit <strong>unmaintainable spaghetti code</strong> the moment you try to export it.</p> <p>The entire ecosystem shifted toward cloud-hosted builders to force vendor lock-in and justify heavy subscription tiers. But for developers who actually care about <strong>code ownership, git integration, and offline workflows</strong>, running an IDE inside a Chrome tab with a hidden backend runtime feels completely backwards.</p> <p>I've been building NotCodes to test an alternative architecture: a <strong>local-first desktop IDE</strong> that pairs visual layout editing directly with a local TypeScript AST parser.</p> <h3> <strong>The Core Architectural Choices</strong> </h3> <ul> <li><p><strong>Local AST manipulation instead of cloud compilers</strong><br><br> When you arrange components or connect endpoints, the changes are parsed and written <strong>deterministically to your local disk</strong>. There is no remote compilation server holding your code hostage.</p></li> <li><p><strong>Clean, standard output</strong><br><br> It outputs standard <strong>React, React Native, and Node.js</strong> codebases. The output is intended to be indistinguishable from code written by hand, with zero proprietary runtime wrappers or framework lock-in.</p></li> <li><p><strong>Zero server compute overhead</strong><br><br> Because all the parsing, building, and rendering happen on the client machine, <strong>infrastructure costs stay practically nonexistent</strong>. You own the files, run them locally, and deploy wherever you want.</p></li> </ul> <h3> <strong>Deterministic Layout vs Prompt-Driven Development</strong> </h3> <p>With the rise of prompt-to-UI tools, prototyping got faster, but <strong>granular layout control</strong> and <strong>deterministic state wiring</strong> still fall apart when apps grow beyond single-view mockups. You end up spending more time prompting around edge cases than actually building.</p> <p>Having a spatial, visual canvas mapped directly to an AST provides precise control <strong>without begging an LLM</strong> to adjust margins or connect a database schema properly.</p> <p><strong>I'm curious how other engineers view this:</strong></p> <ul> <li>Does the stigma around "low-code" keep you away from visual tools entirely, even if they output clean TSX on your local machine?</li> <li>What are the biggest edge cases you've hit when trying to integrate visual scaffolding into standard git/Node workflows?</li> </ul> webdev programming architecture node