A note before we begin: we’re going to try and stay out of trouble by using the term “incumbent tool” throughout this post instead of the name of the actual tool…but all AEC people will know which tool we’re referring to. Read on, you’ll see what we mean.

‍

“Bringing the magic back to building design” is a phrase I’ve used to talk about the impact Arcol will have on our industry (in our manifesto and on the TRXL podcast with Evan Troxel).

But what does that even mean? I’d like to use this post to share what some key parts of what our roadmap looks like in the short, medium, and long term and how we’re going to “bring the magic back to building design”.

We know it’s unusual in the AEC industry to reveal your product roadmap, but we want to be as transparent as possible in order to get your feedback. We believe that the next large company in our space should be transparent, empathetic, and focused on building beautiful tools. We talk about some of this over on our values page. We’re putting our money where our mouth is by giving you a little sneak behind the curtain.

Today, 4 professional bodies wrote a second open letter to the incumbent — we want to use this piece to address some of those concerns by being transparent and empathetic.

What we’re building is ambitious and will take time to get right. We’ve already re-prioritized our roadmap based on feedback from the AEC community, and we’re focused on creating our tool from the unanswered feedback that has accumulated over the years. Execution is key, and we plan to deliver a high quality product.

We know you’re frustrated with the current lack of advancement in the incumbent tool: 20+ year old technology that has no incentive to change due to their monopoly. We’re here to change the pattern of incremental improvements released once a year. We want to make tools that AEC actually loves to use and we want you to love working with us. AEC deserves better.

Short term

This is what we’re currently working on for the open beta that will come out later next year.

Boards

When I started Arcol my first step was to talk to as many AEC folks as possible. There was one piece of feedback that was consistent from these calls — documentation mattered. While we believe that the future deliverable will be a model rather than a drawing set, the current reality is that sheets are the final output for most projects.

Documentation is where the incumbent excels, and why it has gained such significant market share. However, we think that documentation can be so much more than just slogging through the production of construction drawings. Designers create documents at all phase of a project, ranging from moodboards to punchout lists and drawing sets. Our goal is create a tool that is flexible, collaborative, and creative enough to accommodate all these forms of documentation.

We’re changing the documentation game with a feature called Boards. Boards are infinite canvases on which you can place views, sheets, text, links, images, or shapes. Imagine Miro or Figma but with scale, dimensions, and 3d views. We want documentation to start in Arcol on day one of a project — collaborating on mood boards, sketching early concepts, creating project todo lists…whatever you like.

Views and sheets will still work the way that you are used to seeing them, so as the project progresses you’ll be able to annotate and create drawing sets in Arcol as well. At the end of a project, you’ll have a single repository of project data that includes all your work from concept through to contract administration (this is a big hairy problem with lots of steps remaining to solve, but if you don’t think big what’s the point right?).

We mentioned Boards in the “Infinite Canvas” section of our manifesto. This feature has progressed substantially since we first wrote about it, and it’s been fun to use both internally and with our closed alpha users. We know you’re going to love it.

Complex modelling V1

Another consistent piece of feedback we’ve received is that the incumbent tool isn’t great for conceptual work. The general sentiment is that it’s great when the design has been settled…not so much if you’re exploring options. For this reason, the industry has been gravitating towards Rhino. While Rhino doesn’t have the documentation capabilities of the incumbent, it does support modelling complex shapes with its NURBS kernel. People have told us that the incumbent feels very constrained, like you’re constantly battling a rule set. On the other hand, Rhino feels limitless and fluid, allowing your creativity to run and skip through tulip fields of complex geometry.

We started with the most basic component types in Arcol — walls, windows, and doors. Based on the feedback above we’ll be shifting our focus next to complex modelling and allowing you to sweep, loft, push/pull, and perform boolean operations on your model. Our thought is that components like roofs, floors, stairs, etc are necessary (and will come later), but combining the power of complex modelling with creative collaboration in Boards will make a very compelling conceptual tool in the short term. Let me be clear: our longterm goal is NOT to just be a conceptual tool, but to take a big bite out of the documentation space as well. However, this seems to be the most logical step towards providing our users value as early as possible.

Roofs, stairs, and other stuff (MEP)

As I mentioned above, we started building Arcol with walls, windows, and doors. Based on user feedback, we’ve pivoted our roadmap towards massing and complex geometry, but we fully intend to come back and finish building the remaining default elements like roofs, ceilings, floors, and stairs. As the tool expands we also plan to support MEP modelling — the full power of real-time collaboration will be realized when the architectural team AND all the consultants are modelling alongside each other.

Performance and Interoperability

Not a lot has been done in terms of heavy graphics in a browser, so people are reasonably skeptical that a web-first tool will perform well. We know that Arcol’s performance needs to be not just as good, but significantly better than the legacy tools we are competing against. Our job is to show you that web-first tools can be highly performant.

The incumbent tool doesn’t have great performance. Given the huge file sizes that accumulate it’s quite impressive that the incumbent tool runs the way it does, but this tool is built on 20-year-old technology…when there was no such thing as multi-core processors. This is a widespread complaint about the tool, and having Arcol be highly performant will be a key point of difference.

As Greg Schleusner points out here, we should have an equivalent version of USD in AEC. This allows the owner of that data to be platform independent, by using a series of API to talk to the data and not the specific toolset. We don’t intend to boil the ocean, and we’re big fans of the amazing tools that already exist for things like rendering and analysis. We’re committed to facilitating the transfer of your data into and out of Arcol. We’re starting with IFC import/export, and will add support for additional file types throughout our development.

In the short term at Arcol, we want to let designers get back to doing their job, designing. The tool of your trade should never hold you back or lock you in, like the current one does.

Medium Term

This is what would allow us to move from open beta into a V1 of Arcol.

Plugins

Plugins are an important part of any enterprise tool because of the customization they allow. There are many niche use cases that aren’t covered by the base tool, and plug-ins let you bolt on parts to make the tool more powerful and tailored to your needs.

We’re approaching this feature holistically: well-written API documentation, consideration of scripting within Arcol, creating easy-to-use sandbox tools (Figma is great at this), and developing a place to share and distribute plugins for others to use. We want plugins to be accessible to junior developers and hobbyists to further encourage creativity and customization.

Automate Documentation

Producing clean, dimensioned, beautiful drawings and details is an art in its own right, and we believe that this process should be able to be done with the push of a button. We mentioned above that the goal of Boards is to provide a creative space for documentation — automated documentation pushes this even further, taking the bored out of Boards and letting you spend more time designing. Some obvious examples of this are auto-dimensioning and auto-tagging, but it extends to more complex workflows as well like placing and aligning views on sheets (imagine creating a detail view and having the view be automatically placed and aligned on an existing sheet that has other details from the origin sheet).

Inventory and price of construction materials

The current design process has architects designing a building and then either working with a cost consultant or waiting till tender to learn the cost and availability of the materials for the build. From there the project goes into value engineering, which is no fun for anybody. We believe that architects should have information about the general cost and availability of materials for their building while they design it. This will save time on the project and result in designs that are much closer to the original intent, giving the architect valuable information for ongoing discussions with the client as early as the conceptual design phase. One way we might do this is by working with manufacturers to have their product database (inventory, cost, specs) linked directly to content in Arcol.

In the medium term at Arcol, we want to let users back in the driving seat. You should be in control of your tool. The incumbent tool decision making process has been driven by increasing share price, we are driven by creating awesome products that users love to use.

Long term

What’s the far future potential for Arcol? Mike and I have “jam sessions” every Thursday morning, and we often talk about this very question. I often refer to Brian Chesky’s 11 star experience (definitely check out this link if you aren’t familiar with the concept). Here’s some 11 star experiences we think could be a big deal for Arcol users:

Construction copilot

I’ve used the term co-pilot here because of Github’s recent copilot product. As you write code, it interprets your intentions and provide useful autocompletions. You’re still writing the code, but it’s helping you code better and faster. We imagine a similar experience in Arcol. You know those senior architects who can look at a design detail and say “if you did it this way you’d save the builder X hours”? We want that expertise to live inside of Arcol, and AI is a great candidate to make this happen. Constructability, code compliance, localized site considerations for things like weather…an Arcol copilot would use data to help you design the most beautiful yet optimal building.

Metaverse

Wait, don’t go, it’s not what you think! While we definitely wouldn’t be against someone making a Fortnite level in Arcol, NFT’ing an Arcol model, or some other buzzy thing, our thoughts here are more along the lines of thousands of digital twins hosted in a single environment. Think Google Street View, but you’re able to walk inside the buildings because they’re all Arcol model links. Another interesting thought here is as-builts. While it’s not feasible for a municipality to host thousands of Revit models, there could easily be a repository of Arcol model links to allow architects to easily access as-built drawings.

Generative AI for BIM

Tools like Midjourney, DALL-E, and Stable Diffusion are showing the incredible advancements in generative AI. Meanwhile, generative design is gaining popularity in architecture as a way to explore design options within a set of manually defined constraints. We imagine a future that combines generative AI with generative design, creating a variety of building model options based on text prompts. Something along the lines of typing “organic geometry timber football arena futuristic” and having Arcol produce 10+ models of football arenas that are constructed of editable Arcol components.

In the long term at Arcol, we want to leverage data to supercharge the design process. Designing buildings shouldn’t be starting from scratch every time. Unlike the incumbent toolset, we don’t want to just talk about innovation — we intend to actually build it. The industry needs to be driven forward, and we want to be an example of what an “11 star experience” in AEC can look like.

Conclusion

We hope this stuff gets you fired up as much as we are. Like I mentioned at the beginning of the post, we’ve carefully considered our entry into the market and our decisions are based on chatting with people who we hope will end up using Arcol. Things may change as we get more feedback, but that’s a good thing because it means we’re listening to you! If you read anything in this post and thought “well that’s wrong” please let us know! You can contact myself at paul@arcol.io or Mike at mike@arcol.io.

If this all sounds very exciting to you and you’re not yet on the waitlist, you can sign up here. We’re currently in closed alpha with a small group of users, but we’ll be expanding the group regularly throughout the rest of the year. We could not be more excited about the future of the industry, and we’re looking forward to innovating with you!

Thank you Daniel for giving me amazing feedback, as always!