How to outsource Revit family creation services: the brief, the pilot, the acceptance check

The decision comes down to three things: how many families you need, how complex each one is, and how much capacity the in-house team has. An office with one Revit technician who needs a few simple families every few months usually builds them in-house. The same office facing dozens of equipment families with connectors, parametric dimensions and type catalogs for a new project won't get there in time on internal capacity.

Outsourcing usually makes sense for:

• Building or rebuilding the office library, many families inside a fixed window.
• MEP families with duct, pipe and electrical connectors that carry system data correctly.
• Adaptive, structural, or nested and shared families that need specialist experience.
• A project whose client has set a specific standard for family data.

The manufacturer's side, a company commissioning families of its own products for publication, is a different job, covered in BIM object creation for manufacturers.

A vendor builds what the brief describes. If the brief is a product PDF, you get a family that looks like the product and ignores your office standards. A complete brief covers:

1. Revit version. A family saved in a newer version won't open in an older one. Families should be delivered in the oldest version the office runs.
2. Category and hosting for each family. Hosting can't be changed after the fact.
3. The office's shared parameter file and the parameters each family must carry, each marked type or instance.
4. Naming rules for files, types, subcategories and materials.
5. Detail levels: what shows at Coarse, Medium and Fine, and the expected LOD.
6. Source data: CAD drawings, manufacturer catalogues, dimensions, the list of types.
7. Sample schedules and tags from the office, so the family is tested against real output.

If the project runs under ISO 19650, the project's information requirements belong in the same brief. The vendor needs to know which data each family carries, and for which stage.

Before ordering a hundred families, order one or two representative ones: one simple, one harder than the rest of the set. The pilot shows how the vendor read the brief, whether they used your shared parameters correctly, and the quality of what they hand over.

The feedback on the pilot becomes the standard for the whole set. Fixing a naming rule on family one takes an hour. Fixing it across a hundred delivered families is a project of its own.

A family that looks complete in a 3D view doesn't necessarily behave in a project. Check delivery inside a test project built on the office template, not in the Family Editor:

• Flex test: every type, and the full dimension range the family claims, builds without errors.
• Schedule test: the family appears in the office's schedules with correct values in every column. Shared parameters are identified by GUID, so a parameter with the right name and the wrong GUID stays blank in schedules and tags.
• Tag test with the office's standard tags.
• Visibility at Coarse, Medium and Fine, in plan, elevation and section.
• Weight: no imported CAD, no warnings, unused content purged.
• Connectors in MEP families: direction, system and size of each one.

Most of what turns up here is small. One extra character in a parameter name. A material with the wrong name. A subcategory that doesn't exist in the office template. The small errors are the ones that make a family useless in a project, and they only show when you test it in one. To check a whole model against the same rules automatically, see Revit model checker.

Some faults show up in the tests above, but their cause sits in how the family was built, and fixing them means rebuilding part of it. Look for these in the pilot so they don't repeat across the set:

• Geometry not locked to reference planes. The family is right at its default size, then parts stay behind when it flexes.
• Hard-coded dimensions. The family looks parametric, but some sizes are drawn straight into the geometry and ignore the type.
• Wrong category. Equipment built as a Generic Model draws on the plan and never appears in that category's schedules or view filters.
• Overmodelled detail. Screws, textures and internal parts no drawing will ever show, adding file weight and regeneration time.
• Wrong IFC data. If the project exports IFC, each family's IFC class and property sets have to match the project's requirements.

Put each of these in the brief as one sentence. A vendor told up front that geometry locks to reference planes and Coarse stays simple will build it that way, and the rework never happens.

Test a vendor's work in your project, not on their website. Ask for a sample RFA and run it through the same acceptance checks. A rendered image of a family says nothing about its parameters, hosting or file weight.

Settle these before signing: how many revision rounds each family's price includes, who owns the delivered files and whether the office can reuse them on later projects, confidentiality for the project's drawings and data, and whether source files such as type catalogs and reference CAD come with the delivery. For remote work, someone in the office has to own answering the vendor's questions and approving families. Otherwise the questions sit unanswered and the schedule slips.

If the office has a Revit technician with time to spare and needs a few simple families a year, building in-house is cheaper and the knowledge stays in the office. If Autodesk's library or manufacturers' families cover what you need with small edits, you don't need a family creation service, and you don't need us, or anyone like us.

Outsourcing pays off when the volume or complexity exceeds internal capacity and the office has a written family standard. If that standard doesn't exist yet, writing it is step one, and it usually starts with Revit library optimization. How each family gets built is in custom parametric Revit family creation, and the service itself is Revit family creation.