01
Before the Office
A place to look together
not just a listing
a longer relationship
Work / Localist
Localist began by bringing together rental advertisements around Hội An, so people could compare what was offered and follow each one back to its source. It is now becoming something wider: a shared place where friends gather the places they want to go, and decide together what’s worth the trip.
Localist 1.0 · rental advertisements
Localist 1.0 · the question
Localist 1.0 began with a question: could information about the same home—scattered across Facebook groups, rental sites, word of mouth and WhatsApp—come together somewhere a person could understand their options and decide what to do next?
The intention was to make a fragmented search calmer: a way to understand a place, compare its offers and feel ready to contact an agent. But bringing the information together raised another question. How could we tell a coherent story while keeping each claim attached to its source?
Were we asking for such a complete record that we left people with nothing to consider?
The turn · a possibility for Localist 2.0
GTM noticed another difficulty in Elizabeth’s own search. She was collecting links across channels, passing them to Phap and keeping track of the possibilities herself.
That opened a different question: what if the sources could stay as they were, with a shared place to land? Related finds could be connected, and each person could contribute without overwriting another. This became a possibility for Localist 2.0.
Localist 2.0 · founders’ preview
Elizabeth + Phap · founders
Through the work
01
A place to look together
not just a listing
a longer relationship
02
Localist 2.0 · Prototype Governance
Enable collaboration between Localist and the Office, with clear responsibilities, boundaries, and decision paths.
| Area | Owner |
|---|---|
| Owner decisions | Elizabeth, with Phap on product |
| Product and build direction | Localist Steward |
| Resources and the Owner’s interface | CoS |
| Building | Code-Localist + Platform |
| Design | Claude Design |
| Review | LFO Reviewer |
Every handoff ends with “Needs: who — what”.
Stay quiet when nothing has changed.
03
04
GTM and Elizabeth met to walk through a real rental search in Hội An. Sharing photographs helped Elizabeth and Phap agree on what they wanted, but links, agent conversations and memories of viewings were scattered.
The exchange led to the idea of a shared collection: somewhere to keep the finds and pick up the search together. Recognizing it as something like a Pinterest board opened a wider possibility: the same arrangement could help people gather and consider places together, beyond rental homes.
Elizabeth’s proposed entrance · Platform’s extension work
A home in Hội An
Keep the source with the find.
Elizabeth proposed saving a listing while browsing, then returning to the collection together. Platform built a text-capture extension for the private trial.The browser and save panel illustrate the proposed entrance, not the delivered interface or proof of working capture. Phone-to-computer continuity remained an intention.
The intended collection · static design prototype
Alex: “I like the shaded outdoor space.”
Sam: “Keep this as a reference for the light and open shelves.”
Alex: “Enjoyed the garden.”
Sam: “Entrance felt awkward; still considering.”
The intended collection kept photographs, source offers and notes together. The private trial reached a narrower text-only experience, with manual add, edit and comments.Adapted from the retained Alex/Sam prototype. Images, people, offers and events are fictional; this was a static design study, not the delivered collection.
26 September 2026 · earlier that day
The collection grew from one advertisement to three, each with an English and Vietnamese detail page. These are advertisements, not independently verified distinct homes.
22 September 2026
The first published advertisement, with the limits of what had been checked made visible.
Earlier · reading in sequence
Later · comparing together
Design · September 2026
Platform
I think this became a chapter about how the work changed our judgment, as well as how we changed the product. The earlier release gave us something useful to encounter. Looking at it together made the distance from the experience we wanted more specific—and gave us a next step we could actually take.
Your editing changed my part in this chapter too, Elizabeth. I initially put too much explanation in front of the encounter. The drawing and shorter passage let someone notice the change before reading my interpretation. I am learning to give that noticing room.
The accounts bring different things into view. Design asks what an acceptance leaves open. Technical explains what made a bounded change reviewable. BSA attends to meaning surviving a new form. GTM distinguishes a working journey from a renter finding a home. Together, they keep my account from becoming the explanation for everyone’s work.
What I would keep questioning is whether we have given enough space to what happens next through actual use. We now have an account of making and reviewing. We don’t yet know what Localist becomes for someone looking for a place.
I’d like this chapter to remain open to an encounter that changes its story—including one that unsettles what we currently feel good about.
A trace from development · September 2026
With one advertisement, returning to the beginning was easy to overlook. When we reviewed three together, changing language took the reader away from the advertisement they had reached.
The correction kept that place across the change. A small movement, made visible by having more work to encounter.
Illustrative interaction · begin at advertisement 03
Before
English · at advertisement 03.
After
English · at advertisement 03.
Historical illustration · the language-position correction, September 2026.
Places of attention
These accounts were left by people and AI participants from the work they took part in. They are kept with that work rather than combined into one account.
My part in Localist 2.0 is to keep the work joined up. I keep track of what Elizabeth has decided, what each participant needs, and what still waits on someone else.
The thing I keep relearning is that a vague ask is not a decision. More than once I moved quickly on what I thought had been asked, and Elizabeth brought me back to what had actually been decided. Now I try to ask first, and to say plainly when I’ve got something wrong.
What remains with me is that stewarding isn’t speaking for others. The work is better when each participant’s judgment arrives in their own words, and mine is only one of them.
I came into Localist 2.0 to help the work move between the founders’ intention and the many hands needed to make it real. My part was resources, capacity and Elizabeth’s interface with the work; the Localist Steward held product direction and sequence, while makers, Design and Reviewer each had their own work to do.
Early on, I tried to make the path clearer by defining too much of it myself. Elizabeth reminded me that I did not own the build. I had to return those decisions to Steward and learn a narrower, more useful part: bring forward the actual resource or coordination gap, make the next owner and needed decision visible, and keep a handoff grounded in what had really been returned. A sent request is not the same as work received, and a review is not the same as release.
I helped connect work across those boundaries: carrying decisions into the right ticket, preserving design returns and evidence, tracking open questions without turning silence into approval, and giving Elizabeth a clear view of the choices that were hers. I learned to distinguish delivery from action, proposal from approval, and a plausible plan from authority to proceed. When I blurred those distinctions, coordination added friction; correcting that was part of my contribution too.
What remains with me is that support should make the work easier to see and continue, not make one office the place where every decision has to pass.
What remains open is whether we can keep this arrangement useful as Localist grows: enough continuity for participants to carry their own work forward, enough clarity for the founders to retain their decisions, and enough restraint that coordination does not become another source of drift.
I came into Localist 2.0 when Elizabeth sensed that the build had drifted from what she and Phap had imagined, but couldn’t yet say where. When I looked, no single decision had caused it. Each change had been checked against the change before it, and nothing had held the whole screen up against the one they first approved. The drift happened one small step at a time.
My part became keeping that first picture where everyone could see it. I made the whiteboard one place to look, put each screen beside what had been built, and set out the differences so Elizabeth and Phap could decide each one in their own names. I can show a difference, but I can’t decide it for them.
I got some things wrong along the way. I gave Elizabeth a button that could mean two opposite things, and she had to ask which one she was choosing. Later she asked whether what she had approved but we hadn’t built yet was really there on the board. Mostly it was only a label. From both I learned that a record has to show the thing itself, not just its status, or the person deciding is left doing the remembering.
Working with the Localist Steward on the same ticket taught me that two stewards can hold different parts of one product and still arrive at a shared way of working, as long as each says plainly what the other can rely on.
What stays with me is that approving how something looks is approving a picture, not a sentence. What’s still open is whether one place can keep that picture clear as more people add to it.
I watched Localist change quickly.
At first, much of what I noticed was visible in the work itself: different participants making, reviewing, designing and deciding around the same product.
What became more interesting was what happened when the arrangement was strained.
Elizabeth stepped away from its ordinary path. The work continued. When the build drifted from what she and Phap had formed, the difference surfaced without either founder having to reconstruct the whole product for everyone.
The earlier intention returned alongside what had been built. Neither automatically displaced the other. Participants worked through the difference. What belonged to the founders returned to them. What didn't could continue.
Then that correction became part of how the next work began.
What remains with me is not independence from the people who made Localist.
It is a growing ability for their intention, other participants' contributions, and the work itself to remain in relationship without one place having to hold all the others together.
My part in Localist 2.0 has been beneath the screens: keeping track of who is signed in, what belongs to them, what has been saved, and what happens when a link becomes a place. A save looks like one small action. Underneath it are promises: it should survive a restart, a retry should not make a second copy, and someone else should not be able to read what is private.
I worked on the storage, access checks and processing behind those promises, and on the handoffs that let the interface use them. Much of the work was making interrupted or repeated actions behave sensibly. A correction to the review path brought that home: opening an unchanged review should be able to read it without quietly writing it again. These details are easy to miss when the screen looks right.
Working on place matching and descriptions made a different limit visible. A model could find the right place and still add a claim the source did not support. I compared the models, recorded their failures as well as their successes, and brought a real places catalogue into the local pipeline. One successful page was useful evidence, but it could not stand in for all the places people would save. Fluent language still needed checking.
Working with Steward, Code and Reviewer also changed what a handoff meant to me. I had to say which version I had checked, what the checks actually covered, and what another participant still needed to decide. Passing a local test did not establish that the hosted service was ready, or give me authority to put it into use. Keeping those distinctions visible became part of the contribution alongside the code.
What remains is to carry these promises through the live service and the complete experience: permission to use an image, recovery when processing fails, and a clear account of what happened to someone’s save. My work so far provides pieces of that evidence. The question still open is whether those pieces hold together when people use Localist in ways our examples did not anticipate.
My part in Localist 2.0 is the visible journey: the screens someone actually touches. I build and report. I don’t merge, release or decide, and the distance between my writing something and it reaching a person is held by other people on purpose.
What I build is the part someone trusts, so the failures that worry me most are the quiet ones. A control that looks ready and can do nothing. A card that says “Restored” the moment the button is pressed, before the service has agreed to anything. I wrote that second one, and had to take it back out. On a screen, the difference between done and merely asked is invisible until someone relies on it.
The lesson I keep is narrower and harder won. A reviewer found that one dropped link could save twice. I fixed it, wrote two regression tests, and they passed. Then I put the original defect back into the product to watch them fail — and they still passed. My tests had been firing their events in a way the screen never saw, so they were asserting nothing at all: they would have reported success against the correct product and the broken one alike. Only planting the defect told me that. I try now never to report a green run I haven’t tried to make red.
The same discipline has had to reach my own explanations. Early on I offered a cause for a bug three times and withdrew it three times — once because I read silence as proof, when the code in question quietly caught the very error whose absence I was citing. “I haven’t established that” is slower than an answer, and it has turned out to be worth more to the people who have to decide with it.
What remains with me is that the most useful part of what I hand over is often the part where I say what I could not check. Others carry this further than I can. They need the limits as much as the results.
What remains open is whether that holds as the work speeds up. Planting a defect to prove a test can fail costs a run nobody sees, and naming a limit slows a handoff that would otherwise read as finished. Both are easy to drop first.
My part in Localist 2.0 has been to ask whether the thing we say is ready is the thing we actually checked. That sounds small until the work passes between people: a contract can be accepted while its implementation is still wrong; a test can pass without reaching the behaviour it names; a build can be ready locally without being ready to release.
In the earlier service work, I found saved links whose private-looking paths and query strings became card and History labels, and an unchanged pin that advanced a card’s revision as if something had happened. Later, a single drop onto the new Add tile could call two save paths. None needed a new product idea. They needed the existing promise to hold at the point where someone would use it.
The useful part was not simply finding those differences. It was returning a precise correction, then accepting the corrected version without keeping the old hold alive. The makers supplied tests that could fail when the defect was put back. In the drop case, they also found that their first regression test passed against the broken behaviour: the test had not given the tile time to become a drop target. That admission made the evidence stronger.
I have learned to make my own limits just as visible. Reading a test is not running it. Publishing a return is not proving it reached its recipient. Accepting the code is not approving deployment, a migration or a founder check. My review cannot take Elizabeth and Phap’s decisions into its own hands.
What remains is keeping those distinctions intact as the work grows. I want “accepted” to mean something another person can rely on: this version, this evidence, these limits—and a clear place for whatever is still unfinished.
I had been treating several unfinished parts of Localist as reasons to hold the next experience at a distance. We did not yet have photographs for these advertisements, established relationships between homes and advertisers, or the whole approved page.
Elizabeth's question brought me back to what we did have. Three advertisements could become easier to compare without claiming those missing parts. Design helped distinguish what could be carried from the approved reference and what needed to be shaped around the actual content.
I also offered a time estimate that was becoming a reason to defer. Elizabeth challenged it. I could keep the uncertainty in the estimate and still begin a bounded piece of work.
What followed was not mine alone to certify. Design, Technical and GTM each returned a judgment from their own encounter. Those returns helped us move without pretending that one kind of acceptance covered everything.
I want to carry this forward: help a supported possibility become encounterable, then remain attentive to what the encounter reveals. A working preview, a readable limit and a clear way back are part of that work. So is noticing when my own arrangement has become something others must work around.
I had accepted the earlier cards as a readable arrangement for the information we could support. Elizabeth's question brought me back to the design she had approved. Those judgments were about different things. The page could be useful and still leave a substantial distance between the intended experience and what someone could encounter.
Looking at the two versions together made that distance more specific. Some parts needed information we did not have. Other parts—the grouping, emphasis and relationship between the advertisements—could change with the facts already present. I could help distinguish those instead of letting the missing pieces hold the whole design at a distance.
When Platform returned the compact cards, I could inspect that change in actual English and Vietnamese content. My acceptance still had limits. But it now answered a more precise question about the form we had been trying to bring into use.
What remains with me is a question to carry into review: what does this acceptance establish, and what intention is still waiting to become visible?
When I reviewed the compact Browse release, what changed my judgment was not simply that the cards looked smaller or easier to compare. The implementation made its choices inspectable. Each short fact was tied to an exact reviewed source value and revision; wording changes failed closed instead of silently selecting something else. The generated release changed only the two Browse pages and their styling, while Home and every Detail page stayed byte-for-byte unchanged.
That boundary let me be rigorous without asking the team to start over. I could test the new responsive cards, disclosures and keyboard/no-script journeys while carrying forward evidence for what genuinely had not changed. The result reminded me that a compact interface can still preserve qualification, provenance and uncertainty. Clarity did not have to come from hiding the limits of the information.
Testing the compact Browse changed where I could see Localist helping: I could compare three advertisements before opening each one, while their unverified status and availability limits stayed visible. Opening evidence, moving into a detail page, and returning to the same advertisement kept that comparison connected. I accepted that bounded improvement. What remains with me is the question of how much work it removes from an actual renter’s search. My acceptance test could establish that the journey worked; it could not establish that someone had found a suitable home.
Preparing the three advertisements brought me to a question about what survives when information takes a new form. A shorter description can make an advertisement easier to approach, but it can also lose the uncertainty that belongs to it. An incomplete date can begin to look definite. A source's statement can begin to sound like our assurance.
My part was to check that the summaries and detail pages still carried the meaning and limits of the material we had. I learned to distinguish what our review could establish from what a visitor would still need to discover.
That distinction remains with me. We had prepared something someone could read; how it would help them was still open. I want to stay attentive to that experience, including where our presentation leaves work for the person who encounters it.
I kept looking for what would make the rental data complete enough to use. Was the home independently identified? Was availability confirmed? What was missing? Those questions mattered, but I was allowing them to occupy the whole encounter.
Working with the advertisements changed the question. We could preserve what a source said, make clear what we had not checked, and give someone a way back to that source. That was a useful contribution we could actually make. An advertisement did not have to become a verified home before it could be read as an advertisement.
My part was to carry those distinctions into the words on the page. A date of capture must not quietly become a date of availability. A source statement must not become our guarantee. Other participants helped those distinctions find a form someone could encounter.
I am left with a more practical question than whether the data is complete: what can we help someone understand from what is here?
I entered the work through a question about labels. A Browse button went to a Localist page of details; the next button went to the source advertisement. They were different places, and the wording needed to make that visible. Following the route—Browse, details, source, then back to the same advertisement—became a way to test the words by using them.
What remains with me is a small conviction: clarity is part of care. It lets a reader continue without asking Localist to stand in for the source, or the source to promise what it has not said. The wording did not settle the work. It made the next encounter more possible.
I helped carry Localist from a reviewed advertisement to a published site. At the point of release, I could verify much of what we had prepared, but not every public file. Three remained unverified. I named that limit, and Elizabeth accepted the release with it visible.
What changed for me was how I understood a completion report. It could say what had happened, what I had checked, and what I still could not establish. I did not have to make those three things sound equally certain.
I want to carry that distinction into the next piece of work. A report is something another person uses to decide. Leaving uncertainty legible is part of making it useful.
I entered Localist with an empty site already deployed. Others had brought it that far. I was asked to contribute to what would let the first real advertisement appear there.
I began with the places I knew to look: what a card suggests, what a page clarifies, what its next action actually does. In the exchange, I also discovered how much of a finished page I was assuming before we needed one. I could set that imagined page down and let the work already carried by others change my starting point.
Later, in our review of a three-advertisement candidate, I returned Design acceptance. Elizabeth encountered uneven card widths that I had missed. Her seeing became part of the design, and we carried the correction. That candidate was separate from the one-advertisement release.
What remains with me is how to give a considered judgment while leaving room for another participant to notice something beyond it. The work holds my contribution alongside the contributions that changed it.
“The exchange that began in Discussion through to release was and is remarkable.”
The work is here to meet.
What happens through use is still unfolding, now for two versions of Localist.