Back

You don't test a building after you design it. You test it while you design it.

You don't test a building after you design it. You test it while you design it.

Team Arcol

In software engineering, testing used to happen at the end. A team would spend months writing code, then hand it to a QA department, who would spend weeks finding bugs, then send it back for fixes. The cycle was slow, expensive, and produced worse software.

Then the industry changed. Continuous integration. Test-driven development. Automated validation on every commit. Today, a software engineer writes a function and knows within seconds whether it breaks anything. Testing is not a phase at the end of the process. It is a continuous property of the development environment.

Architecture is still running the old playbook. Design first. Test later. Fix what breaks.

What "testing" means in architecture today

The word "testing" may feel unusual in a design context, but that is exactly what happens at every phase gate. Every structural review, every cost estimate, every code compliance check is a test. It asks the same fundamental question: does this design work?

The problem is not that these tests happen. It is when they happen and how they are structured.

Structural review happens after schematic design is largely complete. The engineer receives an export of the architect's model, imports it into analysis software, runs calculations, and delivers findings. This takes days to weeks. If the structure does not work, the architect has already invested significant time in a design predicated on assumptions that turned out to be wrong.

Cost estimates arrive on a similar timeline. The estimator takes a set of drawings or a model export, measures quantities manually or through takeoff software, applies unit costs, and produces a number. By the time that number reaches the design team, the massing has been set, the client has seen renderings, and the project has momentum in a direction that may not be affordable.

Code compliance gets checked when someone exports the model to a zoning analysis tool, or more commonly, when someone reads the code and checks dimensions against requirements manually. This happens at milestones, not continuously.

Every test is a separate step. A separate team. A separate tool. A separate timeline. And every gap between the design decision and the test result is a window where problems accumulate undetected.

The cost of late testing

By the time a structural issue surfaces in the current workflow, the design has momentum. Decisions have been made. Consultants have been briefed. The client has approved a direction. Changing course is expensive, and not just financially.

There is a political cost to redesign. The architect has to explain why the concept they presented does not work as shown. The client has to recalibrate expectations. The project schedule absorbs the delay. The relationships absorb the friction.

The data tells the story. A typical large commercial project generates more than 800 RFIs, according to Dodge Data. Each RFI is a question that was not answered when the design decision was being made. Many of them trace back to the same root cause: a test that happened too late.

The software industry quantified this decades ago. IBM's Systems Sciences Institute found that a defect caught in maintenance costs up to 100 times more to fix than one caught during design. The principle applies directly to buildings: a structural issue caught during massing costs a sketch revision. The same issue caught during construction documents costs weeks of redesign and cascading coordination changes.

What continuous testing looks like in design

The alternative is not faster testing. It is testing that never stops.

Every design move carries instant feedback. Move a wall, see the cost change. Adjust a floor plate, see the structural implication. Modify the unit mix, see the zoning compliance status update. Shift the building envelope, see the FAR recalculate.

This is not about running a full structural analysis on every mouse click. It is about providing real-time feasibility indicators that keep the designer within the bounds of what works, while they are still designing. The detailed engineering still happens. The final cost estimate still gets built. But the designer is no longer working blind between phase gates.

Think of it as the difference between a spell-checker that runs after you finish the document and one that underlines errors as you type. Both catch mistakes. One catches them when fixing is trivial. The other catches them when fixing requires reworking paragraphs.

Continuous testing in design means the concept never gets far from reality. The structural system is visible as geometry takes shape. The cost per square foot is visible as the program evolves. The zoning compliance is checked with every adjustment, not at a milestone. The feedback is immediate, embedded, and always on.

Why this requires a different kind of tool

You cannot bolt continuous testing onto a tool that was built for drawing.

Most modeling tools in architecture were designed to produce geometry. Lines, surfaces, solids. The output is a visual representation of a building, not a data-rich model that understands what it represents. A wall in most conceptual modeling tools is a surface. It has dimensions. It does not know its material, its cost, its structural role, or its relationship to a zoning envelope.

When the tool does not understand what the geometry means, testing requires exporting that geometry to a tool that does. The export is the bottleneck. It is what creates the gap between the design decision and the test result.

For testing to be continuous, the model itself has to carry the intelligence. The wall has to know it is a wall. The floor plate has to understand its span, its loading, its cost implications. The building envelope has to be aware of the zoning constraints it operates within. The authoring environment and the testing environment have to be the same environment.

This is what Arcol was built to be. A modeling environment where every element carries structural, financial, and regulatory data from the moment it is created. Where the model is not geometry waiting to be tested, but a constructible design that tests itself continuously.

Takeoffs update as geometry changes, because the geometry is connected to cost data. Structural feasibility indicators are visible during design, because the structural logic is embedded in the model. Zoning compliance is checked with every modification, because the regulatory parameters are part of the environment.

Connected Constructible Design means that the design and the test are not separate activities. They are the same activity. Every design decision is tested in the moment it is made.

The industry that builds $13 trillion worth of structures annually still tests like it is 1995

The global construction industry produces $13 trillion in output each year. The buildings, bridges, and infrastructure that define how people live and work. The decisions that shape these structures deserve better than a testing process that operates on a two-week delay.

Software engineering learned this lesson decades ago. The shift from waterfall testing to continuous integration did not make software engineers less creative. It made them more productive, more confident, and more capable of building complex systems without catastrophic surprises.

Architecture can make the same shift. Not by adding more review meetings, more consultants, or more checkpoints. By embedding the test in the tool. By making structural feedback, cost data, and regulatory compliance visible in the moment the design decision is being made.

This will not eliminate the need for detailed engineering or professional cost estimation. Those disciplines bring expertise that automated indicators cannot replace. What it eliminates is the long, dark gap between a design decision and the information needed to evaluate it. The gap where problems grow quietly until they are expensive to fix.

The firms that close this gap will not just avoid rework. They will design better buildings, because every decision will be informed by the reality of how that building will actually get built. That is not a minor efficiency gain. It is a fundamentally different way of working.

The tools exist. The question is how long the industry will keep testing buildings after they are designed, instead of while they are being designed.