monica-guli

Really appreciate your thoughtful comment — it means a lot, especially coming from someone clearly thinking deeply about the space.

We share your hope: with the help of LMs, more people are able to write code, but they still need structure — something in between scripting and architecture. Our goal is to make that structure accessible, visual, and developer-friendly. Targeting data analysts and scientists is definitely something we're thinking about.

Glad you also picked up on our local-first direction — that was one of the core motivations behind OOMOL. We were frustrated by the limits of cloud-native SaaS: hard to customize, hard to self-host, and hard to mix real code into the flow. We wanted something that feels more like building actual software — but still composable.

At the moment, OOMOL runs on macOS and Windows. If you’re interested in Linux support or have ideas about your use case, we’d love to chat — we’re always learning from other builders in this space.

And likewise — mad respect for what you're working on. Would be great to swap ideas sometime.

Feel free to reach out at [email protected] — always happy to connect.

Great question — and I completely agree with your experience. Most flow-based tools like Node-RED or n8n are great for simple, event-driven tasks — but once you try to model anything non-trivial, like search algorithms or puzzle solving, they tend to fall short.

OOMOL takes a different approach.

Each node is a fully programmable unit — you write full Python or Node.js code, import pip/npm libraries, manage state, and do whatever logic you want. The flow just connects these pieces in a modular way.

So when it comes to problems like solving Sokoban or the 15 puzzle, it’s not about drawing a visual BFS graph — instead, you might structure it like:

- One node to define the state structure - One node to generate next states - One node to manage a queue (e.g. in memory or Redis) - One node to evaluate whether the goal is reached - And inside the node code: your BFS or A* logic

In this sense, OOMOL doesn’t force you to express logic visually — the *code is the logic*, and the *flow is how you organize and compose that logic across tasks*. Think of it as “wiring together programmable building blocks” rather than trying to drag-and-drop logic trees.

That said, you raise an important point: *for many simple tasks — like batch processing images using ImageMagick — scripts or shell commands are 100% the right tool.* OOMOL isn't trying to replace that.

Where OOMOL helps is when: - You have multiple steps to coordinate (e.g. conditionally processing based on metadata) - You need to integrate with APIs, databases, or cloud storage - You want to track, retry, or debug failed tasks - You’re composing reusable automation pipelines that grow in complexity over time

In short: > *Not every task needs a workflow engine — but once you start composing real logic across systems, code + flow gives you both power and structure.*

We’re still early and figuring out how to best serve developers like you — really appreciate you pushing on this distinction. Would love to hear what types of things you’ve tried to automate, and where tools like Node-RED started to fall short.