Most configurators ask you a list of questions. Wanderer asks the right questions, in the right order, and quietly rewrites itself whenever you change your mind.

To show what Wanderers engine (Reactive Graph Sequencing) actually feels like in practice, let's build something familiar: a pizza configurator. You can try the live demo right on this page.

The Setup

The configurator walks you through a series of choices. Dough. Sauce. Cheese. Crust. Toppings. Each answer feeds into the next, and at the end you get a clean summary of your pizza.

So far, nothing unusual. Any form builder can do this.

But here's where it gets interesting.

Conditional Follow-Ups

When you pick size, you can choose between small, medium, large, and party pizza. If you pick party pizza, a new question appears: do you want it pre sliced? If yes, another question follows: how many slices?

That slice count then shows up in the final summary, right next to your toppings.

In a traditional flow builder, you'd wire this up with conditional branches, store the slice count in a variable, and write a bit of glue code to make sure the summary reflects the choice. Doable, but tedious.

In Wanderer, you just draw it. The graph handles the rest.

The Magic: Going Back

Now imagine you've finished configuring your party pizza with 12 slices. You scroll back through your answers and decide that actually, you want a small pizza instead.

You click on the size question. You change party pizza to small.

Three things happen automatically:

1. The slice questions disappear from your configuration
2. The slice count vanishes from the summary
3. The flow continues cleanly from wherever the last valid question was

You didn't write any logic for this. You didn't define rollback rules. You didn't mark dependencies. The graph already knew that the slice questions only existed because of the party pizza choice. When that premise disappeared, everything downstream of it disappeared too.

This is retroactive adaptation, and it's the defining feature of RGS.

Why This Works

Every node in the graph holds state. Every edge carries a condition. When you change an answer, the graph doesn't just move forward to the next question. It re traverses itself from scratch, evaluates which paths are still valid given the new state, and collapses into a fresh sequence.

The questions that no longer belong simply aren't part of the new sequence. Their state is invalidated. Their entries in the summary vanish. The flow resumes at the first unanswered question in the new path.

You're not patching a flow. You're regenerating it.

Why You Care

If you've ever built a wizard, a configurator, or a chatbot with conditional logic, you know the pain. Forward flow is easy. Backward flow is where things break. Users change their minds, and suddenly your state is inconsistent, your summary is wrong, and you're writing invalidation logic by hand for every possible dependency.

RGS handles this by default. Backtracking, follow up questions, and data invalidation all happen on their own, because the graph itself encodes the dependencies.

That means:

• You can let users freely jump back and edit any earlier answer
• You don't need to track which fields depend on which other fields
• You don't need to manually clear stale data
• The summary always reflects the current valid state of the configuration

Try the Demo

The pizza configurator on this page is running on Wanderer right now. Change your mind as often as you like. Jump backwards. Pick party pizza, set your slice count, then switch to small and watch the slices quietly disappear. The graph is doing all of it for you.

You can learn more about the technology (Reactive Graph Sequencing) here: https://wanderer-flow.de/blog/reactive-graph-sequencing-the-technology-behind-wanderer