alexkern

Congrats on the launch! One of the positive byproducts of the open web platform is that products like this are possible. Much of what I share in other communication tools are links to things on the web, but sharing ends up forcing a context switch cost on both my end and the receiving end. Love that Muddy is exploring this problem space since I haven’t felt like other neue-browsers have gone far enough in making browsing itself a more collaborative and in-context experience.

Dynaboard founder here.

This is an interesting and deep topic, which we plan to share more about in an upcoming technical blog post. We are still experimenting with the best ways to constrain the LLM's output such that it always compiles as expected and "knows" when to use certain Dynaboard-oriented features like {{ bindings }}. At a high level:

- Code refactoring works through a recursive refinement loop of: fetching any relevant DB schema or existing component data -> initial generation prompt -> LLM output -> using tsc (or equiv) to detect errors -> feeding the errors back into the LLM recursively until a fixed point is reached -> format. In our experience it works really well for both simple and moderately complex prompts.

- UI components are first generated as an outline/scaffolding of components which map approximately 1:1 with HTML equivalents in an initial prompt, before being populated with their respective component properties in a subsequent prompt. There's a subset of properties that seem most useful to generate which we focused on for this initial release, but we are looking to expand that list over time.

Congratulations on the launch! I've been impressed by Momento's cache infrastructure during its private beta — the team's execution around developer experience makes integration painless so you can hit the ground running. I've seen first-hand how hard operationalizing instance-based caches think the serverless approach is a great fit here.

That's one way to describe it. :)

One note: we have some lightweight persistent data stores built-in for convenience, like a key/value store. However, you're always able to build on top of your own database / API and most of our early users do.

Thanks for the report. We're now shipping a polyfill for ResizeObserver on the landing page. Drop me a line at alex AT dynaboard DOT com if you're still running into trouble.

We will via Monaco. Using the desktop app, you’ll even be able to load your VS Code config into Dynaboard, or use your own $EDITOR.

Yes we do — everything in the editor interface and the apps you build with it have light-and-dark modes by default. We didn't have the bandwidth to make the landing page have a light-theme, but the product itself supports both modes already.

Thanks for the kind words!

We will not be pricing per developer or per user, but rather usage-based. We aim to be affordable for applications at scale, because we believe the cost of an internal app should not increase linearly with your headcount.

We’ve designed the system for a few deployment configurations, with independent single-tenant and multi-tenant support on the control plane and data plane. The goal is flexible on-prem deployments that balance customer convenience with regulatory / privacy requirements. At the moment though, we’re focused on our multi-tenant cloud environment and making that as top-notch as possible.

You’ll also be able to eject your app out of Dynaboard. The code is yours, we aim to have the best editor available and convenient serverless hosting so that’s why you’ll stick with us.

We're decidedly a "low-code" or even “yes-code” tool. You use the drag-and-drop interface to design the app, while all of the app's logic is written in an in-browser text editor environment. Everything is multiplayer from day 1. It's an IDE in the style of VB6 / MS Access / FileMaker Pro, but built with modern web technologies at the foundation.

We're building for early-stage technical teams and independent developers that want to reduce the iteration time on prototype -> production apps.