Founders I talk to that are doing hardware, broadly speaking, say it's a competitive advantage as it's not as crowded. Content like Aaed's will hopefully nudge more people into it.

The question is on whether these platforms are going to enforce their policies for plugins. For Claude Code in particular this behavior violates their plugin policy (1D) here explicitly: https://support.claude.com/en/articles/13145358-anthropic-so...

It's a really tough problem, but Anthropic is the company I'd bet on to approach this thoughtfully.

What it is: Dreamflow generates a Flutter app from a prompt, then lets you keep working in a real dev environment with a visual editor, AI agent, and full code (code is the source of truth).

Why we built it: 1) make small changes dead simple: tweak properties, move widgets, add components without editing code or prompting; and 2) give the agent precise context: select a widget to add it to the prompt (screenshot included automatically); the agent has access to read runner logs.

What’s different:

- Bi-directional editing: canvas ↔ code; standard Flutter. - Runs in the browser: hot reload, preview. - Agentic edits with diffs; widget-aware context + log access.

How to try: Prompt: “Fundraising CRM for founders: pipeline (Targeted -> Closed); investors (name/firm/check size/intro source); notes + next steps + due date; goal $X/$Y; tabs Pipeline/Investors/Tasks/Settings”

Then preview, rearrange visually, integrate a backend or keep it local, and export/publish.

Current gaps: Visual coverage isn’t complete; GitHub integration is in progress; importing existing Flutter projects isn’t supported yet.

We’d love your feedback. Where does the visual editor help or get in your way? Which integrations would you expect first?

Comments URL: https://news.ycombinator.com/item?id=45130588

Points: 12

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=35202722

Points: 2

# Comments: 0

Performance could certainly be improved (especially for Web), but it's gotten much better over the last year.

Expanded + Percentages for widths are possible already

We definitely want to support more DBs in the future, just a matter of time. Meanwhile, we see some users achieve that goal using API integrations and code export

Ofc you can't import code into FF from your main branch, at least at the moment. But it's still been working well for our users

- Custom Functions: https://www.youtube.com/watch?v=CbNtmue0ZZo

- Custom Widgets: https://community.flutterflow.io/c/whats-new-in-flutterflow/...

- Custom Actions: https://community.flutterflow.io/c/whats-new-in-flutterflow/...

The reason there are 3 different kinds of custom code is so that it can easily integrate with the visual builder ... for instance a "Custom Action" function will show up when you add an action on a Button Tap, or TextField submit. A "Custom Widget" can be dragged in and passed parameters, and a "Custom Function" can be used to set values. Would love any feedback

Being able to easily search and find where your network requests, custom function calls, conditional variables, etc are used is definitely something that has come up. We've started making progress by adding visual elements that help you identify them. For instance, you can see what element on the widget tree has a query (or action) on it based on an icon + color. We plan on adding toggles for overlays of different views, along with the ability to see where an API call is used (from the API configuration page), or where a specific collection is read (from the Firestore configuration page). It's definitely solvable, and we'll keep talking to users and iterating till we get there :)

Wish you the best of luck as well

Flutter is an open source framework for building cross platform applications. FlutterFlow combines a UI builder with pre-built templates and Firebase/API integrations, generates clean Flutter code, and allows you to deploy to app stores directly from your browser. This enables extremely fast iteration, from product idea concepts and designs to working Flutter apps. As an example of what’s possible, we built an internal app for playing trivia games by using the jservice.io API and Firebase all in under 2 hours:

Time lapse of building the app: https://youtu.be/Fm4jjpuKM1E

Link to live version of the app: https://app.flutterflow.io/run/ByqwG33rw80qyN39ooNq

Exported source code: https://github.com/FlutterFlow/ff-trivia/tree/flutterflow

Alex and I, along with a friend of ours from Google, quit our jobs in 2019 to work on a cross-platform mobile app that ultimately failed. It was a learning opportunity, and it also led us to feel the pain of the slow iteration process every time we wanted to roll out a new experience. We were able to experiment with various landing pages within hours, but building new screens and app experiences took weeks or even months. For over a year now, we’ve been tirelessly working on fixing this problem.

I first fell in love with coding by pure luck as a kid in Ethiopia. My father, who at the time owned an internet cafe, decided to start taking night classes in CS in the late 90s. Ultimately he didn’t use his degree professionally, but I ended up with learning materials and a compiler, Turbo C++ 3.0. As I grew older, eventually ending up as an engineer at Google, I started to appreciate that as engineers we were often tasked with solving problems even when the solution didn’t necessarily involve writing code. Alex comes from a physics background, doing his undergrad at Stanford, and transitioned to study CS and AI there as well. In 2016 he joined the team I was on, a small ML group within Google Maps. He’ll often admit he had underestimated the amount of skill involved in building beautiful, fast and functional apps. And he certainly didn’t expect to love building with Flutter as much as he does, having been entrenched in ML for most of his career. Yet here we are.

There has recently been a healthy amount of skepticism towards no-code tools, mainly due to concerns of extensibility and scalability. This is definitely the case for some apps - a good example is a tool such as FlutterFlow itself. It would be very difficult to build all of FlutterFlow recursively. We do use it internally for many of our pages, but using a visual builder to implement our code generator seems far fetched. This doesn’t imply however that there isn’t a middle ground that enables fast iteration in a visual builder, coupled with the ability to write code that seamlessly integrates with the overall experience. We’re not quite there yet, but we believe this is the right direction.

Finally, we believe Flutter is going to be the catalyst that drives this movement. It’s composability, the fact that it’s super cross-platform (Android/iOS/Web/Desktop/Embedded), and the vibrant and passionate community it fosters give it a unique advantage. Whether we do it or someone else, the application builder of the future will be built on Flutter. Huge thanks to our users, the Flutter team and the Flutter community.

We’d love for you to give it a try and share your thoughts. What do you think the future of application development is going to be?

p.s. we were on HN when we announced our launch back in May: https://news.ycombinator.com/item?id=27238381 We’ve made a lot of progress since then, enabling app store deployment, payments, ability to add custom code and much more: https://community.flutterflow.io/c/whats-new-in-flutterflow

Comments URL: https://news.ycombinator.com/item?id=29628716

Points: 190

# Comments: 62