ABOUT FLOW
Built from practice,
not from a product brief.
Flow grew out of everyday architectural project work — solving repetitive tasks, improving consistency and making complex Revit workflows easier to manage.
WHERE IT STARTED
Flow wasn't originally intended to become a product.
It began with the same problems architectural teams encounter every day: repetitive tasks, inconsistent processes and Revit workflows that required more time and attention than they should.
The first tools were developed simply to make project work better — reducing manual steps, making standards easier to maintain and giving designers more reliable ways to complete recurring tasks.
Over time, those individual solutions began to grow into something more connected. Flow developed from that collection of practical tools into a broader approach to improving how architectural work gets done in Revit.
HOW IT EVOLVED
From visual scripts to native Revit tools.
Flow's development began with Dynamo — using visual scripting to automate repetitive Revit tasks and explore better ways of working. As those workflows became more ambitious, development moved into Python, initially using IronPython and later CPython 3.
That progression allowed increasingly capable tools to be developed, but it also exposed the limitations of building larger, more integrated workflows around scripting environments.
Flow eventually moved to native C#, allowing much deeper integration with Revit and providing the foundation for more robust interfaces, shared services and connected tools that behave as a cohesive application rather than a collection of individual scripts.
The technology has changed considerably along the way, but the purpose has remained the same: use automation to make everyday architectural project work simpler, more consistent and easier to manage.
BUILT IN PRACTICE
Developed alongside real project work.
Flow isn't developed in isolation from the workflows it is intended to improve. The tools are shaped through everyday architectural project work, where they can be tested against real models, real deadlines and the practical demands of delivering projects in Revit.
That connection to practice helps keep the focus on useful, practical improvements — reducing unnecessary steps, making recurring processes more consistent and helping designers spend less time managing the mechanics of their workflow.
Flow is intended to fit around and improve the way architectural teams already work — not replace it.
WHERE IT IS NOW
One toolkit.
Built around architectural practice.
Flow has grown into a connected suite of Revit tools supporting project setup, workspace, content, modelling, documentation and model review.
The scope has grown, but the underlying idea remains the same: identify the parts of everyday project work that can be made simpler, more reliable or easier to manage, and build practical tools around them.
Flow continues to develop in response to real project workflows. New tools and improvements are driven by the same question that started it: can this part of the process be made better?