Architecture and design software for AEC project delivery.

What an authoring platform is actually chosen for

This page is about the software: the authoring platforms architects and building designers actually model in. A platform is chosen for a mix of things that rarely get separated in a sales conversation — documentation output for construction issue, parametric modeling depth, freeform geometry capability, discipline-specific libraries, and how well a model behaves once it has to be shared with a structural or services team working in something else entirely.

None of that is really about which interface looks best. The platforms below solve overlapping problems in different proportions, and the honest starting point is knowing what your project actually needs from the model before comparing feature lists.

The main platforms and where each is strong

Revit, developed by Autodesk, is the dominant BIM authoring platform for architecture in most markets, and its strength is documentation: construction drawing sets, schedules and parametric families that update consistently across a large, complex model, plus close integration with structural and services tools built on the same platform. It rewards a well-built template and family library and can be unforgiving without one.

ArchiCAD, developed by Graphisoft, has one of the longest histories of BIM authoring in the industry and is known for an intuitive modeling interface and strong open-exchange credentials — Graphisoft has long positioned IFC support as a core feature rather than an add-on. It is widely used by design-led practices and is particularly strong in European markets.

ALLPLAN, also from the Nemetschek group, is the platform on this list that leans structural. Its centre of gravity is reinforcement modeling and construction detailing — bar shapes, laps, cover, bending schedules and the drawings that come out of them — sitting alongside architectural authoring, which makes it a common choice where one office carries a project from architecture through into structural documentation rather than handing it across. It is strongest in the German-speaking and wider European market, where DIN and Eurocode presentation conventions are native rather than configured, and it is lighter on hardware and gentler to learn than Revit on a project of moderate size. The trade-off is a narrower plugin ecosystem and less depth in general-purpose parametric modeling.

Vectorworks suits practices that need to move fluidly between 2D drafting and 3D modeling, with particular strength outside pure building work — landscape architecture and entertainment or stage design are areas where it is chosen ahead of the larger BIM platforms.

One mundane filter belongs ahead of all of that: what the office actually runs. Revit is Windows-only, so a macOS practice runs it in a virtual machine or on a separate Windows workstation. ArchiCAD and Vectorworks are native on both macOS and Windows, and ALLPLAN is effectively a Windows platform. That single fact settles the decision in a fair number of design studios before a feature has been compared.

Computational geometry and where it fits

Rhino, extended with the Grasshopper visual scripting plugin, is where computational and parametric geometry work happens — facade panelization, complex roof forms, generative design exploration, and anything where the geometry itself is the design problem rather than a constraint on it. It is rarely the tool a project documents construction from directly; the more common pattern links Rhino's geometry into a BIM authoring platform for documentation, keeping the generative logic upstream of the drawing set.

SketchUp occupies a different position again: fast, intuitive massing and concept modeling, widely used early in a design process or for client-facing presentation, and not built to carry the data density a construction-stage BIM model needs. Knowing which stage a tool belongs to avoids the common mistake of asking a concept model to do a documentation model's job.

Templates, families and why they decide quality

Two projects modeled in the same software can behave completely differently depending on the template underneath them. A well-structured template sets worksets, view standards, sheet numbering and family naming conventions before anyone models a wall, and a project that inherits a disciplined template stays coordinated as it grows. One that starts from a default template accumulates inconsistency that shows up first in schedules, then in clashes, then in a drawing set that has to be cleaned up before issue.

Family and component libraries matter just as much. A family built with the right parameters, the right level of detail for its stage, and consistent naming is reusable and coordinable; one built quickly for a single instance becomes a liability the moment it is copied. This is the part of platform choice that rarely makes a comparison table, and it is usually the bigger factor in how a model performs than which software produced it.

Worksharing, model size and what the hardware carries

A building model of any size is authored by several people at once, and every platform here solves that differently. Revit splits a project into a central model and local copies, with worksets deciding who owns what and a synchronize step reconciling the two; hosted in the cloud, the same mechanism works across offices without a shared file server. ArchiCAD's teamwork model reserves individual elements rather than whole worksets, which is finer-grained and tends to suit smaller teams working closely on the same areas. ALLPLAN partitions by drawing file, an older idea that still works well when the split follows the building rather than the org chart.

Whichever mechanism is in use, what actually determines whether a large model stays usable is how it is divided. A single file carrying every discipline, every level and every stage of detail will get slow regardless of the hardware under it. Splitting by building, by level or by discipline and linking the parts back together keeps each file to a size a workstation can hold, and keeps a synchronize from becoming a coffee break. Hardware still matters — a fast single-core clock, RAM well beyond the model's own footprint, a professional GPU and local rather than network storage for the working file — but a well-divided model on modest hardware outperforms a monolithic one on an expensive machine, consistently.

Schedules, quantities and measuring off the model

The reason a building model is worth authoring rather than drawing is that it can be counted. Door and window schedules, room data, wall areas, concrete volumes, reinforcement weights and a bill of quantities all come out of the same objects that produce the drawings, which means they agree with the drawings by construction rather than because somebody reconciled two documents at the end of a stage.

That only holds if the parameters underneath are disciplined. A quantity is exactly as trustworthy as the classification, the type naming and the parameter values that produced it, so a model whose walls are half generic and half properly typed will schedule confidently and wrongly. The rules that fix it are dull and effective: agree the classification system before modeling rather than after, model to the level of detail the measurement needs and no further, keep quantities coming out of the model rather than out of a spreadsheet maintained beside it, and hand-check a sample against the drawing before anyone prices from it. What each stage of a model can be relied on to measure is exactly what the LOD levels exist to pin down.

Standards, national annexes and drawing conventions

Geometry is code-neutral; authoring software is not. What varies by platform is how much of a national convention arrives configured rather than built by hand: sheet sizes and title blocks, dimension and annotation style, hatch and symbol conventions, how levels and grids are annotated, and the classification system the schedules key to. ALLPLAN arrives close to DIN and Eurocode presentation out of the box. Revit and ArchiCAD both ship regional content, and both still need a properly built local template before they produce a drawing set that reads correctly to a contractor working to British Standards or Australian Standards.

The part no template covers is the engineering. A national annex sets the parameters a design is checked against, and no authoring platform enforces it — the model draws whatever it is told to draw. So the standards a project answers to belong in the brief, in the template and in the review, and it is the review that catches the difference. The information-management side of the same question — how models are named, statused and exchanged between parties — is ISO 19650, and it is a separate thing from the design code the building is checked against.

Interoperability, IFC and handover

A model that only has to satisfy its own authoring software is a smaller achievement than one built to survive a federated, multi-discipline workflow. IFC export quality differs by platform and by how carefully the model was built for export — geometry that looks correct on screen can still carry broken or missing data once translated — so validating the IFC against the native model before issue is standard practice rather than an extra step.

In a federated ISO 19650 workflow, the architectural model is one container among several, named and issued to the same convention as the structural and services models it has to coordinate against. At handover, what the operator actually needs is asset data mapped to their own structure, not a model in its native format that only the original authoring software can open.

In practice the exchange runs on a small set of formats, and it is worth being precise about which does what. IFC carries the coordinated model with its object data, and it is what anything outside the authoring platform should be reading. DWG and DXF carry 2D drawings and the occasional piece of reference geometry, and carry no object data at all. The native file — RVT, PLN or the platform's own — is the only one that keeps parametric behavior, which is why it goes to whoever will keep authoring and is not leaned on as an exchange format for anyone else. BCF is the one that gets forgotten: it moves coordination issues between platforms without moving geometry, and it is how a clash review stays a tracked conversation rather than a folder of screenshots.

Delivering in your environment

We model in the platform your project already runs on — Revit, ArchiCAD, Vectorworks or another environment — using your template and your family or component library rather than importing ours. Repetitive modeling, family placement and documentation are the AI-driven part of the work; where the design calls for computational geometry, that is developed in the appropriate tool and brought into the coordinated model rather than left to sit outside it.

Every model is checked before a person reviews it — coordination against other disciplines, IFC validated against the native file, and naming checked against your convention — and a senior engineer signs off the package before issue, on this side of the work the same as on the structural side.