A Revit add-in evaluation checklist for careful firms

Start with the problem, not the tool

Most add-in evaluations begin with a demonstration that looks impressive. A better starting point is a written problem statement: what task is slow, error-prone or inconsistent today, how often it occurs, who does it and what an acceptable result looks like. Without that, you cannot judge whether the tool helps, and you risk adopting software that solves a problem you do not have.

Write down the current method too, even roughly. If you cannot describe how the task is done now and roughly how long it takes, plan to observe it before the trial. An unknown baseline should stay marked as unknown, not filled with a guess.

1. Compatibility

• Which Revit versions are supported today, and what is the vendor's stated approach to new releases?
• Which operating systems and hardware configurations are supported?
• Does it work with your deployment setup, for example virtual desktops or roaming profiles?
• Does it conflict with add-ins you already rely on?

If your firm runs several Revit versions across projects, check coverage for each one you need. A tool that supports only one version may still be worthwhile, but plan for it.

2. Installation and deployment

• Is installation per-user or machine-wide, and does it require administrator rights?
• Can IT deploy it silently across workstations?
• How are updates delivered, and can you control when they happen?
• Does uninstalling remove it cleanly?

Revit discovers add-ins through manifest files in known folders, with separate locations for per-user and all-user installations. Knowing which one a tool uses helps IT manage and audit it.

3. Data handling and privacy

This area deserves particular care, because project models and details often contain client-confidential information.

• Does the add-in send any project data off the workstation? If so, what, where, and under which terms?
• Does it collect usage telemetry? Can it be disabled?
• Does it require an internet connection to run, or only to activate a license?
• Does the vendor's privacy policy match what the tool actually does?
• Do your client contracts restrict cloud processing of project information?

Ask the vendor directly and get the answer in writing. "Local processing" should mean the content you work on is not uploaded.

4. Security

• Is the add-in digitally signed by an identifiable publisher? Revit warns when loading unsigned add-ins.
• Where is the installer obtained, and can its integrity be verified?
• What permissions does it need beyond Revit itself?
• How does the vendor handle reported vulnerabilities?

5. Fit with your standards

Many add-ins create elements, types or parameters. The important question is whose standard the result follows.

• Does it use your existing types, such as line styles, text types, families and parameters, or does it create its own?
• Can you configure mappings or rules so results match your template?
• Does it leave behind anything that a model health check would flag, such as new styles, imported content or unexpected warnings?
• Are results native Revit elements that remain editable without the add-in?

6. Transparency and control

• Does it show what it will do before doing it, such as a preview or a summary?
• Does it report what it could not do, instead of failing silently?
• Can its actions be undone with standard Revit undo?
• Is its behavior documented, including known limitations?

A tool that tells you clearly what it skipped is easier to trust than one that appears to succeed every time.

7. Licensing and cost

• Is the license per user, per machine or per firm? Can licenses move between people?
• Is it a subscription or a one-time purchase? What happens when a subscription ends?
• Are updates and support included?
• What is the total cost across the users who will actually use it?

Compare cost with the value of time saved on accepted results, not on first drafts, and remember that time saved is not automatically money saved unless it changes how work is staffed or scheduled.

8. Support and vendor

• How do you get support, and what response can you expect?
• Is there documentation and release notes that list changes and known issues?
• How does the vendor ask for sample files when diagnosing problems? Synthetic samples are preferable to client drawings.
• Is the vendor likely to maintain the tool through future Revit releases?

9. Exit plan

Ask what happens if you stop using the tool. Do models still open and behave normally? Are created elements native and editable? Is any data locked in a proprietary format? A good add-in leaves your models better and does not make them dependent on it.

10. Adoption effort

• How much setup is needed before it is useful, such as mappings, configuration or templates?
• Who will own that setup and keep it current?
• How long does it take a typical user to become productive?
• Does it change review responsibilities?

Red flags during evaluation

Some signals deserve extra caution, regardless of how good a demonstration looks:

• Vague answers about data. If the vendor cannot say clearly what leaves the workstation, assume more does than you would like until shown otherwise.
• No stated limitations. Every tool has limits. A vendor that lists none either has not tested carefully or is not telling you.
• Results that only look right. Output that appears correct on screen but uses imported or non-standard content will cause problems later.
• Pressure to trial on live projects. A reasonable vendor will support testing on synthetic or non-production data.
• Claims of savings without a method. Ask how any figure was measured. If there is no method, treat it as marketing.
• Lock-in. Elements or data that cannot be used without the tool create a dependency you may not want.

Who should be involved

An evaluation works best with a small group. Include a person who does the task daily, the standards owner who will judge fit with the template, someone from IT who will judge installation and security, and a decision-maker who controls budget. Keep the group small so the trial stays focused, and agree in advance who makes the final decision.

Running a fair trial

1. Use test data. Run the trial on synthetic or non-production content in a test project, never on live client models.
2. Define criteria in advance. What does an accepted result look like? Use the same criteria for the add-in and for the current method.
3. Set an effort cap and a stop condition. Decide how much time the trial gets and what would end it early.
4. Measure the whole path. Setup, execution, cleanup, review and rework, compared with the current method on the same content.
5. Include a skeptic. Someone who will look for problems makes the result more credible.
6. Record the decision. Adopt, adopt with conditions, extend the trial or reject, with reasons.

Applying this to Codex

We encourage firms to use this checklist on Nova Codex as on any other tool. According to the Codex page, it is a Revit 2025 add-in for Windows with per-user installation; it reads details saved as DXF and creates native drafting views using an explicit mapping to the project's existing line styles, text types and filled region types; it previews entity counts and skip diagnostics before creating anything; and processing is local. Its entity coverage is deliberately listed, including what is not yet supported. Qualified firms can request a guided 14-day evaluation using a synthetic or non-production test project, which fits the trial structure above.

Evaluation checklist

• Written problem statement and baseline, or a plan to observe it.
• Compatibility, installation and deployment confirmed.
• Data handling and security answered in writing.
• Standards fit verified with a health check.
• Transparency, licensing, support and exit plan reviewed.
• Trial on test data with criteria, effort cap and stop condition.
• Decision recorded with reasons.