Digital design models
Currently digital design takes place almost entirely inside large, monolithic applications— Revit, Archicad — that do everything. There are clear reasons:
- Learning any application is hard because it is large, so it best to keep staff on one package where they are knowledgeable and work efficiently.
- Each application stores data in a proprietary format and translating from one to another is hard, and also destroys information.
- Pricing models encourage scale — both in magnitude of licenses purchased, and also how long they are purchased for. (Adobe’s monthly billing system hasn’t yet penetrated this market, as far as I am aware.)
- Whilst the monolithic apps are always limited, creating your own application is very hard, so you have to buy at least one and given reason 1 and 2, that app should do as close to everything as possible.
The monolithic applications are extremely lucrative products and anyone who seeks to take market share off them will have to negate at least one of the 4 reasons firms decide to invest in them.
Rhino/Grasshopper was wildly successful because it negated reason 4. Grasshopper lowered the barrier to creating a single feature. If you wanted a simple facade panelization that wasn’t offered in Revit or Archicad you could cheaply and easily create one in Grasshopper. Since an application is just a collection of features, any firm that created and saved Grasshopper scripts in an organized fashion (though almost no firms do this) would — cheaply and almost unnoticed — create their own applications. Since Rhino is so cheap, and Grasshopper is so free, reason 3 lost its potency. But Rhino doesn’t do architectural documentation well and so it has never managed to become the only application in an architectural office.
Flux.io, noticing that the Rhino/Grasshopper was so compelling for reason 4 and that the incumbents would never negate reason 2 themselves (as that would lower their attractiveness) decided to step into this void left by the market. Flux translates any format to any format effortlessly. But there are some problems with focusing on reason 2:
- A firm still need the original applications to create the data, and whilst Flux is cheap it remains parasitic on expensive applications.
- Flux is predicated on firms using at least 2 monolithic applications internally, or it becomes an interoffice collaboration platform. Interoffice collaboration is one of those things which belongs to no one except techs, so getting institutional buy in for a product that does only that — especially given a single collaboration requires 2 sales events — is difficult. It will become easier at the point that total market saturation is achieved, but how do you get there?
- Flux is cheap to replicate. Archicad created a plugin for Grasshopper that allows firms that use Archicad to use it with Rhino/Grasshopper as though it was one package. This almost fully destroys Flux’s offering for an Archicad firm.
Flux is likely moving toward negating reason 4 with its flow app, but given how far away from Grasshopper or even Dynamo they are this is unlikely to become a competitive edge.
I think that the most compelling value proposition and competitive advantage for Flux would be to negate reason 1. Since Flux is browser based it enables one to extract small pieces of functionality and expose small parts of a BIM in the browser using all the tools available in the browser. The BIM is seen as a db or a server interfacing with a series of small, specialized apps rather than a single ‘BIM file’ that interfaces with a single app. For example, an app may allow clients to change carpet and paint colors— in the BIM directly — without realizing that they are doing BIM and without having to learn very much at all. As the suite of apps that interface with a BIM grow the need for a monolithic application shrinks and so do the number of licences purchased.
This is where Flux will likely go if they want to grow their product. The Flux app store concept is the start of this process.
