I hold a lot of hope that visual workflow tools like this will help more people use software to solve their own problems. With an LM's assistance a lot more people can create code but they need some kind of organizational structure - a software architecture that "citizen developers" can easily conceptualize. Targeting Data analysts and scientists seems like a good idea.
I admire the openness of the platform you are creating. I appreciate your blog post's note that current SaaS, cloud native, multi-tenant systems don't permit the kind of flexibility you need. There is substantial depth here - you have been working on this a while. Secrets for api calls, a repository for sharing solutions. I'd try it if it ran on Linux.
My company is working on a similar project, and I have mad respect for your efforts and how far you have come.
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 support@oomol.com — always happy to connect.
Explain to me what tasks can be solved in the approach with flows? I used Node-Red in some automation processes. I managed to solve only simple problems that are easy to solve without AI. But how do you program in this style? What does the flow style look like, for example, a program to find the shortest solution of a sokoban or game 15?
PS. Usually, when I need to make all photos in the folder black and white, I use imagemagick.
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.
I admire the openness of the platform you are creating. I appreciate your blog post's note that current SaaS, cloud native, multi-tenant systems don't permit the kind of flexibility you need. There is substantial depth here - you have been working on this a while. Secrets for api calls, a repository for sharing solutions. I'd try it if it ran on Linux.
My company is working on a similar project, and I have mad respect for your efforts and how far you have come.
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 support@oomol.com — always happy to connect.
PS. Usually, when I need to make all photos in the folder black and white, I use imagemagick.
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.