How to prepare a Revit model for outsourced development
Version, a usable file, markups and a written change list matter more than a vague request to “develop the model”.
Published 24 August 2026 · 3 min read
Outsourced Revit model development only works when the receiving team can open the file, understand what should change, and return it in a state the office can keep using. A vague request to “develop the model” is not enough to quote, and it is not enough to produce against.
Revit version
Name the year the office will edit after handover. A model saved in a newer release cannot be opened in an older one. If linked files are on a different year, say so. Mixed versions are a common reason a package stalls before production starts.
File health
Send a file the office can actually work in. Warnings that nobody has reviewed, unused links, and a Project Browser full of duplicate views all become the next person’s problem. You do not need a perfect file. You do need to know whether the starting model is the live one, and whether it is already in trouble.
Links and worksets
If the model is workshared, say how it should be returned. If other disciplines are linked, include the links the work depends on, or a note that they are omitted. A modeller cannot coordinate against a link that was never sent.
Project standards
If the returned work has to match the office, send the template, a previous project, or a short note on naming, view templates and browser organisation. Hoping the modeller will guess the office standard is how files come back technically complete and still painful to use.
Required changes, markups and a scope list
Markups help when they are tied to a written list: what is in, what is out, and which levels or zones are included. A PDF full of clouds with no instructions leaves every cloud as a design question. Conflicts between the model and the markups should be referred back, not resolved by invention.
Deliverables
State whether the return is the updated .RVT only, or also views, sheets or a PDF issue. Documentation from a model that is still being changed is a separate scope unless it is written into this one.
Questions
No. Development starts from the Revit file you already have. If that file is not usable, say so — the job may be closer to a new model.
Markups help when they are tied to a written list of changes. Clouds without instructions leave too much to interpret.