This describes work that is in design. Everything below is what we are building, except where it is explicitly marked as available today.
A firm in the American Midwest runs about 300 units. Two low-rise buildings. Thirty-one scattered single-family homes. A handful of condo units managed for absentee owners who each want something slightly different. Four furnished corporate rentals.
The screening form is the same for all four.
The showing slot is thirty minutes for all four — generous at the walk-up, where the manager is already in the building and the next viewing is upstairs, and faintly absurd at a house forty minutes out, where thirty minutes of showing carries ninety minutes of driving.
Nobody sat down and decided any of this. The process was set when the firm had eleven units and one kind of building, and every property since has been fitted into it. That is how it happens everywhere: not by decision, by accretion.
The tax a mixed portfolio pays
There are only two ways to run four kinds of property, and both of them cost something.
One process for all four. It fits none of them. The walk-up wastes calendar, the houses are under-scheduled, the corporate rentals get asked questions that do not apply to a three-month furnished let, and the condo owners' particular requirements live in somebody's memory.
Four processes maintained by hand. Every one of them is a separate thing to keep current. When the firm changes its position on something — deposits, pets, notice — that change has to be made in four places, and it will be made in three.
Most firms end up with a third arrangement that is worse than either: one process on paper, and four in practice, with the differences held as exceptions in the heads of whoever handles each property type. That works exactly as well as the people do, which is to say very well right up until somebody is away.
One thing is available today, and it is the foundation the rest of this rests on: Releaser offers custom configuration for different property types. That is real and you can use it now. Everything else described below is design work, and the rest of this article is written in the future tense for that reason.
What we are building: defaults you set, and overrides where they differ
The design is an inheritance model, and it is worth explaining in plain terms because the name makes it sound more complicated than it is.
A firm will set what is true across the whole firm once. Your hours. Your standard notice period. Your tone. The things that go to a person. Then a level down — a region, a property type, an owner's portfolio, a single building — will override only what genuinely differs there, and inherit everything else.
The scattered houses need a longer showing slot and a bigger travel gap. They do not need a different pet policy. So the houses would carry the longer slot and inherit the pet policy, and when the pet policy changes it changes once.
That is the whole idea, and the reason it matters is not elegance. It is that the number of things a firm has to maintain stops growing with the number of properties it owns. A firm at 300 units maintains one set of firm-level rules plus a handful of genuine differences, rather than 300 configurations or one that fits nothing.
Two things this deliberately is not. It is not the software arriving with opinions about what a triplex needs — you author your rules, and nothing is pre-tuned on your behalf. And it is not a hierarchy you have to plan up front: the sensible path is to put everything at the firm level first and push things down only when you actually hit a difference.
Why this has to be built before anything needs it
Here is the engineering argument, and it is the reason this piece exists rather than being a line in a feature list.
Inheritance is an architectural decision that gets made early or never.
If the firm → segment → property-type → property model is right in the first version, then adding segmentation later is a scoping query and a settings screen. The data already knows which level each setting came from. Adding a region, or an owner's portfolio, or a new property type, is a matter of describing it.
If it is not right in the first version, then every configuration in production is stored flat, against individual properties, with no record of which level it came from or whether it was deliberate. Adding inheritance to that is not a feature. It is a migration of live customer configuration, run against firms who cannot tell you which of their 300 settings were choices and which were defaults nobody looked at.
So it goes in before anything needs it. This is the kind of decision that is completely invisible when it goes right — nobody has ever thanked a vendor for a data model — and it is the difference between a product that grows with a firm and one that has to be rebuilt at the point the firm gets interesting.
The trade-off, and it is the same sentence as the benefit
A firm-level change propagates. That is exactly what you want and exactly what should make you careful, and it is one sentence, not two.
Change your standard notice period at the firm level and it changes for 300 properties at once. That is the point — it is why you are not editing 300 things. It is also how a firm changes something for 300 properties without meaning to, and discovers it from an applicant.
Which is why the overrides and the history matter as much as the defaults. Three things belong in the design from the start, not added after the first accident:
Overrides have to be visible and sticky. If the walk-up's showing length was deliberately set to twenty minutes, a firm-level change to thirty must not silently reclaim it. A deliberate local decision outranks a general one.
You have to be able to see where a setting came from. Looking at any property, the question "is this value inherited or was it chosen here" needs an answer on the screen. Without it, nobody can safely change anything at the firm level.
Changes need a history with a name on them. Not for audit theatre — because six weeks later somebody will ask why the corporate rentals stopped asking a question, and the useful answer is a person, a date and a reason.
Where this leaves the four kinds of building
Take the firm from the top of this piece and run it through the model.
The two low-rise buildings inherit almost everything and override the showing slot down — the manager is on site, viewings are short, and the calendar can carry more of them.
The thirty-one houses override the slot up and carry a much larger gap between bookings, because their real cost is the drive. They may also override which questions get asked, since a house and a walk-up attract different applicants asking different things.
The condo units are the interesting case, because what differs is not the property type but the owner. Each absentee owner has their own preferences about showings and communication. That is a segment defined by ownership rather than geography or building type, and it is the clearest argument for why the model has to be more than a property-type dropdown.
The four corporate rentals are a different leasing job entirely — shorter tenancies, faster turns, different questions — and they override the most.
Four sets of behaviour. One set of firm rules underneath them. And the maintenance job is the firm rules plus the genuine differences, rather than four hand-kept processes drifting apart at their own speeds.
Releaser is available to property management firms in the United States and Canada, and offers custom configuration for different property types today. The inheritance model described here — firm-level defaults, segments, and overrides that show where they came from — is in design. This is what we are building it to be.