#13 | In-Place and Loadable Families: the hour you don't redo twice

You have an open project and you need an element that doesn't exist in any library: a shelf with a unique shape, a decorative panel, a detail that the client requested custom-made for that specific wall and only that wall. You open the In-Place Editor, model it, close it, and move on. Five minutes, zero friction. The project moves forward and you haven't wasted time thinking about nomenclature, parameters, or where to save the file.

Then comes the second project. And that shelf—with some minor variations, the same logic, the same idea—you need it again.

Do you reopen it? No. You can't: it's locked inside the project where it was born; it's not a file, it's not in your browser, it's nowhere except right there. You redo it from scratch. And if you need it a third time, you redo it a third time. Every time the same shortcut, every time the same recurring cost—only this time you don't call it "time saving" anymore.

The difference between In-Place and Loadable is not technical, it is economic

Revit isn't asking you "where do you prefer to model"—it's asking you whether you are building an element or an asset. An element solves today's problem. An asset solves today's problem and the one you don't even know you have yet. The difference only becomes apparent later, when the problem arises again and you have—or don't have—something to reopen.

This is also the reason why those who live by Revit Families instead of individual projects don't even ask themselves the question: every loadable family I publish on the Marketplace was born from this identical crossroads, resolved in the opposite direction. Not because I know in advance who will use it, but because building it as an asset costs the same effort as building it as an element—the difference is entirely downstream, in how many times that effort is repaid.

In-Place is not wrong. It is a choice that is valid as long as you already know, with certainty, that you will never do it again.

The problem is that this crossroads is almost never explained for what it really is. I have seen beginners model an entire kitchen wall entirely In-Place—and I have seen video tutorials by colleagues teaching exactly that. The former didn't know what they were giving up because no one had ever told them. The latter knew—or should have known—and didn't explain it anyway.

It's not a technical error. It is an educational gap that is transmitted from one video to the next, creating modelers who are capable of opening the In-Place Editor but incapable of recognizing when they shouldn't.

A practical example

Take the Kitchen Utensil Cabinet from the Marketplace. It wasn't created for a specific project—it was created to be reloaded into projects that didn't even exist when I modeled it. This meant thinking, from the very first Reference Plane, about what needed to remain fixed and what needed to be able to adapt: dimensions, materials, configuration of internal compartments—everything parameterized to respond to different contexts, not just one client.

If you want to see in detail how this logic is built—where the parameters live, how the various components of the piece of furniture move together—I have already taken it apart piece by piece in Inside the Files #10 | Everything moves together: anatomy of a parametric piece of furniture. Here, the principle matters, not the mechanics: the difference between this family and a kitchen wall modeled In-Place is not in the geometric complexity. It is in the fact that this one, you can reopen in six months, in a project you can't even imagine today, and it still works.

When In-Place is the right choice

Not everything deserves to become an asset. A single shelf, an open bookcase with four shelves, a decorative element that will never return—for these cases, In-Place remains legitimate and is even convenient: you have it at your fingertips without having to open a new file, choose a template, or think about nomenclature.

(*In the next episode of Inside the Files, we will look at how to model a home office bookcase family in-place, step by step.)

Even here you can work with parameters—In-Place doesn't force you to model rigidly—but they remain "house" parameters: they live and die in the project where you created them; you don't take them with you anywhere else.

The point is to distinguish between two very different situations: doing it In-Place because you know you won't need it again, or doing it In-Place because it's the fastest path and you haven't stopped to ask yourself if you will need it again. In the first case, you have made a choice. In the second, you have only postponed a problem.

And if you decide it's worth building it properly—correct template, right category, parameters designed to last—put in the time it takes. An hour well invested today is an hour you will never have to spend again tomorrow.

The Inside the Files tip

If you would do it again even just a second time, it's not In-Place. It's a family you haven't loaded yet.

---

The criterion you have just read—element or asset—is the same one that has run through this entire season. When in Inside the Files #11 we mapped where Category, Family, Type, and Instance live, the underlying question was always the same: what are you building, and for whom are you building it—only for today, or also for the you of tomorrow.

In-Place and Loadable are the most immediate version of this question, the one that presents itself before you even open the Family Editor. But it is not the only threshold. There is a third type of family—Adaptive—that doesn't just limit itself to choosing between "inside" or "outside" the project: it adapts, point by point, to geometries you don't even know yet. It is a level that will deserve its own article, when the season calls for it.

For now, the question remains: the next time you open the In-Place Editor, are you doing it because it's the right choice, or just because it's the closest one?