How Constructal Law explains our journey of software design

Diego Macrini
3 min readDec 11, 2020

We came up with the idea of creating our own website builder in the same way that most productivity software tools are created. We were unimpressed by the available options and thought we could do it better. That motivation was enough even though, in retrospect, it might have been a bit simplistic. But we knew that if there was no business case for the tool, at least we would end up with a good tool for ourselves, and we were not wrong about that.

The journey to making the website builder was far from a straight one. We knew the foundational concepts from the beginning, and they never changed: websites had to be made out of extensible components, and they had to be multilingual and responsive. What wasn’t clear and kept changing was the definition of the target user. Was the tool meant to help non-techies build websites? Was it for the average web developer or for advanced ones? Knowing that was hugely important because many decisions depended on who was the primary target user.

The answer to that question was very elusive for years, and in all honesty, we never fount it. It kind of found us. It ended up being that during the development of the tool, we committed to one answer at one point, then tested it with users of that type, and then changed out mind about who the tools was for. We did that many times in what looked like a circular path. At many point in time we were getting frustrated with the feeling of not making any kind of user sufficiently happy about the tool.

Eventually, the answer came once the product was ready. All those iterations between designing for some class of user or another made the software quite well rounded. That’s when we realized that the tool was good for teams, and in particular, that it was a good way of letting web developers of different levels work with content creators. What we built is more collaboration workflow than software tool; the tool is the medium that facilitates the workflow. That insight is important because when the tool is not used according the the intended workflow, it feels like it falls short in many regards. But when the tool us used to implement the “correct” steps in a collaborative process, then it feels as if everything flows effortlessly.

We recently learned that this experience might make more sense that we imagined. There is a concept called constructal law, which was proposed in 1995 by Adrian Bejan, a professor of mechanical engineering. The constructal law says: “For a finite-size flow system to persist in time (to live), it must evolve with freedom in such a way that it provides easier access to the imposed currents that flow through it.”

What the constructal law means is that

all shape and structure — all “design” in nature — evolves in a predictable direction: toward facilitating the movement of whatever flows through it. Designs evolve by configuring and reconfiguring themselves to move more stuff more easily. (see article)

Furthermore, Mr. Bejan says: “This new physics is not strictly about tree-shaped flows. It is about all the morphing architectures that are macroscopic, free, observable and measurable — for example, the round cross-sections we find in blood vessels, subterranean rivers and the tunnels dugs by worms; or the seemingly precise rhythms of breathing, running, wings flapping, flags waving and smoke plumes dancing. The science of form comes predictively from principle, not from analogy. Evolution is physics, not opinion.”

And that in a nutshell is what happened during our journey. We started with a set of opinions about the design of a new tool. Our opinions sometimes clashed with reality, but we couldn’t pinpoint why exactly. We kept going, painstakingly polishing rough edges, until we discovered that something was flowing well within the tool itself. That’s the moment when we realized that we had created a particularly effective workflow for building websites.

In conclusion, we thought that we were building a tool, but in fact, we were building a process, and the tool was just its channel. The tool is good in that it lets the process flow through it efficiently. What we did right was to put our efforts in creating an end-to-end path with as little frictions as possible. And in the case of website building, a complete path involves the collaboration between several types of users. Without that, the path is incomplete and there is no flow, so you end up with just a software tool.



Diego Macrini

CEO/CTO @Proximify. Specialized in research information systems.