This describes work that is in design. Everything below is what we are building, not something you can switch on today.
It is a Tuesday in a firm that runs 180 units. An applicant asks whether the deposit can be split across two months.
The leasing coordinator knows the answer. It is no — except at Riverside, where the owner allows it, and except when the applicant is a returning tenant, in which case it is yes and always has been. She knows this the way you know your way home. She has worked there four years.
She is on holiday next week. The person covering her desk knows the answer is no. That is the whole of what they know, and there is no document that says otherwise, because there has never been a document.
None of this is dysfunction. The firm has a real policy. It is applied consistently, by people who know it well. It simply does not exist anywhere outside them.
The rules are real. The problem is where they live.
Every firm we talk to has a set of these. Showings on Saturdays but not Sunday mornings. First and last month's rent. Pets case by case, but never in the heritage building. Anything touching a lease term goes to Marie, always.
Those are policies. They are stored in a leasing coordinator's memory, on a laminated sheet taped beside a monitor, and in a Slack message from March that three people half remember.
That arrangement works, right up until the week it doesn't: a holiday, a resignation, a new hire's first month, a Saturday afternoon, two people answering the same question three days apart and giving different answers to it. The expensive part is not any single wrong answer. It is the gap between what the firm's policy is and what any given person on any given day says it is — and nobody can see that gap, because there is nothing to compare the answers against.
The first thing we are building is a document
We are calling it the Policy Pack, and the name is deliberately unglamorous, because that is what it will be: your rules, written down once, in your own words.
Pet policy. How you treat income. Notice periods. Your hours. What always goes to a person instead of being answered. The things that are true about each building. Written as prose you would recognise as yours, versioned the way a document is versioned, and readable at any time by anyone at your firm who is allowed to see it.
The software will then follow it. Not approximately — from it. When an answer goes out, you will be able to read back which line of your own pack produced it.
Authoring it will be a set of questions with real defaults, grouped around the decisions an operator actually has an opinion about: your hours, your tone, what to say when a unit is not ready, what always goes to a human, what must never be said. Where you already have something written, it will arrive as a proposal rather than as fact — lines you approve one at a time, and the ones you do not approve will not exist. Extraction will never be authoritative. The pack has to be the firm's own written criteria, authored and owned by the firm, and that is a design constraint before it is a legal one.
The per-customer part is the policy, not the software
This is the argument underneath the feature, and it is why this piece is the first one we are publishing about the roadmap.
A firm running 200 units does not need its own bespoke system. It needs a system that holds its rules — and rules are data. Once you accept that, a lot follows. The per-customer artefact becomes a document rather than a codebase. It can be read by the people whose rules they are. It can be diffed, so you can see what changed and when. It can be rolled back. It can be handed to a new hire as the answer to "how do we do it here," which is a question that currently gets answered by whoever is nearest.
Compare the alternatives honestly. Rules buried across configuration screens are real rules too, but nobody can read them end to end, and no one has ever printed them out and disagreed with line 14. And rules inferred by software watching your team work are worse again: nothing here infers your policy from your behaviour. A rule will be in your pack because a person at your firm wrote it and signed it off, and you will be able to point at the line.
That is also why everything else we are building waits on this one. Answers after hours, drafting that sounds like your office, scheduling that repairs itself — each of them needs a source of truth about what your firm actually does. Build those first and you get software that is confident and wrong. The order is not arbitrary.
Writing it down will start an argument, and that is the point
Here is the part worth saying plainly, because you will hit it in the first hour.
Writing your rules down is work, and it will surface disagreements your firm does not know it has. Two managers who were both certain they had the same pet policy will discover, in writing, that they do not. Somebody will insist the notice period is one thing and be shown four signed leases saying another.
That disagreement is not created by the exercise. It already exists, and it is currently being resolved differently depending on who picks up the phone. The pack surfaces it once, in a room, with the people who can settle it — instead of continuously, in front of applicants, for years.
What the pack will never do
It will not decide anything about a person.
Your screening criteria do gate. An applicant who does not meet them will not reach your calendar, and that is exactly what they are for. But those criteria are yours — you write them, and the pack is where they will be written down. The software enforces your rule. It does not form a view of its own about an applicant, it is not being built to, and the pack is the source it answers from, never a judgment it makes.
When your pack is silent on a question, the correct behaviour is not to improvise a plausible answer. It is to hand the question to a person. We would rather the software say less than have it speak without a source, and we are designing it so it cannot.
We hold this line everywhere in this product, and you will see us keep saying it. Software does the collecting, the sorting, the remembering and the tedious parts. Judgments about people stay with you.
A pack that has gone stale will say so
The failure nobody plans for is not a badly written pack. It is a good one that stopped being true.
The firm changes its approach in March; the pack still describes January. Software then states, confidently and in writing, a policy the firm no longer has — and it does so to strangers, at scale, in your name. That is the worst outcome available here and it arrives quietly.
So every pack will have a named owner and a review date. Past that date, it steps back on policy questions and routes them to a person, while continuing to do the things that do not depend on stale authority — confirming a booking, sending a reminder. That is not a penalty for being late. It is the right behaviour for a document that has not been confirmed recently, and we would rather build it in from the start than add it after the first time it matters.
Releaser is available to property management firms in the United States and Canada today: one shareable link per property, your screening completed before anyone reaches your calendar, and self-serve booking for the people who meet the criteria you set.
The Policy Pack is in design. This is what we are building it to be.