What is the difference between a quantity takeoff and a construction activity?

A takeoff gives you volumes and areas: this wall is 12 cubic meters of concrete. A construction activity gives you what has to be bought, scheduled and paid for: rebar weight, formwork surface, pour volume, curing time, the crew that places it. The second is what a budget needs. CodeBranch builds the extraction layer to produce activities rather than volumes, because a budget line that says "12 m³ of concrete" still needs a human to turn it into a purchase order.

Does the Revit add-in need to run on every estimator computer?

A .NET add-in runs inside the Revit process on the desktop, so it is installed per machine, per Revit version. That has consequences for deployment and for how the extracted data reaches a central system. CodeBranch treats this as an architecture decision made before any code is written, because changing it later means rewriting how the tool authenticates and where the data lives.

What happens when the design changes after the budget is approved?

That is the case worth designing for, because it is the normal case. A model changes constantly, and an extraction pipeline that only works on a complete model is a reporting tool, not a budgeting one. CodeBranch designs the extraction so that a design change surfaces its cost impact rather than requiring a manual reconciliation later, which is the difference between a budget that reflects the project and one that reflects last month.

Do we need our models rebuilt before this can work?

Usually not rebuilt, but usually adjusted. The extraction depends on conventions being consistent — the same kind of element modeled the same way across the project. CodeBranch assesses model readiness during the Product Definition phase, because discovering mid-build that half the model does not follow the convention is the most common reason these projects run long.

How do we evaluate a partner for a BIM integration project?

Ask what they would do when the model does not follow the convention, and ask how they handle Revit version upgrades. Both questions have uncomfortable answers that only someone who has shipped one of these will give you. A partner who describes the extraction as straightforward has not maintained one through a Revit release. CodeBranch starts with a Product Definition phase that surfaces exactly these constraints before development begins, so the hard parts appear in planning rather than mid-sprint.

Turning Revit Models Into Construction Quantities

Q: Can you extract accurate quantities from a Revit model automatically?

You can extract geometry automatically. Turning that geometry into quantities an estimator will sign off on requires deciding how each model element maps to a cost structure, and that mapping is a modeling convention, not a technical feature. CodeBranch built a Revit integration for Building Companion, the budget control platform used by an electrical construction contractor, and the mapping design was the part that determined whether the numbers could be trusted. A model built without those conventions produces extractions that look precise and are not.

A Revit quantity takeoff is not a geometry export. Exporting geometry is solved and has been for years — you can get volumes and areas out of a model in an afternoon. What takes real work is turning “this element is a 12 cubic meter concrete wall” into what a budget actually needs: rebar weight in kilograms, formwork surface in square meters, pour volume, curing time, and the crew hours to place it. That translation is where the engineering is, and it is almost entirely undocumented.

Quick Summary

Geometry extraction is the easy half; mapping geometry to a cost structure is the half that determines whether the output is usable.

The mapping depends on modeling conventions, so the quality ceiling of any extraction is set by how the model was built.

Revit stores lengths internally in decimal feet regardless of the units shown on screen, which produces plausible-looking wrong numbers when ignored.

Each Revit version ships its own API assemblies, so an add-in is compiled per version and version support is a maintenance commitment, not a one-time task.

Four design decisions determine whether the pipeline survives contact with a real project. None of them is obvious, and all of them are cheaper to make before writing code.

CodeBranch built a Revit integration for Building Companion, the budget control platform used by an electrical construction contractor, feeding extracted quantities into the same Unitary Price Analysis engine described in the custom budget control case study. This post is about the decisions that kind of pipeline forces, and what each one costs — a specific instance of the broader pattern in what construction companies build when their platform runs out.

Why Isn’t a Revit Takeoff Just an Export?

Because a budget is not organized the way a model is.

A model is organized by object. A structural concrete wall is one element with a volume, a material, and a set of parameters. A budget is organized by the work required to produce that object: the concrete to pour, the rebar to tie, the formwork to erect and strip, the labor hours, the equipment time, the transport. One model element becomes many budget lines, and the relationship between them is a rule, not a property stored in the file.

That rule lives nowhere in Revit. It lives in how the estimating team thinks about work, and the integration’s job is to encode it. Which means the interesting problem is not reading the model — it is deciding what each element means in cost terms, consistently, across a project where the model was built by people who were not thinking about your budget structure.

CodeBranch designs these extraction layers to emit activities rather than volumes, because a budget line reading “12 m³ of concrete” still needs a person to turn it into something purchasable — which puts the manual step back where it was.

This is also why the output quality has a ceiling set by the model. An extraction pipeline cannot recover information the modeler never entered. If wall types do not distinguish between structural and partition walls, no amount of parsing will separate them, and the estimator will catch the error — or worse, will not.

How Do You Map a Revit Element to a Cost Template?

This is the decision that determines whether the pipeline is stable or fragile, and there are two defensible answers.

Map by shared parameter GUID. Revit shared parameters carry a globally unique identifier that survives renaming. Bind a shared parameter to the families in scope, write the cost classification into it, and the mapping holds regardless of what anyone calls the type later. The cost is upstream: someone has to load the shared parameter file into the project, apply it to every relevant family, and keep doing so as new families arrive. You are asking the modeling team to maintain metadata for a downstream system they may not use.

Map by family and type name. Nothing is required of the modeler — the add-in reads the names already there and matches against a lookup table. It works immediately on existing models with no upstream change. It breaks the day someone renames a type, duplicates a family with a suffix, or a new subcontractor delivers a model with their own naming. The failure is silent unless you design for it.

	Shared parameter GUID	Family and type name
Survives renaming	Yes	No
Works on an existing model as-is	No — requires binding first	Yes
Asks something of the modeling team	Yes, ongoing	No
Failure mode	Missing parameter — loud, easy to detect	Wrong or missing match — silent unless checked
Handles models from outside parties	Only if they adopt the parameter	Only if they follow the naming
Effort to set up	Higher	Lower

Neither column wins outright. Shared parameters are the right answer for an owner or contractor who controls the modeling standard across projects. Names are the right answer when models arrive from parties you do not control and the alternative is not integrating at all. Most production systems end up with a primary strategy and a fallback, and the honest question is not which to choose but what happens when the primary one misses.

Which Revit Version Are You Building Against?

Every Revit release ships its own API assemblies. An add-in compiled against one version’s API assemblies does not load in another, so supporting Revit 2023 and 2024 means two builds, and each new release means another.

This is a maintenance commitment that rarely appears in a project estimate. Autodesk’s release cadence is annual, clients upgrade on their own schedules, and a large contractor will have several versions in use simultaneously across project teams. The practical question is whether the codebase isolates version-specific calls behind an abstraction so that supporting a new release is a small adapter, or whether the extraction logic is written directly against the API and each version is a fork.

The same applies to deployment. An add-in is registered through a manifest placed in Revit’s add-ins folder, per version, per machine. Getting it onto fifty estimator workstations and keeping it current is an IT problem that belongs in the plan, not a detail to discover at rollout.

Why Do Your Numbers Look Wrong by a Factor of Three?

Revit stores lengths internally in decimal feet, regardless of what the project displays. A model showing millimeters is storing feet. Read a length parameter directly and you get a number that is internally consistent, plausible, and wrong for every downstream calculation that assumes metric.

The API provides conversion utilities for exactly this reason, and the failure mode is what makes it dangerous: nothing throws. The extraction completes, the budget populates, and the error surfaces when someone notices the concrete order is off. Areas and volumes compound the problem, since the error scales with the exponent — a length off by a factor of 3.28 becomes a volume off by a factor of 35.

Any extraction pipeline needs unit conversion at the boundary and a test that catches it. The test is trivial to write and the bug is expensive to find in production.

Where Does the Add-in Send the Data?

A desktop add-in runs inside the Revit process on an estimator’s machine. The extracted quantities need to reach a central system, and there are two shapes for that.

Direct to an API. The add-in calls the backend, which means it needs credentials on the desktop and network access from inside a Revit session. It also means the extraction is only as available as the connection, and a failed call mid-extraction needs handling.

Through an intermediate file. The add-in writes a structured export that gets picked up separately. Simpler, works offline, and the estimator can inspect what was extracted before it becomes a budget — which is not a trivial benefit when trust in the numbers is the whole point. The cost is that it is no longer real-time, and someone has to own the handoff.

The choice interacts with the previous question about authentication: an add-in that holds credentials on a shared workstation is a different security posture than one that writes a file.

What Happens When the Model Changes?

This is the case that separates a demo from a system, because the model always changes.

A designer thickens a slab, adds a column, revises a tendon layout. If the pipeline can only process a complete model from scratch, it is a reporting tool that produces a snapshot someone has to reconcile against the previous one by hand. If it can identify what changed and update only the affected budget lines, it becomes part of how the project is managed.

Doing the second requires a stable identity for model elements across extractions and a strategy for what happens to a budget line whose element was deleted — or whose element still exists but now costs something different. Neither is difficult in isolation. Together they are the design problem that most of these projects underestimate, and CodeBranch raises it during definition rather than discovering it when the first revised model arrives.

What Should You Decide Before Writing Code?

Four things, in this order, because each one constrains the next:

The mapping strategy, because it determines what you need from the modeling team and how much lead time that takes. This decision has an organizational dependency, which makes it the slowest to change later.

The version support policy, because it shapes how the codebase is structured. Retrofitting an abstraction layer after the fact is more expensive than designing for it.

The data path from desktop to system, because it drives the security and authentication design, and those are hard to revisit once estimators are using the tool.

The change handling model, because incremental updates require element identity to be tracked from the first extraction. Adding it later means the historical data does not support it.

None of these is a technical unknown — they are all solvable. They are decisions with organizational consequences, which is why they belong in a definition phase rather than a sprint. CodeBranch runs that phase before development on every engagement, and a BIM integration is the clearest case for why: the expensive mistakes here are architectural, and they are made in week one.