Skip to content
ARTINEXT

Service · Custom tools · Working remotely

Revit plugin development, built from your workflow.

Custom Revit plugins, add-ins and extensions for architecture, structural, and MEP teams. Every tool is studied against how your team actually works before a line of it is written.

01, Why a plugin, and why now

The three things a plugin is usually bought to fix

Almost every plugin request traces back to one of these. Naming which one you're in decides what the tool has to do, and how much of it you actually need.

A step nobody should still be doing by hand

Tracing linework, renaming, renumbering, copying values between views. Work that is fully determined by rules already in your standard, done by a person from memory, on every project.

Two pieces of software that don't speak

The structural model, the spreadsheet, the drawing set. Each one is fine alone. Moving between them is a person retyping, which is where the discrepancies come from, and why nobody trusts the numbers.

A rule that only exists in someone's head

The office standard everyone half-knows and nobody can check. Until it's written as something a machine can test, every model is compliant right up to the moment someone looks.

02, See it run

Two tools, recorded end to end

Both of these were built for a specific conversion problem a team was doing by hand. Nothing here is a mockup, these are screen recordings of the tools running.

ARTINEXT C2RCAD → Revit

Builds the Revit model from a coordinated CAD plan set

Instead of a team tracing linework by hand, the tool reads the plan set and creates native Revit elements from it, walls placed on their real wall types, floors, levels, and openings, so the model starts from the drawing rather than from someone's interpretation of it.

Input
Coordinated CAD plan set
Output
Native Revit elements
Runs in
Revit

Recordings are silent and play without sound.

03, What moves the number

What a plugin actually costs is decided before it's built

There's no price list on this site, because a plugin isn't priced by its button. Four things move the size of the job, and you can estimate all four before talking to anyone.

How well the rule is already written

A standard that exists as a document is a specification. A standard that lives in three people's judgement has to be extracted first, and that extraction is the work.

How many systems it has to touch

Inside Revit only is one job. Revit plus a spreadsheet is another. Revit plus a database plus something with a login is a different project, mostly for reasons that have nothing to do with Revit.

How many people will run it

A tool for the one person who requested it can be blunt. A tool for thirty needs to survive being used wrongly, on a model it didn't expect, by someone who wasn't in the kickoff.

What has to happen when it fails

Silence is cheap and useless. Reporting what didn't convert, and why, is the difference between a tool your team trusts and one they check by hand anyway, which means they now do both jobs.

No estimate is given before the first two stages. A number produced before the problem is stated in full is a guess wearing a currency symbol.

04, Process

Discover, define, build, evolve

Four stages. The first two are where most of the risk gets removed.

Discover

We watch the real workflow, not the documented one. What's actually done by hand, by whom, and how often it goes wrong.

Define

The problem gets stated in full, with a success measure that can be tested, before any tool is proposed.

Build

Built against your standards and your users. Every added layer of complexity has to earn its place.

Evolve

Systems are built to change shape as your work grows, so the tool doesn't become the next thing to work around.

05, Questions

Before you write to us

Do you build for a specific Revit version?

Whichever ones your office actually runs, including more than one at a time. The version range is a scoping question asked in the first stage, supporting three versions is not three times the work, but it isn't free either. What the version range does to the size of a job is set out in the plugin cost piece.

Can you work with our existing plugins and templates?

Yes, and it's usually the better answer. If something already installed does part of the job, the honest recommendation is to extend or connect it rather than replace it. If a tool doesn't solve the real problem, we don't recommend it, even when building it from scratch would look more impressive.

Who owns the code?

You do. It's your process encoded, it shouldn't live somewhere you can't reach it. Source and build instructions are handed over.

Is Dynamo an option instead of a plugin?

Sometimes it's the right one. A graph is faster to build and easier for your team to adjust; compiled code is faster to run, easier to distribute, and doesn't break when someone reorganises a node. Which one fits is decided against how the tool will be used, not by preference. Where a graph stops being enough is covered in the Dynamo piece.

How do we know it works before it's finished?

The success measure is written down in stage two, before anything is built, and it has to be testable. A tool that can't be checked against a stated measure hasn't been finished, it's been stopped.

Do you work with teams outside Iran?

Yes. The studio is based in Iran and works remotely; that's how most projects run regardless of where the team sits.

06, Start

Tell us the step you'd stop doing by hand

Bring the workflow, not the spec. If a plugin is the wrong answer, we'd rather tell you that in the first conversation than at the end of a build.

We are not a fit if you want a generic add-on installed without any process review, or an estimate before the problem is stated.