I’m writing this from a design perspective, but these choices were intentional product decisions, not just visual ones. This is not a product overview. It’s a note about what I deliberately didn’t want Giselle to become.
Why start with “what it is not”
Right after a release, products are often understood through familiar frames. People try to place them into categories they already know. With Giselle, that happens almost immediately.
AI. Nodes. Automation.
Each of these words carries strong expectations: speed, efficiency, replacement. Together, they often suggest a tool that does the thinking for you.
Before explaining what Giselle does, I wanted to step back and remove some of those assumptions. Not to lower expectations, but to align them.
Starting with “what it is not” felt like the clearest way to do that.
Giselle is not a ChatGPT replacement
Giselle is not built around conversation. You don’t ask a question and receive a finished answer.
Tools like that are extremely useful, and I rely on them myself. But they tend to compress the process. You see the result, while the reasoning behind it stays implicit.
What mattered to us was keeping the structure visible. Where logic branches. Where decisions are made. What depends on what.
Giselle doesn’t aim to replace thinking. It keeps thinking on the surface so it can be examined, adjusted, and shared.
Giselle is not a no-code automation tool
You can build workflows without writing code. That part is true.
But many no-code tools optimize primarily for speed: getting something to run as quickly as possible.
In that process, important context often disappears.
Why this branch exists. Where a decision was made. What state the workflow is currently in.
In Giselle, those elements are not hidden behind configuration panels. Judgment, branching, and state are intentionally visible.
The goal wasn’t to make workflows faster to create. It was to make them understandable when you come back to them later—or when someone else needs to read them.
Giselle is not a magic app generator
You won’t click a button and get a finished app.
That was a conscious choice. Instant results can be impressive, but they often stay external. They work, but they don’t really feel like your own.
We wanted building to feel closer to design than to automation. Something you shape gradually, where the final structure reflects your intent.
That’s also why I spent so much time on the nodes themselves. They needed to stay readable as workflows grow, but calm enough not to overwhelm you.
I didn’t want workflows to become something you tolerate using just because they work. I wanted them to look like something you’d actually feel comfortable showing to someone else.
What I wanted instead
Giselle is for people who aren’t necessarily engineers. Designers, planners, and anyone who wants to understand how things connect—even if they don’t know every technical detail.
When the structure is visible, it becomes easier to work with. Easier to explain to others. Easier to extend when requirements change.
I’m building a media site alongside Giselle, and I often find myself thinking about how these workflows will evolve once external APIs and integrations are in place. This part will make more sense then. That flow will become more useful there.
Not everything is available yet. But the structure is designed so those pieces can fit naturally when they arrive.
Giselle is still evolving. And many of the things we’re building next are shaped by how we want to use it ourselves—day to day, in real projects.