I built FlowStep out of frustration from working in L2 support.
My colleagues and I actually want to solve problems, not just close tickets.
But logs and short feature descriptions are often not enough.
To understand a failure, we need to know what happens when a module is called and how execution reaches its end.
Developers usually don’t have the time, or the approval, to write detailed documentation, especially documentation that includes visual explanations.
When documentation exists, it’s often text-based and written in developer language.
Existing code-to-diagram tools tend to visualize complexity, not the actual execution flow support teams need to understand.
They work well for developers, but not for explaining the essential execution path to support teams.
I felt there had to be a way for developers to take their code and, with some intelligent help in between, generate a flow that speaks the language of support instead of code.
That stubborn idea eventually turned into FlowStep.
KalaINC•2h ago
My colleagues and I actually want to solve problems, not just close tickets. But logs and short feature descriptions are often not enough. To understand a failure, we need to know what happens when a module is called and how execution reaches its end.
Developers usually don’t have the time, or the approval, to write detailed documentation, especially documentation that includes visual explanations. When documentation exists, it’s often text-based and written in developer language.
Existing code-to-diagram tools tend to visualize complexity, not the actual execution flow support teams need to understand. They work well for developers, but not for explaining the essential execution path to support teams.
I felt there had to be a way for developers to take their code and, with some intelligent help in between, generate a flow that speaks the language of support instead of code.
That stubborn idea eventually turned into FlowStep.