Skip to content

Communities · Engineering · 2026–present · Shipped

A building record that stays with the building

84 Prescott

A privacy-conscious resident application combining a navigable building model, issue history, practical building information and optional neighbor coordination.

A phone screen: the Building tab of the 84 Prescott app. A 3D model of a four-storey brick courtyard building under a row of floor buttons, a neighbour's offer of a ladder above it, two issue pins on the roof, and an Apartments sheet folded at the bottom.The same model with apartment 32 chosen: a wireframe lights the apartment on the third floor, and the sheet below reads Apartment 32, Your apartment, Floor 3, South Wing, 1 unresolved issue, Fix reported, with Manage my apartment and Room planner buttons.
Fig. 1 — The Building tab, then apartment 32 chosen, captured from the app on 23 October 2026 on a local run with made-up households (Maya, Daniel, Priya). Own captures; nothing from the live building.
SCHEMATIC BUILDING · UNIT 3B SELECTED (FICTIONAL)MAR 2026 · RESIDENT (3B)Reported: radiator cold since FridayMAR 2026 · MANAGEMENTAcknowledged · plumber bookedAPR 2026 · PLUMBERValve replaced · photo attachedSEP 2026 · NEW RESIDENT (3B)Read the history before the first cold week
Fig. 1 — Schematic stand-in on fictional data: a building as a stack of floors, one unit selected, and the issue history that stays attached to it across residents. The real 3D capture from the app replaces the building once reviewed. No real residents, units or records are shown in any tier.
Role
Independent product design and development
Years
2026–present
Project status
Shipped
Categories
Communities · Engineering
Navigable 3D building model and apartment selector
Live
Issue lifecycle with evidence and provenance
Live
Rules, rights and the printed record
Live · legal read pending
Optional neighbour coordination
Live
Privacy rules (no accounts, author severed, no occupancy inference)
Implemented · enforced by tests
Resident adoption
Early · one building · not measured

04Situation

Buildings accumulate a shared history, but the people living in them often have only fragments of it: who reported a maintenance problem, what management said, whether it was fixed, and how past residents solved everyday problems. I built a resident-owned interface around the building itself so that knowledge can outlast turnover without turning neighbors into a directory they never agreed to join.

The failure this answers is ordinary. A building's residents start a group chat; it fills with useful things — which valve sticks, which contractor management uses, how the heating behaved last winter — and then the people who knew those things move out, the chat is archived, and the next resident starts from nothing. The knowledge belonged to the building, but it lived in a tool that belonged to whoever happened to be there.

For this building the problem is heat, and heat is where a record matters most. Massachusetts requires 68°F by day and 64°F at night through the heating season, and no room hotter than 78°F. [S36] Once the city orders a repair for a condition on the sanitary code's urgent list, the owner must make a good-faith start within 24 hours rather than 30 days. [S36] Cambridge's housing inspectors take heat complaints by phone and no online form exists. [S37] A tenant who calls arrives with whatever they can remember. The app exists so that they arrive with dates.

05Research

The research was one building and the people in it, which is both the strength and the limit of this project. [I07] Three observations shaped the design:

  1. The building is the natural index. People do not remember issues by date or ticket number; they remember where. "The radiator in the back bedroom" is a location first and a problem second, so the interface starts from a model of the building and lets you walk into an apartment.
  2. Provenance is what makes a record trustworthy. A note that says "management said it's fixed" is only useful if you know who heard it, when, and what evidence exists — a reading, a photo, a dated notice. The app keeps management's word as management's word and lets only the household that had the problem say it is over.
  3. A directory is a liability. Residents will share what helps the building; they will not sign up to be listed. Every record is about a place. Who has joined an apartment is shown only to the people in it; a directory listing, a pet, a move-out date and a rent figure each appear to neighbours only when the household chooses to show them, one at a time.

A fourth finding came from checking the brief itself. The plan began by testing its legal claims against the regulation, and found that the heating season is not a fixed date: the state default runs 15 September to 31 May, and a city's board of health may adjust it for one year at a time, which Cambridge did in 2026. [S36][S38] So no rule in the app is a constant. Each is a record with a citation, a source and the date someone read it, and a test fails the day a rule passes its expiry. [I07]

The join screen: the heading Which apartment do you live in?, a note that this one-time setup link is for the building's first resident, the 3D model cut open at the third floor with apartment 32 highlighted, and a grid of both wings' apartments below.
Fig. 2 — Joining: one screen, no email, phone number or password. The phone makes a key that never leaves it; a passkey carries the resident to another phone. Synthetic households; own capture, 23 October 2026.
The Apartments sheet: a search field, both wings' apartments as a grid, apartment 42 marked as yours, 32 with a dashed edge for a fix reported, 33 with a dot for an unresolved issue and figures for listed residents, then a key and the shared spaces.
Fig. 3 — Every apartment, and only what each chose to show: a dot for an open issue, a dashed edge where management reports a fix, a figure where someone has a listing, nothing where there is nothing. Synthetic households; own capture.

06Design decisions

The building is the interface, not a feed. The app's front door is a 3D model of Bromley Court, 84 Prescott Street, built 1909: four floors of seven apartments in two wings and one more in the basement, 29 in all. The model is traced from the 1909 floor plate, then corrected from residents' photographs and answers, and the drawings and the walls disagree often enough that every part of the model carries a note of its source — plan, photograph, resident's answer, or assumed — and a part is done only when nothing in its row is assumed. [I07] Choose a floor, drag to turn, tap an apartment and the model frames it and shows what residents recorded there. No report means no data, never a verified absence of problems.

Reporting is shaped by the sanitary code. Twelve categories, each with a few questions, checked against the state code. An answer on the code's list of conditions that always endanger health marks the issue Urgent and says why. [S36] A heat report asks for a thermometer reading and tells the reporter where the code wants it taken: five feet above the floor, on a wall more than five feet from an outside wall. [S36] Before anything is sent, the app offers up to three open issues like it nearby — worked out on the phone from issues the reporter can already see — so one leak does not become three reports. The reporter chooses whether the report shows at their apartment, their floor, their wing or the building.

The Report an issue screen with Heating & hot water chosen: rows of choices under Since when (Today, A few days, A week or more), Radiators (Cold, Lukewarm, Some warm some cold, Warm but room still cold, Too hot), Radiator noise, and Hot water.
Fig. 4 — Report, with Heating & hot water chosen. The answers, not a typed title, become the issue's headline, so a history reads the same across households. Own capture.

Management's word is recorded as management's word. Each issue shows four steps: Reported, Management acknowledged, Fix reported, Fixed. A fix management reports reads "Fix reported"; only a household that had the problem can confirm it, say it isn't, or later say it came back, and the app asks them. A reading is judged against the rule for its hour and the screen says "may not meet the requirement", never "violation". Timeline entries are only ever added: whoever added one can take it back from the phone they added it with, and it stays, struck through, and stops counting; anyone else can say an entry is wrong, which is shown beside it. What the page and the printout conclude about management and the city reads only the entries that stand.

The Issues list: Unresolved 3 and Closed 0, filters for All locations, My floor and My apartment, then three rows: Mice, Pests, Basement, Urgent; Leak, Plumbing & leaks, Apt. 33; Not enough heat, Heating & hot water, Apt. 32, Urgent, Fix reported, 2 households. A Related issues row follows.
Fig. 5 — Issues: status, place, when it last changed, and a heart for how many households have it. Related issues groups the third heat outage of a winter with the first two without merging them. Synthetic data; own capture.
An issue page, Not enough heat: Apt. 32, 2 households, yours included. A card asks Management says this is fixed. Is it? with Yes, it's fixed and No, still a problem. Below, four steps with the first three filled, a Follow button, and Management and follow-up with the repair deadline under the code.
Fig. 6 — One issue: the question the household is asked after management reports a fix, the four steps, and the deadline block that says what the code requires and from when. Synthetic data; own capture.

Records about places, severed from people. The design assumes a hostile member in every building: an owner-occupier, or a friend of the landlord with the lobby code. So there are no accounts and no roles. Identity is a key on the phone; management is a contact, not a login; nothing on the server can be made to hand over a list of residents. A report keeps its author for 48 hours, long enough to withdraw it, and then belongs to the building; which households confirmed something is kept as keyed hashes that can be counted but not listed. A report the reporter did not pin to their apartment shows on their floor only if the floor has enough apartments to hide one household, and otherwise at the building. Whether an apartment is lived in is not recorded at all. Anything that looks like a door code is refused in every text field. And "I want to know" is plain word search over the building's own records, with sources; no model ranks, summarises or writes a field. [I07]

Rules as reviewed data. Under More, Tenant rights & building rules holds the code on heat, hot water and pests, the correction deadlines, the statutes on services, reprisal and late fees, the lead law, Cambridge's heating season and the terms of this building's lease, each in plain words with its citation, source and read-by date. [S36] Association letters cite issues by their record, and a draft that mentions gas or smoke gets the emergency line first. The page says it is information, not legal advice, and names the city's free help. [S37]

Tenant rights & building rules: a note that this is information about the law and the lease, not legal advice, naming Cambridge's Housing Services Center; then How to report a repair issue as numbered steps: document the problem with readings five feet above the floor; notify management in writing.
Fig. 7 — Rights: each rule with its citation, its source and the date someone read it. A rule past its read-by date fails a test. Own capture.

What was deliberately not built: a feed, a chat (discussion stays in the building's group chat, which the app links to and never reads), ratings of neighbours, and any text a model writes. The alternative to all of this — a building directory populated from the records — was rejected at the start, and the decision records say why. [I07]

07Artifact

The app as deployed has four places on a tab bar — Building, Issues, Community, More — and every screen is built from the same few parts: a back link, tappable rows, one main action, and times as people say them. [I07][I20]

  • The building model and apartment selector, with each apartment's own page: household, lease and rent, directory listing, room planner, visible only to the people in it.
  • Issues, with the lifecycle above, readings judged against the rule, photos stripped of metadata twice and served only to confirmed residents, and a printed record and CSV for the inspector.
  • Practical building information: the resident guide, which keeps every version; building contacts with a source and a last-checked date; a maintenance calendar; building updates.
  • Optional neighbour coordination, strictly opt-in: a directory, requests and offers about shared places that expire on their own and never show who posted, noise notes that go to an apartment with no name on them, and a room planner whose furniture shows in the building model for everyone while who lives there never does.
  • A view-only link for people outside the building — an inspector, an advocate, a reporter — that shows categories, floors, statuses, counts and dates, and never a name, apartment, message or photo.
The 84 Prescott app on its demo building, phone-sized: under the masthead a yellow line reads Demo building, everyone in it is made up, changes you make stay on this device for about an hour; below it a neighbour's request to borrow a drill, the floor buttons, a button for apartment 27, and the 3D model of the brick courtyard building with two issue pins on its roof.

Open in a new tab

Fig. 8 — The app itself, on a demo building: the same code, built to run entirely in your browser with no server behind it. Fifteen invented households, a winter of heat issues with their repairs and disputes, neighbours' posts, and apartment 27, furnished, which is yours for the visit. What you change stays in this browser for about an hour, and nothing in it comes from or reaches the live building. Opens on request; nothing loads until you ask.
The Community tab: Invite neighbors; Requests & offers with Extension ladder to borrow, Offer, posted 11 minutes ago; the Directory with Maya (you) and Priya listed with 555 phone numbers and WhatsApp links, Daniel listed with his apartment only; Noise notes.
Fig. 9 — Community: the directory with your own listing first, a neighbour's offer, and noise notes. Names and numbers are invented. Own capture.
The Room planner: apartment 32 as a small 3D model with Living room, Dining room, Kitchen and Bedroom labelled and furniture placed; buttons for Other side and From above; the word Saved; a catalogue row of Rug, Sofa, Sectional, Armchair.
Fig. 10 — Room planner on the phone, apartment 32 with its basic furniture. Figs. 11–14 show apartment 27 furnished in full. Own capture.
A close-up of the room planner's drawing of apartment 27 with the living room in front: maple floor, white walls, a green sofa against the long wall with a striped rug and a coffee table before it, a TV stand facing it, a yellow armchair by the fireplace, a lamp and a plant; the hall, the tiled kitchen and bathroom, and the bedroom behind.
Fig. 11 — Looking into apartment 27's living room, furnished by the planner's own “Add basic furniture”: a sofa against the longest wall with a rug and a coffee table, the TV stand facing it, an armchair, a lamp and a plant, each only where it fits. Walls stand at the back and are cut low in front; the household's listed pets are drawn in it and never stored. Invented household (Noor); own capture.
The planner focused on apartment 27's bedroom: a queen bed against the wall with a nightstand and lamp at its head, a dresser along the far wall, maple floor and white walls, three windows; the bathroom, kitchen and living room beyond.
Fig. 12 — The bedroom on its own: a bed against the wall with a nightstand at its head and a dresser, as the planner places them. Every piece can be moved, turned a quarter at a time or removed; things hung on a wall slide along it and never over a door or window. Own capture.
The same apartment drawn straight down from above as a plan: living room, kitchen, hall, bathroom and bedroom labelled, each with its floor finish and furniture.
Fig. 13 — From above: the same drawing as a plan, every room labelled, from the same data as the building model. Own capture.
The building model cut open at the second floor: apartment 27 is lit in teal among its neighbours' empty rooms, and inside it the sofa, rug, bed and plants from the planner are drawn in the model's shaded style, with labels Biscuit and Pistachio where the two pets sit.
Fig. 14 — What a household places is drawn in the building model for every resident: floor 2 cut open, apartment 27 chosen, its furniture and pets inside. Who lives there is never shown; the other apartments read as nothing because nothing was placed. Own capture.
A printed page: Heating & hot water, Oct 23 2026 to now, 1 issue. A record kept by residents of 84 Prescott Street, Cambridge, MA, printed Oct 23 2026. It is not an official finding. Then Not enough heat, Apt. 32, with four dated entries from Contacted management by email to Fix reported, and under Readings, 61°F, reading below the minimum.
Fig. 15 — The printed record for one category: each issue on its own page, dated entries, each reading with its verdict, no names, notes or photos. Synthetic data; own capture of the print view.
The view-only page on a desktop: What residents of 84 Prescott St. are doing in the app, as it stands now. Apartments with residents in the app 3 of 29, Unresolved issues 2, Closed issues 1, Offers posted now 1, then an issue list by category and floor.
Fig. 16 — The view-only link, as an inspector or an advocate would see it: counts, categories, floors, statuses and dates, nothing that names anyone. Synthetic data; own capture.

How it was built matters as much as what: the brief arrived on 18 October 2026 and the building was live the next day, and what kept speed from turning into drift was a small set of rules the code enforces. [I07] Every choice that would be expensive to work out again is a dated decision record, never edited once accepted (148 of them). Thirteen invariants — a sensitive field travelling with an apartment, a report still naming its author after two days, a rule past its read-by date — are each a failing test, not a code-review comment. Every word a resident reads follows one style sheet, and tests catch the banned words. The whole gate, typecheck, 786 tests and the production build, runs before anything is pushed.

08Outcomes

The app has been live at one building in Cambridge since 19 October 2026, with the public front page and the city's contacts open to anyone and the records held for residents. [I20] Residents' answers and photographs have been correcting the model since the first week, and several of the app's rules were changed at their word. [I07] Tenant advocacy groups in Cambridge have begun using it and giving feedback on what the next versions should do; that is my account as of October 2026, and this page keeps no usage figures because the app records none.

What the page does not claim: that residents will keep using it through a winter, that a landlord has fixed anything faster because of it, or that the record has yet been put in front of an inspector. When any of those happens it will be reported here with its own evidence. The measure the design aims at is simple: a resident arrives at the housing inspector with a dated record, readings against the rule, and the day the clock started.

Next, in the plan's order: evidence packets with hashes and signatures, stewards, organising held apart from the building's records, rent history that pools across buildings, sensors, and more than one building.

What is not and will not be on this site, in any tier: real residents, who lives in which unit, rent or lease records, or how anyone gets into the building.

09Reflection

84 Prescott is the smallest-scale institution I have designed for, and it has the same shape as the largest: knowledge that should belong to the group keeps ending up in tools that belong to individuals, and the fix is a structure with explicit rules about who may see what. The privacy constraint was not a burden on the design; it was the design, and writing each rule down as a test turned out to be the fastest way to build, not the slowest.

It also closes a loop with the Ford work. The charger was the handshake between a car and a home; this is the record a home keeps of itself.

References & documentation

  1. 1. I07
    Private `sureshot125/84prescott` README and ADRs — 3D model, records, privacy constraints and product screensfirst-party

    First-party code; not proof of adoption

  2. 2. I20
    84 Prescott, the deployed app at 84prescott.pods.boston: public front page and the view-only page, read 2026-10-23 — Shows the app live: the building model, the three things residents can do, the join flow (lobby code or a neighbour's link, no email or password), the city's sourced contacts with last-checked dates, and the privacy statement. Vercel project created 19 October 2026 and the pods.boston domain attached the same evening.first-party

    First-party deployment; proves the app is running, not that residents use it. Everything past the front page is residents-only and was not read. Captures on the page come from a local run on synthetic households, never from this deployment.

  3. 3. S36
    105 CMR 410.000, Minimum Standards of Fitness for Human Habitation (State Sanitary Code, Chapter II), as published by Cornell LII: 410.180 heat, 410.630 conditions deemed to endanger health, 410.640 correction deadlines — 68°F by day and 64°F at night in habitable rooms, no room above 78°F, the heating season of 15 September to 31 May with a board of health's one-year adjustment, and the measuring rule (five feet above the floor, more than five feet from an exterior wall) in 410.180; the list of conditions that always endanger health in 410.630(A); a good-faith start within 24 hours for those and 30 days otherwise in 410.640.

    The app cites the same sections from the same mirror (building/rules.ts, read 2026-10-19). Re-check the text against mass.gov at publication; the 2023 code revision renumbered some sections.

  4. 4. S37
    City of Cambridge, Inspectional Services Department, Housing Division page — To request an inspection, residents call 617-349-6100 and ask for the Housing Inspector for their area; names heat, hot water, plumbing, blocked exits and rodents among the commonest complaints. No online form.

    Public page; confirms the route a tenant takes, not anything about this building. Phone number re-checked at publication.

  5. 5. S38
    City of Cambridge, Inspectional Services news: heating season changed for 2026 — Cambridge's one-year change to the 2026 heating season (ended 18 May, resumed 30 September), which the city said applies to 2026 only and needs a fresh determination each year.

    Supports the design point that heating-season dates are not constants. The notice's own text, not the app's summary of it, governs at publication.