I’m tired of calling glued-together scripts “workflow automation”

Felix Schultz — Sat, 27 Dec 2025 10:37:30 +0000

I’ve built and maintained a lot of “automation” over the years.

Most of it followed the same pattern:

a bit of JavaScript here, a Python script there, some environment variables, maybe a cron job, maybe a webhook. Then you wire it together and hope nobody touches it too much.

And for a while, that works.

Until it doesn’t.

When scripting stops scaling

What usually gets called “workflow automation” today is often just scripting with better marketing.

You glue together JS and Python snippets. You pass JSON blobs between steps. You rely on runtime behavior to tell you whether things fit together or not.

At the beginning, this feels flexible. Later, it becomes fragile.

Refactoring is scary. Debugging means reading logs and guessing which step mutated the data. Someone changes a field name and the whole thing still runs — just incorrectly.

That’s not automation. That’s accumulated technical debt with a scheduler.

I wanted workflows that behave like software

Flow-Like started from a pretty simple idea:

if workflows are critical, they should behave like real software systems.

That means:

clear inputs and outputs
early validation instead of late failures
predictable execution
the ability to understand what a workflow does without reading five scripts

In Flow-Like, workflows are visual graphs, but they’re also typed. Connections aren’t just “data goes here”. They have meaning. If two steps don’t agree on what they exchange, you don’t get a broken run later — you get feedback immediately.

This alone removes a huge class of bugs that are considered “normal” in many automation setups.

Visual doesn’t mean dumbed down

A lot of tools treat visual workflows as a way to hide complexity. I don’t like that approach.

Flow-Like uses visuals to expose structure, not to pretend it isn’t there. You can see execution order, dependencies, and side effects. If a workflow is complicated, the graph shows that — and that’s a good thing.

As a developer, I want systems that are honest about their complexity.

Robust by default

Under the hood, Flow-Like is written in Rust. That wasn’t a trendy choice. It was a practical one.

Workflow engines deal with IO, concurrency, long-running tasks, and failures. Crashes or undefined behavior are not acceptable. Rust gives you a runtime that’s fast, predictable, and safe by default.

More importantly, it makes the system portable. The same workflow can run locally, inside a desktop app, or on a server without changing how it behaves.

Privacy and local-first execution

One thing that bothers me about many automation tools is how quickly they assume “send everything to the cloud”.

Flow-Like is local-first. You can build and execute workflows entirely on your own machine. No mandatory backend. No hidden SaaS dependency.

That’s not about being anti-cloud. It’s about having a choice.

Local execution means:

easier debugging
real data during development
fewer surprises around privacy and compliance

If you later want to run workflows on a server or in Kubernetes, that’s fine. But it shouldn’t be required.

AI workflows without duct tape

AI is now part of many automation pipelines. Too often that means embedding prompts in scripts and hoping nothing weird happens.

In Flow-Like, AI steps are just part of the workflow graph. They have typed inputs and outputs like everything else. You can see where data comes from, how it’s transformed, and what gets produced.

That makes AI workflows less magical — and much easier to trust.

Why I’m building this

If you’ve ever looked at an automation setup and thought “please don’t break”, you probably know exactly why this exists.

I don’t think automation should mean “a pile of scripts nobody wants to touch”. I want a workflow system that developers actually enjoy using. One that’s robust, predictable, and private by default. One where you can come back months later and still understand what’s going on.

That’s what I’m building with Flow-Like.

You can find the project on GitHub and it is still evolving. If the ideas resonate, feel free to follow along, poke at it, or tell me where it falls short. Thoughtful criticism is more valuable than quiet approval.

Website • Docs • GitHub

DEV Community: Felix Schultz