Making every page fast and private

Plan for the page-speed and company-separation work: every page loads only your company's data, straight from the database, a page at a time, and nobody at one company can ever see another's.

22 Sep 2026 · DRAFT — waiting for Gera's approval · reviewed by two separate AI reviewers (Opus and Fable)

The one decision needed now

Approve this plan?

Yes, start (recommended): it first fixes the vendor data leak, then finishes the prospects speed-up. Anything that touches your live database still comes back to you first.

Change something: tell me which step to add, drop or reorder.

Where each page stands today

Checked against the actual code, not from memory. “Tested” means a test fails if the page ever starts reading another company's data.

Page	Only your data	Tested	Loads a page at a time	Needs a new database index?
Prospects	Yes	No	Fix waiting	Already has one
Tenants	Yes	Yes	No	No: small enough to sort in memory
Properties	Yes	No	No	No: short list
Turnovers	Yes	No	No	Yes: grows forever, stored in random order
Work orders	Yes	Yes	No	Yes: grows forever
Tours / calendar	Yes	No	No	Yes: it asks for a date range
Conversations	No	No	No	Built, switched off: needs you
Vendors	Fix waiting	Fix waiting	No	Later

What the traffic data changed

The first draft was aimed at the wrong pages. Page-view data we already collect (59 days) shows:

Your busiest page is the dashboard: 1,644 views, used by 19 companies, more than any other page. Its data request takes about 3.2 seconds typically, and has recently been closer to 9 seconds. It was not in the first draft at all.
The leasing hub and prospects use the same slow stats request, so fixing it speeds up three of the top pages at once.
The pages the first draft focused on (turnovers, tours, calendar, properties, tenants) are among the least-opened: a few hundred views between them in two months.
Caveat: 93% of page views come from our own team, so this says more about internal use than about customers.

The plan, in order

Fix the vendor data leak. A safety fix, not a speed one, so it stays first. A manager at one company, opening a vendor shared with other companies, can see that vendor's jobs for your other customers. The fix is written; one of its tests is accidentally calling the real database.
Measure why the dashboard is slow, before changing it. Some of last month's slowdown may have come from our own recent changes. Compare the old and new code side by side and count the database round trips. That tells us whether it's the code, the data or the platform.
Speed up the dashboard and the shared stats request. The fix follows what step 2 finds. One fix, three of your top pages faster.
Finish the prospects speed-up. Your #2 page. Loads the first 100 leads instead of all of them. Two known fixes, plus a screenshot before it ships.
Decide what a conversation is, then the conversations index.needs you Your #4 page. The index is built and switched off, but switching it on today would fill it with chats filed under buildings, the shape behind the Western Slope duplicates. Settle “one conversation per person per company” first (see the section below); nothing is built until you answer.
Stop pages loading every company's building list. One small change on three pages, copying what already works on renewals.
Build one shared testing tool, then add tests for properties, calendar and turnovers, so “only your data” is proven, not assumed.
Design indexes for work orders, tours and turnovers.needs you Lower priority now: these pages get little traffic. A written proposal only; nothing is created.

Is the data model right? The Western Slope question

Raised in the 21 Sep standup: one Western Slope prospect became four conversations, the match on a street address failed, and the wrong fee was quoted. Western Slope has one shared phone number across many homes, and prospects ask about several homes in one chat.

Should we key things on phone number or email? No, and we already decided that. Keying on phone number was the old model, and it broke: people change numbers and lose their history, and one human became two records. Since May, each human is one person record, and a phone, an email or an AppFolio ID is just a way of finding that person. The number someone dialled isn't a person either (one callbox line carries dozens of callers). It records which door a message came through, which points to a company or a building.

The idea that untangles it: every message answers three separate questions. Who is it (the person)? Which door did they use (a line or inbox, pointing to a company or building)? And what is it about (a home, a lease, a repair)? At a one-building customer all three answers are “that building”, so filing everything under the building worked. With one door and many buildings, it doesn't.

Record	Filed under today	Right?
Prospect / lead	The person, with a company-wide list for the page	Yes and since this morning a lead keeps every home discussed
Tenant	The building, linked to the person	Yes a lease is at a building
Work order, turnover, tour	The building	Yes they're about a unit
Conversation	The building	No the one person-level record still filed under a building

August's “one conversation per person” work grouped chats on screen, but still per building, so the flaw stayed underneath.

What it looks like for Western Slope

Western Slope has five buildings sharing one phone number. Today, a prospect who asks about three of them gets three conversations, one per building. After the change they get one conversation, filed under the person at Western Slope, with the buildings shown as tags (“asked about: Building 1, Building 3, Building 5”). Every building they mention is added to the list.

What a “building” and a “phone line” are

Company, building and phone line or inbox are three separate records, each with its own permanent ID. A building belongs to a company and comes from the customer's property system.
A phone line points to one building or to the whole company. Camellia's number means one building. Western Slope's shared number just means “Western Slope”. We don't need the line to pick a building, because the conversation is no longer filed under one.
Each message records which line it came in on. The line is never used as the building.

What changes and what doesn't

Rule of thumb: a record about a building stays under the building; talking to a person goes under the person and company.

Record	Filed under	Changes?
Tenants	Building (a lease is for a unit)	No
Work orders	Building (a repair is in a unit)	No
Renewals	Building (renewing one lease)	No
Turnovers, tours	Building (one unit)	No
Prospects / leads	Already the person, with a list of homes	No (check: four homes asked about = one lead, not four)
Conversations	Building → person + company	Yes, the only change

Work orders, renewals and leads already point to their conversation by its ID, and that link doesn't change: several of them can point to the same conversation. A resident at Building A with a leak, who also asks about a bigger unit at Building B, has one conversation. It shows the repair (filed under A), the renewal (A) and the new inquiry (B). Building pages look exactly as they do today. If the same person also rents from a different company, that's a separate conversation, and neither company sees the other's.

The order it would be built in

You and Fede decide (b90034167). Nothing is built before that.
New messages go into one conversation per person per company. We find the person by phone or email and record which line they used. Tested first with real messages on a test company, because Clara replies through this path.
Conversations keep a list of the homes discussed, so Clara quotes the right home's fees instead of guessing from a street address.
Merge the existing duplicate conversations (this changes live data, so it comes to you first), then switch on the conversations speed-up.

Proposal (a draft for you and Fede to test, not decided): a conversation belongs to one person at one company. The line or inbox is recorded on each message, and buildings become a list on the conversation, the way leads now carry a list of homes. It's per company, not global, so one company never sees another's chats, and it fits the conversations index, which is already split by company.

Your call: this is already on your decisions page as b90034167 (“OK to build one conversation per person per company?”). Answering it there is the ruling. It touches Clara's live messaging, so bring Fede in.

How the new database layouts would work

The pattern, already live on the prospects page. Every row gets two extra labels: whose data it is and the order the page shows it in. The database can then hand back “this company's newest 50” in one step, instead of us loading everything and sorting it ourselves. The cost follows what's on screen, not how much is stored.

Page	Status	Group label	Order label
Prospects	live	`PLIST#<organizationId>`	`<lastActivityAt>#<inquiryId>`
Conversations	built, off	`CLIST#<organizationId>`	`<last activity>#<conversationId>`
Tenants	no index needed	`PROPERTY#<propertyId>`	`OCCUPANCY#<id>`, sorted in memory
Properties	no index needed	`PROPORG#<organizationId>`	`PROP#<propertyId>`
Work orders	needs one	today `PROP#<propertyId>`	today `WO#<PMS id>`: not a date
Tours / calendar	needs one	today `PROP#<propertyId>`	today `TOUR#<id>`: random order
Turnovers	needs one	today `PROP#<propertyId>`	today `TURNOVER#<id>`: random order

For the last three, the candidate follows the prospects shape: company or building as the group label, a real date (last updated, tour start, move-out) as the order label. Final field names are part of the design step, not decided here.

The choices that make or break each one

Learned the hard way on prospects:

Which date is “the” date. A work order has created, scheduled and completed times. The page has to pick one on purpose, because it decides what “newest” means.
Dates stored in one consistent format. Mixed formats sort in the wrong order, and nothing complains.
Grouped by company or by building. Prospects is grouped by company, which turned out to cost a manager who looks after only some buildings extra reads, and sometimes gives them short pages. This is a real trade-off to decide page by page.
The sort label only ever moves forward. An old copy of a record being saved again must not push it back down the list.
Nothing personal in the labels. No names, phone numbers or emails. That's why the tenants page is not getting one: it's small enough to sort in memory, so resident names never go into a database label.
Records missing the needed date are left out and counted, never given an invented date.

Two decisions that can wait

Turn on the conversations index. Adds an index to the live database and fills it from existing records. It can be undone, and the same thing was done safely once before for prospects. My lean: yes, but only after the “what is a conversation” decision above, so it is filled once, with the right shape.
How your staff account should see tenants. Your account currently loads every company's residents. Making you pick a company first sounds simple, but it would change what regular managers see and break a picker on the create-work-order screen, so this is a product choice, not a quick fix. My lean: revisit once paging is in.

What the reviews corrected

Mistakes caught before any work started:

My diagnosis of the vendor fix was wrong: I took a checker's generic error message as the specific cause. The real problem is in a different place.
I had turnovers marked as tested. It isn't: the test covered a small widget, not the list.
The first reviewer thought turnovers needed no index. It does.
There is no way yet to measure page speed in production; the read counter only works on a developer's machine. We need to build that before we can show you a page got faster.

Full working notes: ~/.claude/jobs/loop/1fdb267c/PLAN-DRAFT-2026-09-22.md · Handoff: HANDOFF-2026-09-22-1700Z.md