DEV Community

Kayra
Kayra

Posted on

Why I built a local-first visual builder instead of another cloud SaaS

Most modern visual builders and rapid prototyping platforms take the exact same path: they lock your application into a proprietary browser runtime, charge per-seat or per-usage cloud fees, and emit unmaintainable spaghetti code the moment you try to export it.

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 code ownership, git integration, and offline workflows, running an IDE inside a Chrome tab with a hidden backend runtime feels completely backwards.

I've been building NotCodes to test an alternative architecture: a local-first desktop IDE that pairs visual layout editing directly with a local TypeScript AST parser.


The Core Architectural Choices

  • Local AST manipulation instead of cloud compilers

    When you arrange components or connect endpoints, the changes are parsed and written deterministically to your local disk. There is no remote compilation server holding your code hostage.

  • Clean, standard output

    It outputs standard React, React Native, and Node.js codebases. The output is intended to be indistinguishable from code written by hand, with zero proprietary runtime wrappers or framework lock-in.

  • Zero server compute overhead

    Because all the parsing, building, and rendering happen on the client machine, infrastructure costs stay practically nonexistent. You own the files, run them locally, and deploy wherever you want.


Deterministic Layout vs Prompt-Driven Development

With the rise of prompt-to-UI tools, prototyping got faster, but granular layout control and deterministic state wiring still fall apart when apps grow beyond single-view mockups. You end up spending more time prompting around edge cases than actually building.

Having a spatial, visual canvas mapped directly to an AST provides precise control without begging an LLM to adjust margins or connect a database schema properly.


I'm curious how other engineers view this:

  • Does the stigma around "low-code" keep you away from visual tools entirely, even if they output clean TSX on your local machine?
  • What are the biggest edge cases you've hit when trying to integrate visual scaffolding into standard git/Node workflows?

Top comments (0)