Back

What Figma understood about collaboration that AEC still hasn't learned

What Figma understood about collaboration that AEC still hasn't learned

Team Arcol

In 2012, a small startup decided to rebuild interface design software from scratch. Not port it. Not wrap it in a cloud layer. Rebuild it, natively, for the browser.

A decade later, Adobe tried to acquire that company for $20 billion.

Figma's trajectory is not just a business story. It is the clearest case study in what "collaboration" actually means in software, and why the distinction between cloud-hosted and cloud-native is worth billions of dollars. The AEC industry looked at the same moment in technology and made a different choice. That choice has consequences that compound every year.

What Figma actually did differently

Before Figma, the dominant design tool was a desktop application. Powerful, mature, well-loved. Designers worked in local files, exported assets, shared links to static screens, and gathered feedback through comment threads attached to screenshots of work-in-progress.

Figma did not take that workflow and add a sync button. It asked a more fundamental question: what if the design file itself lived in the browser? What if there was no local file at all?

The browser was not Figma's delivery mechanism. It was the architectural decision that made everything else possible. When the file lives in the browser, multiplayer is not a feature you add later. It is the natural state of the environment. Two designers in the same file, same moment, seeing each other's cursors. A product manager watching the design evolve in real time. A developer inspecting spacing values without waiting for a handoff document.

This was not incremental. The previous generation of tools could never achieve this, regardless of how many cloud integrations they bolted on, because the authoring happened locally. The file was a local artifact. Collaboration was something you did around the file, not inside it.

Figma made collaboration the medium, not the afterthought.

How AEC adopted "cloud"

The AEC industry watched the cloud transformation happen across software. And it responded, reasonably, by moving files to cloud storage.

You can now upload a Revit model to a cloud viewer. You can sync project folders to a shared drive. You can access drawings from a tablet on site. These are genuine improvements over the alternative, which was FTP servers, USB drives, and printed drawing sets.

But the authoring still happens locally. The architect opens a desktop application, works in a local file, saves it, syncs it, and waits. The structural engineer downloads that file, opens it in a different desktop application, runs their analysis, exports results, and uploads them. The cost estimator pulls quantities from yet another tool, builds a spreadsheet, and emails it.

The collaboration happens in meetings. Not in the tool.

This is the equivalent of what interface designers were doing before Figma: working in isolation, exporting artifacts, gathering feedback asynchronously, and hoping everyone was looking at the same version. Figma proved there was a fundamentally better way. AEC has not yet made the same leap.

What the AEC equivalent of Figma's insight looks like

The architectural decision is the same one Figma made: build the authoring environment natively for the browser, so the model is born collaborative.

Not files synced to a server. A shared environment where every participant works in the same live context. Where the architect adjusts a floor plate and the cost estimator sees the takeoff update in the same moment. Where the structural engineer's feasibility assessment is visible to the design team during the design session, not two weeks after it.

This means more than multiplayer cursors, though that matters. It means the data layer is shared too. Design geometry, cost data, structural logic, and zoning constraints all live in the same environment. Not in separate files maintained by separate teams using separate tools.

When Figma unified design and developer handoff into one environment, it eliminated an entire category of miscommunication. The AEC equivalent eliminates the version gaps, export cycles, and feedback delays that generate hundreds of RFIs on every major project.

The model is not a file that gets shared. It is a shared environment where work happens.

Why this matters now more than it did in 2015

Three forces are converging that make this architectural decision more consequential every year.

Design-build delivery is becoming the default. Dodge Data projects that design-build will account for 47% of U.S. construction spending by 2028. In design-build, the contractor is involved from the earliest design phases. The general contractor needs to see cost and constructability implications while the architect is still shaping the massing. This only works if both parties are in the same environment. When the delivery model demands early cross-discipline collaboration, a tool that only supports single-user authoring becomes a bottleneck.

More disciplines need to be in the model earlier. Integrated Project Delivery, lean construction, and sustainability requirements are all pushing the same direction: more people need input into the design at earlier stages. The old workflow of "architect designs, then hands off" is giving way to a model where structural, mechanical, cost, and construction teams contribute simultaneously. Every additional handoff in that process is a place where information degrades.

AI agents need cloud-native, data-rich environments. This is the accelerant. AI in AEC is moving from rendering assistance toward agents that can evaluate design options, run feasibility checks, and propose alternatives. These agents cannot operate on local desktop files. They need a cloud-native environment with structured, accessible data. A browser-native model with embedded cost, structural, and regulatory data is not just better for human collaboration. It is the foundation that makes agentic workflows possible. Agent-ready by design. Not retrofitted. Not bolted on.

The architectural decision Figma made in 2012 compounded over a decade. The same compounding is available to AEC firms that make the equivalent choice now.

The rebuild, not the port

Arcol made the same architectural decision Figma made. Browser-native authoring. No local files. The model lives in the cloud, and every participant, architect, structural engineer, cost estimator, contractor, works in the same live environment.

This is not a cloud viewer for desktop files. It is a ground-up rebuild of the design environment for the way projects actually need to work: collaboratively, across disciplines, in real time.

Connected Constructible Design is what becomes possible when you stop trying to make desktop tools collaborative and start building collaboration into the foundation. Cost data lives in the model. Structural feasibility is visible during design. Takeoffs update as geometry changes. The export-upload-review-feedback cycle that defines most AEC workflows disappears, because there is nothing to export. Everyone is already there.

The gap is widening

AEC does not need its tools ported to the cloud. It needs them rebuilt for it. That is the lesson Figma taught the software design industry a decade ago, and it is the lesson AEC is still in the process of learning.

The firms that understand the difference between cloud-hosted and cloud-native will be the ones that move fastest. Not because the technology is novel, but because the architectural decision, building for collaboration from the ground up, compounds in ways that incremental upgrades never will.

Every year that passes without making this shift is another year of export cycles, version mismatches, and coordination meetings that discover problems instead of preventing them. The compounding works in both directions.