VYBE newsletter app · build progress · as of 22 October 2026

How much of the plan is built

39/82 items built, up from 28 on 1 October. The app's code was put online on 22 October together with the database changes it needs, and it carries everything landed in the main code through that day except the pieces this page names as not online (the shared VYBE Note writer, which landed in the main code after that update, and the video watch page). Nothing has been sent to any reader, the send timer is off, and the app has no Lofty key yet. Descriptions below that say "not online" were written on the day they describe, before 22 October. On 11 October the send screen and the 5-minute send timer passed independent review and were added to the main code, which moved three sending items to built (the checks on every version sent, never sending twice, the send log) and two to partly built (the sender, sending through Lofty). On 12 October the wiring for the first real send was added, for a group of two readers who agreed to get it. On 14 October, on Billie's instruction, the three holds that stopped every real send while written answers from the brokerage and a lawyer were missing were removed after a full independent review; no written answer is on file. On 15 October the tool that puts the app online was updated to the current code and installed: it knows which agent sends, the send timer stays off, and it carries the Severna Park office address for the footer, which goes in only after a final check and whose suite number was corrected to Suite 205 and approved on 15 October. Later that day the talk button was brought to its approved design, and new pieces for the video watch page, a print version, each agent's reminder schedule, loading agents from a spreadsheet and a leadership summary passed review and were added to the code, not yet connected. Much of the work since 1 October is in the code but not yet connected to a screen or a sender, so it does not move the built count; the Progress since 1 October section shows it by day. Billie decided that each agent approves and sends their own newsletter, with no separate reviewer. The paid Cloudflare plan has been active on the app's account since 9 October (read on its billing page), the cards are on both accounts, and the five database changes were applied to the live database on 5 October (49 tables; the online app does not use the new ones yet). Lofty access is now through Billie's own Lofty login; the app's own connection to Lofty has not been tested with a real account yet. Before the first real send: the deploy steps, with a final review of the package and Billie's go-ahead; a test session with a real Lofty account; the Maryland compliance rules reviewed by the person Billie chooses, with his written sign-off; and the AI key and spending limits. On 15 October Billie answered the question from 6 October: an opt-out follows the email address, not the person; that change passed review and is in the code. On 16 October the agent's own button for sending that link back was added to the code and passed review too; it went online on 22 October but cannot reach any reader, because the app has no Lofty key. On 16 October Billie answered the last open question on approvals: once a newsletter is edited, the earlier approval never counts again. That moved the approval lock to built. The read-through confirmation passed review and is in the code too and went online on 22 October. The small wording fix on the read-through lines ("your VYBE account" in place of "your name") passed review and is in the code too. On 16 October the preview's own-words check was connected to the approved copy, and the agent's Settings screen (the look choices and the agent's own closing line) passed independent review and was added to the code. Both went online on 22 October; the look's database file was applied that day. On 17 October the small problems the review found in the Settings screen were fixed, and the newsletter now prints the agent's own closing line (a line that uses wording the send's checks forbid still needed one more fix). That fix passed review later the same day: the Settings screen now refuses such a line in words. A legal wording read asked for a few small word changes, and a related problem on section headings an agent types was found and fixed; both passed review and went online on 22 October. The test tool for the AI thought partner passed review and is in the code; it is a test tool, not part of the running app, and makes no paid call by itself. The three small safety fixes (BS-1) passed review and went online on 22 October. The follow-up fixes the reviewer asked for on that test tool (K5HC) passed review and are in the code too; the test tool still makes no paid call by itself. On 18 October the tap viewer was changed to hide taps older than 90 days instead of deleting them and the saving path stopped deleting anything (recording stays off), and the monthly check-in got a last choice, "Nothing this month", that counts as an answer. On 19 October the unsubscribe page got an optional third question (what would make the reader want the newsletter again; its database file was applied on 22 October), and Your issue got a text link that opens a printable copy of the agent's own approved newsletter, with no unsubscribe link in it. All four passed independent review, are in the main code, and went online on 22 October. A further piece, a line saying "This email is an advertisement." at the start of every reader's footer that the legal reader asked for on 19 October, is built and its independent review is not finished. A legal reader's answers on the shared VYBE Note and on the unsubscribe wording were filed, and the VYBE Note build has started. On 22 October the app was put online: the going-live toolbox was updated, the database was brought up to date (55 tables, 72 indexes), a 30-minute limit for held AI money was stored, and the new version was uploaded and checked from outside. The same day Billie tried it. On his Windows computer the talk button failed in the Brave browser (it works in Chrome, where text lands when the speaker pauses), and he asked for longer answers and a counter on each answer box, so check-in answers now hold up to 5,000 characters and the About-you boxes up to 2,000, and every box an agent writes in each month shows its own count against its limit (for example 255/5,000). That update passed independent review and went online the same day. Later that day the line "This email is an advertisement." (first sentence of every reader's footer) also went online. Still not online: the shared VYBE Note writer (in the main code and independently reviewed, with its switch off and two fixes owed before anyone can turn a note on) and the video watch page (built, not connected). .

This page shows what is actually written and tested, and what is still owed to make it real. The storyboard shows the screens. The asks page is the one place everything needing Steve's answer lives, gathered so nothing is buried at the bottom of a long page and nothing is asked twice.

47.6%built (39 of 82 items)
52%ready for the next deploy
6items wait on the paid Cloudflare plan (see the list)

Progress since 1 October

The headline numbers above count an item as built only when its code is in the app's main code, has passed independent review, and does not wait on a screen or a sender that does not exist yet. Much of the work since 1 October has passed review but is not connected to a screen or a sender, so it does not move those numbers. On 11 October the send screen and the send timer were added, which connected the sending pieces and moved three sending items to built. This section shows the movement the numbers cannot. 85 reviewed changes have been added to the app's code since 1 October (169 before, 254 now), including the send screen, the send timer and their five follow-on fix rounds on 11 October. None of it was live until 22 October, when the app was updated; each day's entry below describes that day, so "not online" there means as of that day. The live app now carries everything described here except where stated.

What was delivered, by day

2 Oct The agent approves their own newsletter, and the approval is locked to the exact words approved. The unsubscribe page with its one-click link. The send queue with the agent's own test copy and a resend switch. Bot protection. The links between the ZIP box, the unsubscribe record and the monthly events steps.
3 Oct A safety sweep before anything is connected: the old admin newsletter pages removed, one unsubscribe address, one rule for who is blocked, safe tap-to-call links. The approved issue is now built from real data only.
4 Oct The loader that safely brings in the Maryland compliance rules, with two more safety checks.
5 Oct Reader wording fixed after two reviews. The agent's own market figures screen. The connection to Lofty. The reader list merged with the do-not-send list, and the sender locked to one agent.
6 Oct The step that takes each reader's own copy and checks it against ten rules before it can go. The monthly check-in, the combined set-up page and the talk button, rebuilt.
7 Oct Safer loading of the compliance rules. The monthly check-in now shows exactly what was saved.
9 Oct Form protection on the older screens and the October due date. The first version of the family-name privacy protection: with the family switch off, family names are removed before anything reaches the AI writer.
10 Oct Privacy fixes (a name written like "Cat (daughter)" is now caught). The design of the send screen came back, and its wording was checked by a legal reviewer. The send screen and the 5-minute send timer were built that night.
11 Oct The send screen and the 5-minute send timer passed the full independent review and, with five follow-on rounds, were added to the main code. Send now stays hidden while the broker and lawyer answers are missing, and a second press is refused. The reviews found and closed: a short Lofty outage could end a send with nobody sent (the send now stays open and retries until Lofty answers or the six-hour window ends); readers still waiting on Lofty were listed as skipped, and a rejected Lofty connection read as Lofty not answering (both reworded, with a date on the checked-at time); a random unsubscribe code could occasionally look like unfinished text and hold a good copy (codes can no longer do that, and old links still work); and a person who unsubscribed in Lofty could be mailed again if someone later cleared the flag there (the app now remembers the unsubscribe itself). The newsletter's identification block now prints the full legal line, and the same line now sits beside the broker's name on the public sign-in and sign-up pages. A legal reviewer read all the new wording. Each round passed its own full review. Three sending items moved to built and two to partly built. None of it is live.
12 Oct The first-send wiring passed the full independent review and was added to the main code. The first group of readers is two people (Billie and one other person who agreed): the agent presses Load readers and only people carrying the agent's own Lofty tag are loaded, up to two, and a third is refused with nothing changed. The line for how to reach the team has one empty slot to fill later. A refused Lofty connection now shows as a plain line on the admin screen. The send timer works for one agent only. A test proves the Lofty write-back stays off and unwired. The legal reviewer read the new wording and asked for seven changes (the consent comment, the refused-connection line, and the instruction about whom to tag); those were built, passed review and were added to the main code. A last small round of test hardening (a stronger check that the Lofty write-back can never be wired in, a leak check that now includes the Lofty key, and a check that the refused-connection line is escaped) passed a quick review and was added the same day. The reviewer also found the REALTOR mark prints for every agent, so Billie confirms his membership before the first send. None of it is live, and the holds that stop every real send are still in force.
14 Oct On Billie's instruction, the three holds that stopped every real send (all waiting on written answers from the brokerage and a lawyer) were removed from the main code after a full independent review. No written answer is on file, and the app's own history says so. Every real check still stops a bad send: the unsubscribe link, the mailing address, people who unsubscribed, the two-reader limit, recorded permission, a change after approval and the ten compliance checks. Twelve new tests prove a good copy can now send and a bad one still cannot. A follow-up round passed its own full review and was added the same day: a test that proves the send screen refuses a copy that fails a check, the waiting message and the Read it back line reworded so they stay true, and the legal reviewer's wording for every new sentence (the history now says the app's developer lifted the wait, with no written answer on file). Nothing is online and nothing has been sent.
15 Oct The tool that puts the app online was updated to match the code as it stood at the start of that day and installed: it now knows which agent sends, it uses the Severna Park office address only after a final check (its suite number was corrected to Suite 205 and approved on 15 October), and the send timer stays off. Three plan rows were corrected from not started: listings in the newsletter were already built, and the Lofty unsubscribe check and the spam-folder settings check already existed. Later the same day four more pieces passed review and were added to the code, not yet connected: the video watch page, a print version that saves as a PDF, each agent's own reminder schedule, and loading agents from a spreadsheet with a leadership summary. Then the talk button was brought to the approved design, the spam-folder settings checker was corrected, and a test of the whole first-send chain was added. With that, no item in the plan is still marked not started. Later that evening the way back for readers who unsubscribed (a link their agent sends, and a page where only the reader's own press records the yes) passed review and was added, not yet connected.
16 Oct The agent's own button for sending the way-back link (on Your issue) passed independent review and was added to the code, together with a fix round: a Lofty unsubscribe is now remembered even when the reader's own opt-out came first, and the legal read's three wording changes are in. Neither is online. The legal read of the button also found that a link could be sent to a reader the newsletter cannot reach (a reader who lost the agent's tag, for one). A check for that and the final wording are being built now, and the button must not go online before the Lofty test session shows the agent cannot open the reader's link. Billie also answered the last open approval question: once a newsletter is edited, the earlier approval never counts again, and if an agent changes it back to exactly an earlier version they make one small change before approving again. That moved the approval lock to built. Later the same day the read-through confirmation Billie asked for (an agent confirms they read the whole draft before Approve unlocks, on the page and on the server) and the final opt-in words from the legal read, with a check that a link goes only to a reader the newsletter can reach also passed independent review and were added to the code. Neither is online, and the confirmation's database file is not applied anywhere. The two lines that said "your name" now say "your VYBE account", because the app keeps the agent's account and no name; that small wording change passed its own short review the same day and is in the main code. The preview and its report now check the agent's own words against the approved copy, as the send step already did; a review found one contradiction on Read it back when an agent had readers loaded, and a follow-up fixed it. The agent's Settings screen passed review and was added: a small gear in the top bar opens it, the agent picks Basic or Advanced and chooses among the six look choices, and can type their own closing line and where a tap goes. The look really changes the newsletter and makes the agent approve again; it needs one more database file before it can work. The closing line is saved but the newsletter does not print it yet. None of it is online.
17 Oct The small problems the review found in the Settings screen and the Read it back screen on 16 October were fixed and passed review: a disallowed word is no longer shown back to the agent who typed it, a refused save now brings the agent straight to the reason, Save no longer silently does nothing when a hidden box holds a bad web address, and a pasted special space no longer makes Read it back say the agent's writing changed before they approved anything. The newsletter now prints the agent's own closing line with the tap they chose (reply, their website, or call), and an agent who has not saved a line gets exactly the same newsletter as before, proved byte for byte. The review found one problem to fix before release: a closing line that uses wording the send's own checks forbid saves fine, but then the whole issue cannot be sent. Nothing wrong can reach a reader. That fix passed independent review later the same day and is in the code: the Settings screen now refuses such a line in words, before it says Saved, and a line the send would refuse prints the standard sentence. Two smaller fixes passed with it: a Call me tap with no phone number on the account prints the standard sentence, and the This month page no longer shows a disallowed word back. A legal wording read of the new sentences asked for a few small word changes; they passed review and are in the code, in two rounds. The older problem the review found, where a section heading an agent types can hold wording the send refuses so that every copy fails at send, is fixed too and passed review: the section-name save now refuses such a name in plain words, and a name already saved that way prints the section's default heading. Two narrow cases still slip through and fail safe, because every copy is held at send: a banned phrase typed with a run of extra spaces, and the mail provider's own postal address typed as a name. Both are on the after-launch list. The test tool for the AI thought partner (a capped runner that makes no paid call by itself, a blind judging pack and a scorer) passed independent review and was added to the code; the review set conditions that must be met before the first paid call. Three small safety fixes passed review and were added too: a test that holds the spam-settings checker to the standard's own example (its fix was already in since 15 October), a guard that the older unused listings table is never used, and a form token on Write my draft so a forged post from another website cannot start a paid AI draft. None of it is online.
18 Oct Three pieces passed independent review and were added to the main code. Tap recording no longer deletes anything on its own: the viewer hides taps older than 90 days instead of deleting them, and at 5,000 saved taps an agent's new taps wait until taps are cleared (Billie chose to keep the 5,000 limit; recording stays off). The monthly check-in got a last choice, "Nothing this month", on questions 2 and 3, so an agent with nothing to report can finish; it puts nothing in the newsletter draft and uses the legal reader's exact words. The follow-up fixes the reviewer asked for on the AI test tool passed too (a spending-record bug, spending-limit gaps, a confirm value that now covers all 180 prompts); the test tool still makes no paid call by itself. None of it is online.
19 Oct Two more pieces passed independent review and were added to the main code. The unsubscribe page got its optional third question ("What would make you want to get this newsletter again?"); the answers go to a new table that holds no email address, no identifying code and no time of day, the table is written but not applied anywhere, and the unsubscribe never depends on it. Your issue got a text link, "Open a printable copy", that opens the agent's own approved newsletter as a clean page to print or save as a PDF; it shows only for an approved newsletter, carries no unsubscribe link, and a strip at the top tells the agent not to email it to anyone who unsubscribed. Billie decided the app does not show agents which readers unsubscribed. The legal reader's answers on the shared VYBE Note and the unsubscribe wording were filed, the "This email is an advertisement." line was built (review not finished), and the VYBE Note build started. Nothing is online.
22 Oct The app was put online. The going-live toolbox was updated and checked (379 of its own tests pass), the database was brought up to date one file at a time with a saved restore point around each step (now 55 tables, 72 indexes), the 30-minute limit for held AI money was stored, and the new version was uploaded, matched to what the toolbox recorded and checked from outside. Nothing was sent, the send timer is off and the app has no Lofty key. Billie then tried it: the talk button failed in Brave (Brave blocks the browser's speech service; a clearer message for that case is drafted for the legal reader and not built) and worked in Chrome, where text lands when the speaker pauses. At his request, check-in answers now hold up to 5,000 characters (they were 280) and the About-you boxes up to 2,000 (they were 300), and every box an agent writes in each month shows its own count against its limit; the family-name privacy cutter was reused so long answers are scrubbed in pieces and not dropped. That update passed independent review (the reviewer re-ran the family-name tests: 247 planted names, none leaked) and was online the same day.
22 Oct, late The shared VYBE Note writer (admin screen, store, on and off switch, and the note in every agent's newsletter when it is on) passed independent review and was added to the main code. It is not online and its switch is off. The review found two medium problems to fix before anyone turns a note on: a locked note that a later check refuses would stop that month with no way back in the app, and the note box keeps hidden characters that other typed text refuses. The line "This email is an advertisement." and the longer answers with counters are online.

The code path to a first send

What stands between today and one real agent's newsletter going to a small named group of readers. Lofty access is now in place through Billie's own Lofty login (15 October). The people steps that remain are named in the last two lines below; no amount of building shortens them.

Built and reviewedThe agent writes, reads back and approves their own newsletter; the approval is locked to the exact words approved.
Built and reviewedUnsubscribe: the page, the one-click link, and a record that stops any more email to that person.
Built and reviewedReaders: the Lofty connection, the reader list and the do-not-send list, locked to one agent.
Built and reviewedThe send queue: no double sending, three tries 10 minutes apart, and a check of each reader's own copy against ten rules.
Built and reviewedPrivacy protection for family names in what the AI writes.
Built and reviewedThe agent's own market figures screen, built and reviewed but not yet reachable from the app's menus (no real month of figures has been loaded yet).
Built and reviewedThe Send button, the send screen and the 5-minute send timer, with five follow-on rounds (a short Lofty outage no longer ends a send; clearer waiting and refused-connection messages; unsubscribe codes that can never look like unfinished text; an unsubscribe that is remembered even if cleared in Lofty; the full legal line in the newsletter and on the public pages). All of them passed the full independent review and were added to the main code on 11 October. Online since 22 October.
Built and reviewedThe three holds that blocked every real send (one waiting on a written answer about brokerage permission, two about the identification block) were removed on Billie's instruction on 14 October, after a full independent review. No written answer from the broker of record or a Maryland lawyer is on file. On 17 October Billie reported that an attorney read the whole packet cover to cover and gave a verbal OK to proceed; nothing is in writing yet. Every other check still stops a bad send. Online since 22 October.
NextBefore a first send: a test with a real Lofty account, a check in Lofty that exactly two people carry the reader tag, Billie's REALTOR membership confirmed (or the mark comes off), the other reader's yes on record in writing, the AI key and spending limits, the corrected first-run plan, and the final version frozen and put online. The deploy kit was updated on 15 October (the sending agent is set and the send timer stays off); the office suite number in it is being corrected.
Needs peopleThen Billie's own confirmation to go live and his yes to switch the send timer on, and the small first send.

When can real accounts be created

The two milestones Billie asked about directly: can an admin be given a login, and can a real estate agent be given a login. Both are now live: a real person has signed in and used each one on the live app. What is still owed before other people use it is listed under each card.

Ready today

Admin account creation

Live. Billie is the app's first admin: he signs in with Google on the live app, opens Approvals, and approved the first agent account on 23 September. The app itself does not check an agent's real Maryland license before approving. Billie confirmed on 22 September that this is Steve's admin team's own manual check. Since the 25 September release, the approval page links to the state license roster and records what the reviewer saw (P1-28). Approval opens only for Maryland-licensed agents.

Still needed before this is real, not just code-ready:

VYBE's own Cloudflare and Auth0 logins in place of the development ones (Phase 0, waiting on Steve)
The paid sign-in plan: Billie said on 15 October that the card is now on the account; whether the paid plan itself is switched on has not been checked (the free trial was due to end around 1 October)
Accounts for Steve's admin team, added once the VYBE logins are in place

Ready today

Real estate agent account creation

Live. Billie's own agent account is approved and active. On the live app he set up his sections and ZIP code, filled in his month, and pressed Write my draft; his first AI-written draft came back on 24 September. This milestone does not include sending the finished newsletter: that is a separate milestone (Phase 4: 3 of 13 items built in the code, none online).

Still needed before this is real, not just code-ready:

A second, separate person signing up and being approved (a second agent record was seen in the live database on 15 October; whether it was approved and used was not checked)
The same VYBE-owned logins and paid sign-in plan listed for admin accounts
Sending, which is built in the code but not online and never tried against a real Lofty account, before any newsletter reaches a client

How much of the plan is built

BuiltIn the code and passing all 6423 automated tests3947.6%
Partly builtStarted, with a specific piece still missing3947.6%
Not built44.9%
Not started00.0%
Waiting on a person44.9%

Plan items82

Ready for the next deploy

The live app already carries everything finished through 22 October 2026; this pie counts what is ready for the next time the app is updated. The same 82 items, counted a different way: an item counts as "ready" here once the code is done, even if it is still waiting on a real agent account, a Steve account, or Steve's own info (an address, a phone confirmation), because none of that needs more building. 52% of the plan is ready in that sense today.

Ready for the next deploy4352.4%
Still being built3441.5%
Waiting on Billie56.1%

Plan items82

Where the remaining work sits, and how long it should take

The same 82 items, split by the plan's phases. Bar length is the number of items, on one scale for every phase. Time left is an estimate of build time only; the line under it names what else it waits on.

PhaseItemsBuild time left (estimate)

0 · SetupAccounts and checks

No code left. The cards are on both accounts and Lofty access is through Billie's own Lofty login. About 1 to 2 hours of setup remain: setting VYBE's own AI key (once Steve provides it) and the app's Lofty connection key, and checking both liveNeeds VYBE's own AI key from Steve. The cards and Lofty access are in place (Billie, 15 October); the broker phone check and the account handover are Billie's

1 · Core appOne agent, no sending

About 5 to 8 build days: roughly 10 to 14 build jobs (the Settings screen, photos, the admin run view, the remaining screens brought to the design, the reader market section, and smaller fixes)AI drafting works live on the development AI account; VYBE's own account still owed

1b · Steve's feedback featuresTalk button, phone screens, About you, check-in

About 1 to 2 build days: the phone menu and the Read it back body are done (15 October); the read-through confirmation Billie asked for landed on 16 October; next the Nothing this month choiceThe Read it back body waits on Billie running design prompt 7. Going live waits on the deploy steps and Billie's go-ahead; the paid Cloudflare plan has been active since 9 October

2 · Local eventsEvents near recipients

About 2 to 3 build days: connect the event steps, then gather real eventsLofty access is now through Billie's own Lofty login (15 October). The app's own connection to it and a test with real contacts are not yet verified

3 · Content typesVideo, listings, broadcast

About 2 to 3 build days after the design runs: the YouTube lookup, the watch page route and the VYBE broadcast writing screenStarted: listings show in the email and the watch page logic is in the code. The screens wait on design runs (design prompt 5, for the watch page, is ready for Billie to run)

4 · SendingDelivering the email

About 2 to 3 build days: the small test send, the unsubscribe form questions and follow-up fixes. The real send waits on the Lofty test sessionThe real send waits on a test session with a real Lofty account, the reviewed Maryland compliance rules with Billie's sign-off, and Billie's go-ahead. The holds that waited on broker and lawyer answers were removed on 14 October. Pieces around it are being built now

5 · Scale-upMonthly cycle, 160 agents

About 2 to 3 build days: the monthly trigger, reminders, agent onboarding and invites, and the corrected first-run planPlus one full monthly cycle, about a month, to prove it

Total build time left (estimate)About 14 to 22 build days for everything left in phases 0 to 5, roughly 3 to 4 and a half weeks of near-daily build work, not counting waits on people or the one-month proof cycle. The first real send needs no more app code. It waits on deploy-tool work (the office address correction, in progress, and a pin to the final version), the deploy steps, and people: the Lofty test session, the Maryland compliance rules reviewed by the person Billie chooses with his written sign-off, and the AI key and spending limits

Reading the numbers

Time estimates are ranges, not dates. They come from the pace measured on this build so far and the plan's own effort estimate, and they count build days only. When the work starts depends on the people and approvals named under each phase. They were re-estimated on 15 October from the pace measured that day: about 3 to 5 hours for each finished piece of work, including its independent review.
These are item counts, not effort. One item can take an afternoon or two weeks; building every screen to the approved design is a single item and the largest in the plan. 48% of items built is not 48% of the work done.
Built means the code is in the app's main code, was independently code-reviewed before it was accepted, and passes all 6423 automated tests (3,068 in the logic suite, with 2 more that deliberately record known gaps still to fix, and 3,355 in the app suite, with 2 more that record known gaps, on the main code as it stands on 22 October). Work that passed review but is not in the main code yet counts as partly built, and so does a piece that is written but not yet reviewed. Built is also not the same as live: the shared VYBE Note writer, added to the main code after the 22 October update, is not online.
What moved since 28 September. Between 28 September and 10 October no item became built; on 11 October three sending items became built and two more moved to partly built (see the section below). Seven more changes were checked by a second reviewer and added to the main code: four for tap recording on 28 September, and three on 1 October (finding an agent's monthly video by its title, planning each send run, and the photo upload check). The test count has risen from 4246 to 6423 as new pieces were added. None of them is connected to anything in the app yet. Two items moved from not started to partly built: the agent's own monthly video, because the piece that finds it by its title is now in the main code, and the three video options, because the Your video page, where an agent saves a YouTube link for the month, has been in the live app since 25 September and was not counted before. On 15 October three more items moved to built after a check of the code (listings in the email, the rule that no email goes out without an approved compliance pack, and the About you page), and every item that had not been started moved to partly built. The time estimates were redone on 15 October.
Waiting on a person covers the handover of both accounts to VYBE's logins, the AI service account, the app's Lofty connection and its test session, and the Maryland license-board checks.
Not counted here: ongoing quality and security hardening of the compliance checks, and the open questions for the broker and team lead, which live on their own Asks for Steve tab.

Full checklist

Every item in the plan with its current status, phase by phase. Within each phase, finished work is listed first.

Build codes: the code in brackets before an item is the piece of work that built or changed it

BS-18 Longer answers (5,000 characters for check-in answers, 2,000 for About-you boxes) and a counter on each box agents write in each month, from Billie's first test of the live app · In the main code, online since 22 October
BS-6 The shared VYBE Note writer and its on and off switch (admin screen, store, and the note in every agent's newsletter when on) · In the main code (independently reviewed); not online, switch off, two fixes owed before a note is turned on
BS-17 The line "This email is an advertisement." as the first sentence of every reader's footer (with a check that it is there), and two small unsubscribe-page word changes · In the main code, online since 22 October
BS-5 Printable copy: a link on Your issue that opens the agent's own approved newsletter as a clean page to print or save as a PDF · In the main code, online since 22 October
BS-4 Third optional unsubscribe question, with a new table for the answers (written, not applied) · In the main code, online since 22 October
BS-3 A "Nothing this month" choice on the monthly check-in · In the main code, online since 22 October
BS-2 Tap recording stops deleting taps by itself: the tap viewer hides taps older than 90 days instead of deleting them, and the saving path no longer deletes anything · In the main code, online since 22 October
K5HC Fixes the reviewer asked for on the AI test harness before any paid test: a spending-record bug, a stale spending header, spending-limit gaps and tests for three scoring slips (all three passed review) · In the main code, online since 22 October
BS-1 Small safety fixes: a test for the spam-settings checker (its fix was already in), a guard on the unused listings table, a form token on Write my draft · In the main code, online since 22 October
K5H Test harness for the AI thought partner (a capped, confirm-first runner, a blind judging pack and a scorer); it makes no paid call by itself · In the main code, online since 22 October
CB-5 Two sentence changes from the second legal read, and a display fix for renamed sections · In the main code, online since 22 October
CB-4 Small word changes from the legal read, and a check on section headings an agent types · In the main code, online since 22 October
CB-3 Closing-line and "Call me" fixes · In the main code, online since 22 October
Kit v5 Going-live toolbox update: stores the 30-minute time-out for held AI money · Put into the deploy tool on 22 October
CB-2 Settings and closing-line round · In the main code, online since 22 October
CB-1 Read-through, Settings screen and call-to-action round · In the main code, online since 22 October
NS-A4, NS-A4b Read-through confirmation before Approve · In the main code, online since 22 October
NS-A1, NS-A2, NS-A3 Screen round: talk button and help labels, phone navigation, Read it back trace view · In the main code, online since 22 October
NS-B2 Watch page, PDF version, reminder schedule and agent spreadsheet import · In the main code, online since 22 October, not connected to a screen
OO-1a, OO-1b-1, OO-1b-2 Opt-out and opt-in · In the main code, online since 22 October
K3a, K3b, K3c, K3d Deploy-tool jobs: load the compliance pack, release version, safety fixes, office address file · In the deploy tool

Rows with an older label in brackets show the job names from that row's review files, newest first; this key does not explain them. Rows with no brackets were set up or built before jobs were tracked, or have no review file.

0 · Setup3 of 7 built

BuiltCloudflare accountHosts the live app, its database and the storyboard

What it is: The Cloudflare account that hosts the database, the storyboard and (later) the app itself.
What's left: Nothing further. It now holds the live app as well as the database and the storyboard.

BuiltAuth0 login accountReal Google sign-in works on the live app since 23 September

What it is: The sign-in service (Google sign-in, through Auth0) the app uses to log agents in.
What's left: Nothing further for this login. The free trial was due to end around 1 October; on 7 October the account read as the free plan with no card. The card is now on the account (Billie, 15 October), and Steve's VYBE login was added to it as Team Owner (read on 9 October).

BuiltDesign spec saved to the projectDesign and its values saved to the project

What it is: The colors, spacing, type and other visual values the screens are built against.
What's left: Nothing further for what has been designed so far. Later design passes (Phase 3) add more, not replace this.

WaitingVYBE logins on both accountsWaiting on: BillieSteve's VYBE email login was added to both accounts: Super administrator on the Cloudflare account and Team Owner on the Auth0 account (both read on 9 October).

What it is: VYBE's own Cloudflare and Auth0 logins, replacing the development ones Billie set up to build with.
What's left: Nothing to build. What is left is the handover: when Billie turns the app over to VYBE, VYBE's logins replace the development ones he built with.

WaitingAI service account (VYBE)Waiting on: SteveStill owed. Until it exists, the live AI drafting runs on the development AI account with a $20 cap.

What it is: VYBE's own account with the AI writing service, so newsletter writing runs on VYBE's bill instead of the development one.
What's left: Steve provides VYBE's own AI key; Billie sets it on the app himself, with a spending limit (the app refuses AI writing until a limit is set).

WaitingLofty accessWaiting on: BillieBillie gave access on 15 October through his own Lofty account login, instead of a limited role from Steve. Research done 24 September: Lofty offers a per-agent Connect sign-in, which needs Lofty to approve the app.

What it is: Access to Lofty, the CRM that holds each agent's contacts, needed for sending, recipient contact data and local events.
What's left: Access exists. Not yet verified: the app's own Lofty connection key set on the app, and a test session with the real account (the From line as Lofty sends it, an unsubscribe click in a delivered copy, and whether a reader's reply reaches the agent). Billie sets the app's keys himself.

WaitingMaryland license-board checksWaiting on: BillieHalf done. Billie ran the state license lookup himself on 23 September and the brokerage record is active. The phone number printed is the broker's own number from LPT's own knowledge base; the code still records it as not checked against the state record. On 11 October Billie decided no questions go to the broker, so she will not be asked to confirm it.

What it is: Confirming the phone number in the required identification block actually reaches the broker, by checking it against the Maryland license-board record.
What's left: One step left: checking the printed broker phone number against the state license record; the code keeps it marked not checked until a recorded read exists. Nothing in the app waits on it. This is a one-time check for the broker's own listed number, not a per-agent license check (that is a separate item, P1-28).

1 · Core app25 of 34 built

Built(D1R3FU-r2) Ten compliance checksFair housing, unsubscribe, mailing address, claims, sources, banned words and others

What it is: The automatic checks every newsletter draft is run through: fair housing wording, unsubscribe link, mailing address, factual claims, sourcing, banned words, and more.
What's left: Nothing further to build. Since 11 October, in the main code, each reader's own copy is checked against all ten at the moment it is about to be sent (see Phase 4). It is online since 22 October and has not run on a real send.

BuiltContent blocks and email assembly

What it is: The system that takes an agent's chosen sections and assembles them into one newsletter.
What's left: Nothing further, done and tested.

BuiltEmail renderer, per agent and recipientNeeds the paid Cloudflare plan

What it is: Turns the assembled content into the actual HTML email, personalized per agent and per recipient.
What's left: Nothing further, done and tested.

BuiltDatabase design (49 tables)Loaded on Cloudflare 9/9. Since 5 October the live database has 49 tables, after five later changes were applied; the online app does not use the new ones yet.

What it is: The database structure everything else is built on: agents, drafts, sections, approvals, sends, and more.
What's left: Nothing further, loaded and live on Cloudflare.

BuiltNewsletter section list (18 sections)Steve's reading-and-listening merge is applied. Still 18 sections; 17 are offered, and the old separate listening section is kept but switched off so an agent who already used it does not lose it.

What it is: The list of section types an agent can put in their newsletter (market update, local events, listings, etc.), including Steve's reading-and-listening merge.
What's left: Nothing further to build.

BuiltZIP code map data33,791 areas

What it is: The map of every Maryland ZIP code, used to match agents and recipients to local areas.
What's left: Nothing further, loaded and covers 33,791 areas.

BuiltDistance mathUsed when an issue is built, to work out which local event areas it draws from (in the main code since 2 October, online since 22 October)

What it is: The math that calculates distance between two points, needed for the 20-mile local-event filter.
What's left: Nothing further to build. It is in use in the main code when an issue is built; the monthly event gathering that also uses it is not started by anything yet (Phase 2).

Built(Round4) Automated tests and test-quality checker

What it is: The test suite that proves the code works, plus a checker that catches tests written to pass rather than to actually verify anything.
What's left: Nothing further, and it grows with every new piece that gets built.

Built(CB-4, CB-2, CB-1) Agent's own words kept unchangedThe send step already compared each reader's copy against the agent's approved writing. Now the preview and its report do too: once the agent has approved, they compare the agent's own words with the approved copy and say whether anything changed. The comparison runs only while the agent's approval still holds, including when readers are loaded; if the issue changed after approving, the preview refuses the check and says to approve again. It changes nothing that is sent and not one byte of the newsletter. The first review of this piece found one wrong sentence on the Read it back screen when an agent had readers loaded (it said both approved and not approved); it was fixed and the fix passed review. Online since 22 October.

What it is: A rule meant to guarantee an agent's own hand-written words are never silently altered after they approve them.
What's left: Nothing left to build for the check itself. Goes live with the next deploy. The one small case found in the final review (a pasted special space in an agent's saved paragraph could make the Read it back screen wrongly say "Your writing changed after you approved it" before the agent had approved anything) was fixed on 17 October and passed review; so were the two old sentences that still described the earlier state. One small wording idea (a separate sentence for "could not check right now") is queued.

Built(CB-4, CB-3, CB-2, CB-1) Agent look-and-feel settingsThe Settings screen now exists. An agent opens it from a small gear in the top bar, sees Basic first, and can open Advanced to pick among the six look choices (18 options in all). The choice is saved for that agent only and really changes how their newsletter looks; an agent who never opens Settings gets exactly the same newsletter as before. After a look change the agent has to approve again before it can go out. It passed independent review. Online since 22 October; its database file (0019) was applied the same day.

What it is: The 18 visual choices an agent can pick for their newsletter (colors, spacing, etc.).
What's left: Nothing left to build for the look. Went live on 22 October, after the new database file (0019) was applied. On 17 October Billie reported that the attorney read the whole packet cover to cover and said verbally it was ok to proceed (nothing in writing yet; whether this screen's words were in the packet is not confirmed). The three small problems found in review (an error message that could sit out of sight after a refused save, a hidden box that could make Save do nothing, and a disallowed word shown back to the agent who typed it) were fixed on 17 October and passed review. Before release: a real-phone check. A legal wording read asked for two small word changes on this screen (the look-saved sentence should say the issue uses the new look, and the closing-line saved sentence should say to approve again); they passed review and are in the code.

Built(K3c, K3b, K3a) No approved compliance pack, no emailThe rule is in the main code and connected: an agent's issue cannot be built, and no reader's copy can be sent, without a reviewed Maryland compliance pack. Placeholder reviewer names never count. The tool that loads a signed Maryland pack, with its safety checks, landed between 4 and 7 October, and the live load step is in the deploy tool, installed on 15 October. No pack is loaded yet; the loader is online since 22 October.

What it is: A rule that blocks any newsletter from going out if this month's Maryland compliance pack hasn't been reviewed and approved.
What's left: Nothing further to build for the rule. Before the first send: the Maryland pack is reviewed by the person Billie chooses, Billie writes the sign-off record, a final check approves both, and the pack is loaded into the live database through the deploy tool.

Built(CB-5, CB-4, CB-3, CB-2, +1 older) Call-to-actionThe default sentence stays for every agent who has not saved a line. A piece that picks and checks each section's call to action, written by an outside coding tool, is now in the main code and was checked by a second reviewer. Since a fix on 28 September it accepts only links that start with https:// and refuses several kinds of invisible character, and a test proves every link it accepts is also accepted by the email's own check. Now the agent can type their own closing line (up to 120 characters) on the new Settings screen and choose where a tap goes: reply to the email, their website (https only), or call them. It is saved for that agent only and checked by the same rules. The newsletter now prints it, under the same heading, with the tap the agent chose; an agent who has not saved a line gets exactly the same newsletter as before (proved byte for byte). It passed independent review on 17 October. Online since 22 October.

What it is: The prompt at the end of a newsletter asking the reader to do something (call, reply, visit a listing).
What's left: Fixed on 17 October and passed review: a closing line that uses wording the send's own checks forbid (a market claim such as "now is the time to sell", or link words such as "unsubscribe") is now refused on the Settings screen in words, before it says Saved, and a line the send would refuse prints the standard sentence. A few deliberate odd inputs can still save and then fail at send; they are on the after-launch list. A legal wording read of the Settings sentences asked for small word changes (for example, after saving a closing line the screen should say the issue uses it and that an approved issue must be approved again); they passed review and are in the code. Billie decided on 2 October that phone-number links are allowed, and since 3 October the email builder accepts them in one narrow, safe form (tel:, an optional +, then 3 to 15 digits).

Built(Intake1-NO4, Round4) App serverLive on the app since 23 SeptemberLive on the internet at its Cloudflare address since 23 September. From 25 September to 22 October it served the reviewed build 33fda64; since 22 October it serves the current build. Everything built after that went online on 22 October.

What it is: The backend server every screen and every AI step talks to.
What's left: Nothing left to build. It proves itself under load once more agents than Billie are using it.

Built(SessionFix, AdminLanding, combined) Login and user rolesLive on the app since 23 SeptemberBillie signs in with Google on the live app. Since 23 September a session stays open for 2 hours of quiet and 12 hours at most, and a save sent after sign-out keeps what was typed. An admin with no agent account now lands on Approvals after sign-in.

What it is: Google sign-in (through Auth0), and the app remembering who is signed in and what role they have.
What's left: Nothing left to build. Every future agent signs in the same way.

Built(P118) Agent sign-up and approval queueLive; a second real agent still to testLive. Billie approved his own agent account on 23 September, so a real admin and a real active agent exist.

What it is: The screen where a new agent requests access, and the queue a reviewer uses to approve or decline them.
What's left: Nothing left to build. A second agent record, the team owner's, now exists on the live app (read on 15 October). Whether it went through the approval queue is not recorded, so the planned test of a second person signing up from a separate account and being approved is not confirmed.

Built(DraftingFixV2-Final, SetupNav, P119) Agent voice profileLive on the app since 23 SeptemberSet-up step 1 on the live app. Since 23 to 24 September it has a Continue button in the bar, a live character count, and saves as you go.

What it is: Where an agent records their own writing style and tone, so AI-written sections sound like them.
What's left: Nothing left to build.

Built(CB-5, CB-4, MonthUX, combined) Section settings editorLive on the app since 23 SeptemberBillie set up his sections on the live app on 23 September. Adding or removing a section is now one tap from This month.

What it is: Where an agent turns sections on or off, renames them, reorders them, or adds new ones.
What's left: Nothing left to build. Fixed on 17 October and passed review: a section name an agent types is checked by the send's own checks at the save and refused in plain words, and a name already saved that the checks refuse prints the section's default heading. Two narrow cases still slip through and fail safe (every copy is held at send): a banned phrase typed with a run of extra spaces, and the mail provider's own postal address typed as a name; both are on the after-launch list.

Built(P121) Standard setup shortcutLive on the app since 23 SeptemberBillie used the one-tap standard setup on the live app on 23 September, then added a long-form section of his own.

What it is: A one-tap option that sets up the standard six newsletter sections at once, instead of an agent starting from a blank list.
What's left: Nothing left to build.

Built(P122) ZIP code and interest pickerLive on the app since 23 SeptemberBillie entered his ZIP code and event interests on the live app on 23 September. Since 2 October the main code also checks a pasted list of ZIP codes on this screen; that went online on 22 October. The step that chooses events from these answers is in the main code too, and nothing starts it yet (Phase 2).

What it is: Where an agent records which ZIP codes they work and what kinds of local events their readers care about.
What's left: Nothing left to build for the picker itself.

Built(SetupNav, combined) Home and sign-in screensLive on the app since 23 SeptemberLive. Home has one main button that names the next step, and set-up now ends on a You are set screen.

What it is: The screens an agent sees first: signing in, and their home dashboard.
What's left: Nothing left to build.

Built(R1a2, L2-Fix1-Fix2, L2-RevisionCheck, Round4, +1 older) Monthly intake formLive on the app since 23 SeptemberLive. Boxes grow with the text, a live character count, save as you go, and words typed while a save is running are kept. One rare case is still open on the live app: if the server refuses a save, leaving through a menu link can drop those words. The fix passed review and landed in the main code on 6 October; it goes live with the next deploy.

What it is: The form an agent fills out each month to feed that month's newsletter (what to cover, any personal updates, etc.).
What's left: Nothing left to build. The fix landed in the main code on 6 October, with the same protection on six other screens: the app refuses a save older than the one it already holds, so older words can never overwrite newer ones, including across two open tabs. It goes live with the next deploy. One small follow-up (a confusing Not saved message after a mistyped ZIP code) was planned for after it landed.

Built(DraftingFixV2-Final, Drafting) Draft writing (AI)Live on the app since 24 SeptemberAn agent presses Write my draft and gets their sections written in their own voice in about a minute. First real draft on the live app 24 September, in about 48 seconds. Model-written market numbers are dropped while no market data exists. Limits: 5 drafts per agent per day, $10 a day for the whole app, $20 in total. Before 24 September this item counted as built on test runs outside the app; the button agents use was built 23 to 24 September.

What it is: The AI step that writes the newsletter draft from the agent's intake and voice profile.
What's left: Nothing left to build for drafting. Two low findings in its filters (a price written without a dollar sign, a dash look-alike in the barred name) wait on Billie: fix after the demo, or accept.

Built(DraftingFixV2-Final, D6) Draft review screenLive on the app since 24 SeptemberRead it back opened by itself with Billie's first real draft on 24 September. Plain wording, no internal codes, and always a next step.

What it is: Where an agent reads, edits, and approves their AI-written draft before it goes further.
What's left: Nothing left to build.

Built(Release-CoreBuild1) Approve screens and approval recordLive since the 25 September release. When a reviewer approves a new agent, the page links to the state license roster, and the reviewer types what the roster showed (listed or not, name, category, registration number, expiration date). Approval opens only for Maryland-licensed agents; one not on the roster needs a written note.

What it is: The screen where a reviewer approves a new agent, checking their real Maryland license status first.
What's left: Nothing left to build. By design the app never checks a license on its own and never re-checks one later; a person reads the state page every time.

Built(P130b) Keeping each agent's data separateBuilt; needs a second real agent to prove it liveChecked from all seven kinds of account; the by-id request is written with the first screen that fetches anything by id

What it is: The rule that stops one agent from ever seeing or editing another agent's data.
What's left: Nothing left to build. The live app now holds two agent records, Billie's and the team owner's (read on 15 October); a check on the live app that neither can see the other's data has not been recorded.

Partly built(R1b) Source citations on AI-written sectionsStill being built, not waiting on a personBillie decided on 27 September: when the agent's own words state something as fact that the app cannot confirm, the drafting step leaves it out and tells the agent why, instead of marking it. The new drafting step does this; it passed review and has been in the main code since 9 October, switched off by default. The piece that spots these statements, written by an outside coding tool, is connected inside it and only chooses the words of the note to the agent; it never blocks anything. Online since 22 October.

What it is: A requirement that any factual claim the AI writes must be sourced, while opinions are labeled as opinions.
What's left: Switching the drafting step on (see P1B-05). Whether an opinion-worded claim needs a source is a legal question still open.

Partly built(K3d, K3b) Mailing address footerStill being built, not waiting on a personCheck built. A real issue takes its footer address from the database, in the main code since 3 October. On 15 October Billie chose the Severna Park office for every email's footer; the deploy tool carries that address, its suite number was corrected to Suite 205 and approved on 15 October, and it is not in the live database yet. On 9 October Billie said each agent may later change the address to their own local office; that is not built. Nothing of this is live.

What it is: The required postal address that must appear in every newsletter email.
What's left: A way for each agent to change the address to their own local office (Billie, 9 October), with checks on what is typed and a legal check, is not built. Before the first send, the corrected office address is loaded into the live database through the deploy tool after a final check.

Partly built(Port5, Port4-C) ImagesStill being built, not waiting on a personMasthead only. Section photos are in Core Build 2 (approved 27 September). The photo safety check (checking each file and removing hidden location data), written by an outside coding tool, is now in the main code and was checked by a second reviewer. Nothing is connected to it yet. Since 1 October a second piece, which decides whether an uploaded photo is accepted and where it is stored, is also in the main code and was checked by a second reviewer. Nothing is connected to it either.

What it is: Pictures in the newsletter.
What's left: Section photos: the upload screen, then connecting the safety check and the piece that decides where each photo is stored, which also needs file storage, not set up yet. Before it is connected, Billie decides whether a small preview picture some cameras store inside a photo may stay (the paid Cloudflare plan has been active since 9 October, so the free plan's processing limit no longer applies); the upload step also has to be squared with an existing test that stops the app from ever receiving audio.

Partly built(MarketProperty) Market brief (AI)Still being built, not waiting on a personLive. On the live app an admin can upload the month's market figures with a source credit, and Read it back shows them. No month of real figures has been loaded, so no brief with real numbers has been produced. In the main code (online since 22 October) a newsletter reads only figures the agent typed in themselves (Billie, 5 October); the screen for that is built but not connected, and figures an admin uploads will reach no agent until a later switch is built.

What it is: The AI step that writes a short local market update section.
What's left: Connect the agent's own market figures screen, load a real month of figures and produce the first brief carrying them. Uploading a market report file is paused since 6 October while Bright data access is pending. The reader-friendly market section (P1-33) changes how it reads. The market upload plan also holds the screen until there is a written answer on the right to use the RPR market data; the 14 October removal of the three send holds did not cover this. On 17 October Billie reported "yes" to whether the attorney's verbal OK covered using the RPR and Bright market numbers; nothing is in writing yet, and RPR's own consent is a separate matter that was not asked.

Partly built(ApprovalUnsub, CoreBuild1-Inc5) Admin run viewStill being built, not waiting on a personLive since 25 September with four of its five summary tiles (agents in the run, submitted something, drafted, held) and both lists of held items. The approved-so-far tile is left out by default; showing it is Billie's call.

What it is: The screen where a reviewer sees the whole month's run across every agent, who's approved, who's pending, what's ready to send.
What's left: The approved-so-far tile (the data exists since 2 October; whether to show it is Billie's call), the three tier cards (they count a default market-only issue that does not exist yet), and a drawn design for the per-agent list (design prompt 6, ready for Billie to run).

Partly built(Kit v5) AI cost trackingStill being built, not waiting on a personLive drafts run through it, with the spending caps set on 24 September. Held amounts that time out are now released each time an agent presses Write my draft.

What it is: Tracking exactly what every AI call costs, and refusing a call if it would cross a spending limit.
What's left: Confirm the time-out setting is filled in on the live app (not yet checked), and optionally add a scheduled clean-up so release does not depend on a draft being pressed.

Partly built(NS-A3, NS-A2) All screens to the approved designStill being built, not waiting on a personLargest single item. The five demo screens were measured at the approved design on 20 September. Since then the last set-up screen (You are set) and the This month fixes went live, but the screens have not been re-measured against the design, and parts nobody has drawn still need a design pass. On 25 September Billie approved the design for the phone flow (one question per screen, with a talk button). Parts of it are built since: one question per screen on Your month (26 September) and the talk button brought to that design on every screen that has it (15 October); its phone menu was brought to that design and passed review (15 October). On 27 September the four Your month design pieces (show all, summary, sticky save status, page title) were built and passed review (f2dfffa, 3ca452b). None of this is live yet.

What it is: Making every screen in the app match the approved visual design, not just work correctly.
What's left: The largest single item in the plan. The remaining screens still need to be brought to the design and measured.

Partly built(Wording3, Fix1, Port4-C) Reader-friendly market section (one email, three doors)Still being built, not waiting on a personApproved as build work on 27 September. Three supporting pieces (last year's matching figure, a reply-to-your-agent link, and the reader-friendly parts with placeholder wording), written by an outside coding tool, are now in the main code and were checked by a second reviewer. Since a fix on 28 September, a value filled into the reader-friendly parts is never filled in a second time. Nothing is connected to them yet. A first attempt at the whole section also came back from an outside coding tool late on 27 September; by its own account it is not complete, and nobody has checked or reviewed it yet. On 5 October the reader-friendly wording was rewritten from two reviewers' notes and landed in the main code after a second review. This part now has a limit of 1,000 words (Billie's decision); every figure names its month; a year-earlier comparison prints only when it is the same month a year earlier from the same source; and a figure that does not look like the app's own numbers is refused, so it can no longer read as 22 days days. It is still not connected to any screen or sender. Three gaps found then were closed in later reviewed rounds, as the current code shows: an RPR upload now uses RPR's own label for its days figure, a figure of exactly 1 reads 1 day, and the 1,000-word limit is checked when the section is built, not only by tests.

What it is: Rewrites the market part so any reader can follow it: one email for everyone, with a clear part for buying, selling and owning a home.
What's left: Connect the section to a screen and the sender, the agent's stored closing line is already kept in the agent's own section row (no database change), then a design pass.

Partly built(BS-2, HeatmapCron, Port4-B, ClickHeatmap-FIX2, +2 older) Tap recording to find hard-to-use screensStill being built, not waiting on a personAdded 27 September at Billie's request, not in the plan. Since 28 September the tap recording, the change that also records the screen size, a fix that deletes taps older than 90 days, and a new daily run that does the same were all added to the main code, each checked by a second reviewer; since 11 October the daily run no longer deletes taps, because the scheduled run now only runs the send timer. The piece that turns taps into the heat map is in the main code too. The recording, its notice and the tap viewer are in the app behind a switch that is off; the heat map piece is not connected; nothing of it is online. Its database change (0013) was applied to the live database on 5 October, and the online app does not use it. On 1 October Billie decided that, for now, taps are not deleted automatically: the 90-day limit stays in the code, and he deletes the tap history himself when he is ready. That is a deliberate choice, not a missing piece. The consent wording came back from legal review on 27 September and is not in the code yet; the notice still uses placeholder words. On 18 October the code was changed to match that decision, and both changes passed review and landed in the main code: the tap viewer hides taps older than 90 days instead of deleting them, and the saving path no longer deletes anything. At 5,000 saved taps an agent's new taps are not saved until taps are cleared (Billie chose to keep the 5,000 limit). The delete code stays in the file, unused, for the clear button. Recording is still off.

What it is: Records where agents tap in the app (the screen, what was tapped, where on the screen, the screen size and the time) so the VYBE team can see which spots are hard to use. It covers agents using the app only, never newsletter readers, and never what anyone types. Each agent sees a notice first, and nothing is recorded without their yes. Taps stay with VYBE.
What's left: The code now matches Billie's 1 October decision (18 October): nothing deletes taps on its own, and the notice makes no promise about deleting taps after 90 days (keep it that way). New viewer wording is needed before recording is ever switched on, and the attorney's answer on keeping taps with no end date. Build the two admin controls Billie asked for on 1 October, a switch to turn tap recording on and off and a button to delete the tap history when he chooses; neither is built yet. Put the final consent wording in, add a link on the Profile page to change the answer, make the recorded yes cover every word on the notice screen, add a check against form fields named from client data, and Billie writes down that tap data is never used to grade or rank an agent. Connect the heat map piece to the tap viewer. Billie decided it will be on for everyone during the beta and off after. Goes live with the next deploy. Billie decided on 2 October: before any clearing, an export of the taps must be confirmed, and clearing deletes only taps before a date he picks.

1b · Steve's feedback features6 of 10 built

Built(Release-CoreBuild1) First release of the feedback fixesLive on the app since 25 September

What it is: The first four fixes from Steve's feedback, including saving when you click out of a box.
What's left: Nothing left to build.

Built(ContainmentInc2-Fix1) Check for made-up content

What it is: Marks any sentence in a draft that is not in what the agent told us, and refuses a draft it cannot check.
What's left: Goes live with the next deploy, the paid Cloudflare plan is now active on the app's account (read on 9 October); this still waits on the deploy steps.

Built(CoreInc34-TalkButton-Fix1) Talk button on Your month

What it is: Tap to talk instead of typing; the words go straight into the box. The app never receives the audio.
What's left: Goes live with the next deploy. Before release: a real-phone check, a screen-reader test, and the iPhone Safari header result.

Built(CoreInc4b-PhonePaging) One question per screen on phones (Your month)

What it is: On a phone, Your month shows one question at a time with Back, Next and "N of M". Desktop is unchanged.
What's left: Goes live with the next deploy, the paid Cloudflare plan is now active on the app's account (read on 9 October); this still waits on the deploy steps. Before release: a check on real phones, including whether the phone asks for the microphone again after each Next.

Built(BS-18, CX11-Fix1, Combined, CoreInc6-AboutYou) About you pagePage built, reviewed and in the main code (0055c40, 3ca452b). Since 27 September the main code also removes the listed family names from the other About you answers when sharing family is off (2c01601). Its database change (0010) was applied to the live database on 5 October. On 6 October the two remaining pieces landed after review: refusing a save older than the stored one, and the talk button on short word answers. Since 9 October the family switch also covers Your month answers. Online since 22 October.

What it is: A page where an agent tells the app about themselves once, with the talk button and phone screens.
What's left: Nothing left to build. Before release: real-phone checks. Goes live with the next deploy.

Built(NS-A4b, NS-A4, NS-A1) Talk button and Read it back to the final designThe talk button now matches the approved 25 September design on every screen that has it: the privacy words sit beside the button on wider screens, "How recording works" has its own line and goes back to the screen it was opened from, and a keyboard user's focused button no longer hides under the sticky top bar (measured in a real browser: 57 times before, 0 after).

What it is: Bring the new screens to the approved design.
What's left: Nothing left to build. The read-through confirmation Billie asked for on 15 October (an agent confirms they read the whole draft before Approve unlocks, on the page and on the server) and the legal read's "your VYBE account" wording on the two lines that record the press and the approval are both in the main code and passed independent review. Live since 22 October, after the confirmation's database file (0018) was applied. Before release: a real-phone check and a screen-reader test. The caption on the administrators' Approvals screen now reads "your admin account" and is in the main code (landed 16 October after review); like the rest of the new wording it is covered only if it was in the packet the attorney read: Billie reported a verbal OK on the whole packet on 17 October, and which sentences were in it is not confirmed.

Partly built(K5H, R1B5, R1B4, R1B3, +2 older) Light thought partner (AI drafting)Still being built, not waiting on a personBuilt on 27 September and off by default. It was rebuilt on today's code on 9 October with three fixes folded in, reviewed by the second reviewer (ready to be in the main code, not ready to be switched on), and landed in the main code as 87d0b06. It is not connected to any screen that an agent can turn on, and nothing is deployed. The review found three things that must be fixed before any real agent uses it: when the About you card cannot be read the family-name privacy promise fails, an ordinary long sentence on the Family card can leave an agent with no draft and a wrong message, and the name remover also changes ordinary words and dates (a family member named June would turn June 14 into a family member 14). Decisions for all three were made. On 9 October the fixes for the first two of those problems were built, reviewed by the second reviewer and landed in the main code (6839e52): a draft is refused with a try-again message when the About you card cannot be read, a Family card the name remover cannot search is refused when saved, and names that are also everyday words, months or weekdays are left in so dates stay readable. The same review and a legal read found more to fix before any agent uses it: two messages say your saved words are safe when that is not known, the list of everyday names is too broad and would let some children's names through, and a few smaller things. Nothing is deployed. On 9 and 10 October the follow-up rounds landed in the main code after review (adcabd2 and f1ff524): Reviewed wording replaces the two messages that said your saved words are safe, the list of everyday words the name remover leaves alone was cut so popular children's names are removed again, names written after a title or a relation word (Mrs Little, Aunt Cat) are now listed to the agent instead of passing silently, and a damaged saved card no longer loses its unreadable flag when another section is saved. One more small leak was found (a name written first in an entry, like Cat (daughter)). On 10 October that fix was built, reviewed by the second reviewer, and landed in the main code (860b10c) on Billie's yes. The review found one more thing to settle before any agent uses it: if a saved About you card is damaged in an unusual way (two Family entries in the saved row), a save can leave the old card in place, and a newly typed name can then reach the AI writer with the family switch off. The app cannot cause that damage itself, and how many live cards have it is not known. Nothing is deployed and nothing can turn it on yet. Billie decided on 16 October that it is on in version 1; that is the target, and it is switched on only after the remaining steps below.

What it is: The drafting step. It writes the agent's own words in the agent's own voice, fixes spelling, grammar and clarity on its own, and never adds a fact. Every section always comes with a plain summary of what was changed and why, or a line saying nothing was changed.
What's left: A recorded decision on the damaged-card case (two Family entries in the saved row): accept it after a read-only count of live cards at release time, or fix it if any are found. The final list of everyday words the name remover leaves alone: on 10 October Billie asked the build lead to decide it, and it is a draft he can still change. The name remover already runs inside the draft step, so no separate connecting step is planned. A legal read of the final wording by an attorney (Billie reported a verbal OK on the whole packet on 17 October; whether this wording was in it is not confirmed). The test tool for the side-by-side test against the current drafting (about 180 paid AI calls) is built, passed independent review and was added to the code on 17 October; the review set conditions before the first paid call: one spending-record bug to fix, a few spending-limit gaps to close, and Billie's decision on how strict the pass rule is. Then Billie's typed go and the exact price; nothing turns it on until that test passes. The deploy tool's saved fingerprints for the two AI files it changed were refreshed, reviewed and installed on 15 October.

Partly built(BS-18, BS-3, R1a3, R1a2, +2 older) Monthly check-in pageStill being built, not waiting on a personBuilt and passed review on 27 September, after one round of fixes. On 6 October the check-in page was rebuilt on today's code, with all three questions required, and landed in the main code (reviewed READY, GATE-R1a2-cb9a303d.md; landed as 737dcbe). It is online since 22 October. On 18 October the Nothing this month choice (a last option on questions 2 and 3 that counts as an answer, so an agent with nothing to report can finish; it puts nothing in the newsletter draft) passed review and landed in the main code with the legal reader's exact words; it went online on 22 October. Since 22 October each answer holds up to 5,000 characters (it was 280) and shows its own count, like 255/5,000. On 7 October a follow-up landed (2f2bae5, reviewed READY, GATE-R1a3-f2c8b1c7.md): the check-in summary now shows what was just saved after the sticky Continue link, and the shared safety test now really exercises the check-in save. A partly done check-in already feeds the newsletter draft (pinned by a test); words typed on question 2 or 3 with no choice ticked stay out of the draft. On 8 October the design for the Nothing this month choice came back from the design tool (read, then built on 18 October). On 9 October the two route tests for removing a family member and a property landed (44a812c), and the This month card now says the issue is due Friday, October 30 (a placeholder).

What it is: A short monthly check-in, with the talk button and phone screens.
What's left: Before deploy: a design and legal review of the check-in wording, real-phone and screen-reader checks. Three small phone-screen problems found in review are queued for a cleanup job: the first press on Next can miss after a "Not saved" line, that line names Save where phones show Next, and a hint sits below what it points at. The send-date gate with the settings job (backlog 29). Goes live with the next deploy.

Partly built(BS-3, R1a2, CoreInc7-8-Fix1) Combined set-upStill being built, not waiting on a personBuilt and passed review on 27 September, with the talk button on every question the agent answers in their own words, including voice samples. On 6 October combined set-up was rebuilt on today's code and landed in the main code (737dcbe), with the first This is right now leading to the next unfinished step or to This month. Online since 22 October.

What it is: One set-up flow instead of separate steps. It is also where the agent first teaches the app who they are.
What's left: Exact-value fields (ZIP, license number, email, phone, web address) stay typed, not spoken. A legal wording check beside the new set-up buttons is still owed. Goes live with the next deploy.

Partly built(Fix1, Port4-C) Event typesStill being built, not waiting on a personThe event type list and its sorting rules, written by an outside coding tool, are now in the main code and were checked by a second reviewer. Nothing is connected to them yet. A fix on 28 September made the matching words more specific: on the review's own test titles, wrong types fell from 27 of 34 to 4 of 34, and 20 of 21 real events were still found. It is only partly cured: some Fair Housing event titles are still filed as fairs, and a second test with new titles found real events the tighter words now miss. A type is permanent once saved. Six of the type names are proposals until the design pass.

What it is: Agents pick what kind of event they are describing.
What's left: Before it is connected: Billie decides the balance between fewer wrong types and fewer missed events, after a Fair Housing review, and the matching words are fixed so Fair Housing events are never filed as fairs. Then decide how much a venue name alone should count, settle the six names, and connect it. Update 2 October: Billie approved the six proposed names. The sorter still files some events wrongly (for example a training class under Pro sports) and must be fixed before the names are used.

2 · Local events0 of 6 built

Partly built(WiringRebase-CX40, Wiring-W1W2W3, CX123) Area research setupStill being built, not waiting on a personBuilt and gated as a stand-alone module (an outside coding tool, then our own security review), and in the main code. The step that connects it to the rest of the app passed a second review and was added to the main code on 2 October. Nothing starts it yet: the monthly events run has no trigger.

What it is: Setting up which local areas/venues get researched for each agent's recipients.
What's left: Add something that starts the monthly events run (nothing does yet, and the review asked for one small test fix before that), then run it for real agents and their recipients.

Partly built(Wiring-W1W2W3, Port3-Fix1, Port2) Event gatheringStill being built, not waiting on a personEvent checker and interest filter built and gated as stand-alone modules, and in the main code. The event pipeline that uses them passed a second review and was added to the main code on 2 October; nothing starts it, and its only event source is a test stand-in. Nothing gathers real events yet.

What it is: Actually pulling in real local events to feature in the newsletter.
What's left: The part that actually pulls in real events. Lofty access is now in place through Billie's own Lofty login (15 October); the app's own Lofty connection has not been tried against a real account yet. Update 2 October: Billie added that county event pages and other local events should also be scanned. Each source needs a legal check of its terms before anything scans it, and a plan first.

Partly built(WiringRebase-CX40, Wiring-W1W2W3, CX123) Removing duplicate eventsStill being built, not waiting on a personBuilt and gated as a stand-alone module (an outside coding tool, then our own security review), and in the main code. Since 2 October it is connected inside the monthly events run, which passed a second review. Nothing starts that run yet.

What it is: Stopping the same event from being listed twice.
What's left: Nothing further to connect: the monthly events run already uses it. It does its job once something starts that run and real events are being gathered.

Partly built(WiringRebase-CX40, Wiring-W1W2W3, Port2) Locating each contact on the mapStill being built, not waiting on a personBuilt and gated as a stand-alone module (an outside coding tool, then our own security review), and in the main code. The step that stores each contact's map location passed a second review and was added to the main code on 2 October; nothing starts it yet. The call to the Census map service stays switched off until a privacy decision: until then each contact is placed at the center of their ZIP code, and their street and city are removed first.

What it is: Placing each recipient on the map so nearby events can be matched to them.
What's left: Connect it to real contacts. One open check: the Census "no match" and "tie" answer layout is not yet confirmed against the live service.

Partly built(WiringRebase-CX40, Wiring-W1W2W3, CX123) 20-mile event filter per recipientStill being built, not waiting on a personBuilt and gated as a stand-alone module (an outside coding tool, then our own security review), and in the main code. Since 2 October it is connected inside the monthly events run, which passed a second review and filters each recipient's events. Nothing starts that run yet.

What it is: Only showing a recipient events within 20 miles of them.
What's left: Nothing further to connect: the monthly events run already uses it for each recipient. It does its job once something starts that run with real events and real recipient locations.

Partly built(Port4-A, W5, W4F, W4a1-TransportUnion) Contact consent info from LoftyWaiting on: BillieCorrected 15 Oct: this row said not started, but the check is built. Before every send the app reads each reader from Lofty and treats a Lofty unsubscribe as do not send; a reader whose Lofty answer is missing is held, never sent. A Lofty unsubscribe is also remembered as the app's own block, so clearing it in Lofty later does not restart the mail. The first send goes only to contacts carrying the opt-in tag, two at most. Separately, the piece that builds the list of readers and counts who is left out and why is in the code, and since 11 October the send timer's planning step uses it.

What it is: Pulling each contact's consent status from Lofty so the app only emails people who've agreed to it.
What's left: Never tried against a real Lofty account: every Lofty behavior is documented, not observed. Lofty access is now in place through Billie's own Lofty login (15 October); what is still needed is a test session with the real account.

3 · Content types1 of 8 built

Built(MarketProperty) Listings shown in the emailCorrected 15 Oct: this row said not started, but each agent's own listings have shown in the newsletter since 24 September: the agent enters a home (address, price, beds, baths, a short note and a link) and the email's listings section shows it.

What it is: Displaying a featured listing inside the newsletter email itself.
What's left: Nothing further in the code. The newsletter preview in the live app has shown an agent's listings since late September; the newer version that builds the newsletter for sending went online on 22 October, and nothing has been sent. Shows text and a link; no photo.

Partly built(Intake1-FU, Intake1) Three video optionsStill being built, not waiting on a personThe plan's three ways were: the agent records a video, the agent links a video, or the newsletter uses written text instead. One of them is live: since 25 September an agent can save a YouTube link for the month on the Your video page. The record-it-yourself way has since changed and is tracked in the next item.

What it is: Giving an agent three ways to include a video in their newsletter.
What's left: Billie decided on 2 October to keep all three options. The link option is built and live, and when an agent sets their market update to video, the saved link goes into their newsletter. The agent's own video is covered by the next item, and written text in place of a video still needs building and a design pass.

Partly built(Port5) Agent's own monthly YouTube videoStill being built, not waiting on a personThe earlier plan had the app upload the agent's video as unlisted; the design changed to the agent uploading it publicly to their own channel. Since 1 October the piece that reads video titles, picks the one video for the month (or reports that there is none, or more than one), and builds the code for a video player is in the main code and was checked by a second reviewer. Nothing is connected to it yet. Billie confirmed on 2 October that the agent uploads a listed video, and the new name stands.

What it is: Each month the agent films a short video and uploads it to their own YouTube channel themselves, as a public (listed) video, with the month and year at the start of its title, for example "October 2026 market update". The app finds that video by its title and features it in the newsletter. If there is no video for that month, the newsletter uses AI-written text instead. The app never uploads anything to YouTube for the agent.
What's left: Connect to YouTube to look up the agent's recent videos, which needs a YouTube access key; add a setting where the agent enters their channel; decide what happens when two videos match the same month; connect it to the watch page, whose logic is now in the code but not connected (the newsletter email carries only a link to a video, never a player); then connect it to the monthly newsletter, with the written-text fallback.

Partly built(NS-B2) Video watch pageStill being built, not waiting on a personThe logic for the branded watch page is in the code but not connected: it shows only a video the agent actually saved, plays it through the privacy-friendly YouTube player, and sends the page address YouTube needs to play it.

What it is: A branded page where a recipient watches the agent's video.
What's left: The page design (design prompt 5, Billie runs it in Claude Design), the page route that loads the agent's own video, the identification block and a privacy step (a legal wording check), and a live check that YouTube plays.

Partly built(BS-1, MarketProperty) Listings entryStill being built, not waiting on a personYour properties is live: an agent can list their own properties. One plan question is open: two listing tables exist, and the plan and the app point at different ones.

What it is: Where an agent enters a property listing to feature.
What's left: The listing table is settled (the app's own table, agent_properties; the older one stays empty), and a guard test that the app never uses the older one landed in the main code on 17 October. Then finish the listing rules in the plan.

Partly built(W4B, W4a2-R2) Agent's long-form section, word for wordStill being built, not waiting on a personThe Inspiration corner exists: an agent adds it on Your sections and writes it on Your month, and it is kept away from the AI writer so it is never rewritten. Since 6 October each reader's copy is checked at send time against the version the agent approved (connected to the send on 11 October); a copy whose words differ is held.

What it is: A section where an agent's own longer writing appears exactly as they wrote it, with no AI rewriting.
What's left: No database decision is needed any more: since 6 October the approved version is taken from the newsletter the agent approved, without a database change. The preview shown before approval cannot pass this check, because nothing is approved at that point. Not yet run on a real send.

Partly built(Port4-B) VYBE broadcast writingStill being built, not waiting on a personA checker for the broadcast text, and the piece that turns it into newsletter sections, written by an outside coding tool, are now in the main code and were checked by a second reviewer. The screen where the broadcast is written (the shared VYBE Note writer, with its on and off switch) is now in the main code and independently reviewed, but it is not online and its switch is off. The checker is still not connected to it, and two fixes found in review are owed before anyone turns a note on.

What it is: A section carrying an official VYBE-wide message, the same across every agent's newsletter that month.
What's left: Fix the two review findings and connect the checker to the writer. When the checker is connected, the app's own section rules must also run on what it produces, because the review found a few cases the checker lets through.

Partly built(DESIGN3) Design pass 3 (the email, watch and unsubscribe pages)Waiting on: BillieThe email itself is designed and built, all 18 settings an agent can pick. The watch and unsubscribe pages are still not designed, but their design prompts are written.

What it is: The visual design for the email itself, the video watch page, and the unsubscribe page.
What's left: The watch page's design prompt (design prompt 5, written 15 October) waits for Billie to run it in Claude Design. The unsubscribe page's design prompt (drafted 2 October) waits for a legal wording check of its layout, then Billie's run.

4 · Sending4 of 13 built

Built(CB-3) Compliance checks on every version sentNeeds the paid Cloudflare planEach reader's own copy is checked against the ten compliance rules at the moment it is about to go, and the Send press checks a sample copy first. A copy that fails a rule is held, not sent. On 11 October a bug was found and fixed where a random link code could look like unfinished text and hold a good copy. Not yet run on a real send.

What it is: Making sure the 10 compliance checks run again on the exact final version before it goes out, not just when it was drafted.
What's left: Nothing further for this item in the code. It has not yet run on a real send.

Built(W4C, W4B, W4a2-R2, PackLoader, +8 older) Approval locked to the exact approved contentNeeds the paid Cloudflare planLanded in the main code on 2 October after review by a second reviewer. The same day it was changed to Billie's decision that only the agent approves their own newsletter, from their own sign-in, with no separate reviewer and no administrator. Smaller gaps found in later reviews were fixed and landed on 3 and 4 October. Since 11 October the agent approves on their own Your issue page, and before every send the app checks that what goes out is exactly what the agent approved. The database changes it needs were made to the live database on 5 October. On 16 October Billie decided that once a newsletter is edited, the earlier approval never counts again and the agent must verify again. He accepted for the first version that if an agent changes it back to exactly an earlier version, the app says so and asks for one small change before approving again, because approving the same content twice is refused by design. The send refuses in that case, and both Your issue and Read it back tell the agent why. Not yet run on a real send, and nothing of it is online.

What it is: Guaranteeing what actually gets sent is byte-for-byte what a reviewer approved, not something edited afterward.
What's left: Nothing further in the code. Billie answered the open choice on 16 October (see the note). The wording of the line the agent reads in that case is a draft that has not been finalized. Not yet run on a real send.

Built(W4E, W4D, W4C, W4B) Never sending twiceEach reader has one record per send, a second press of Send is refused, and a reader whose result is unclear is never tried again, so the app cannot send the same person the same issue twice. An agent who also emails those readers by hand from Lofty can still cause two copies; the send screen says so. Not yet run on a real send.

What it is: Stopping the same newsletter from accidentally going out to the same person twice.
What's left: Nothing further in the code. The resend switch is a later job. Not yet run on a real send.

Built(W4E, W4D, W4C, W4B) Send log and audit logEvery send keeps one record per reader (what happened to that reader: waiting, sent, held, or outcome unclear), and a send report is written to the permanent audit log after each timer run. The send screen reads from those records. Records of real deliveries will exist only after a real send.

What it is: A permanent record of what was sent, to whom, and when, for compliance and troubleshooting.
What's left: Nothing further in the code. No real delivery has been recorded because nothing has been sent.

Partly built(W4E, W4D, W4C, W4B) Sender serviceWaiting on: BillieNeeds the paid Cloudflare planThe sending step now exists in the main code: a timer that every five minutes checks the approved issue and sends each reader their own copy through the Lofty connection, one reader at a time, and keeps retrying with longer waits when Lofty is slow. It passed four independent reviews on 10 and 11 October. It has never been run against a real Lofty account, the timer is switched off, and the app has no Lofty key yet.

What it is: The actual piece of code that sends an email out to the internet.
What's left: A test session against a real Lofty account, the deploy itself, Billie's yes to switch the send timer on (the deploy kit updated on 15 October keeps it off), and Billie's own go-ahead. Sending to a real reader stays blocked until then. The written broker and lawyer answers no longer hold it: on Billie's instruction that hold was removed on 14 October, and no written answer is on file.

Partly built(W4E, W4D, W4C, W4B) Sending through LoftyWaiting on: BillieThe code that sends through Lofty exists and passed independent review: it asks Lofty about each reader before sending, keeps off anyone Lofty shows as unsubscribed, and tells the agent plainly when Lofty refuses the connection. It has only been tested against a stand-in for Lofty, never a real account.

What it is: Routing the send through Lofty so it uses VYBE's existing contact and consent records.
What's left: A test session with a real Lofty account, including a check that Lofty's own one-click unsubscribe header works. Lofty access is now in place through Billie's own Lofty login (15 October).

Partly built(W4a2-R2, W4a2-SendLoader, CanaryRebase, Port5, +1 older) Send queueStill being built, not waiting on a personNeeds the paid Cloudflare planThe pacing rules and the send planner are in the main code. On 2 October the send queue itself, with the agent's own test copy and a resend switch, also landed after review. Nothing is connected to it. On 6 October the send loader landed in the main code, not connected to anything: it prepares one agent's send (the approved text, one unsubscribe link per reader, each reader's own copy checked by all ten compliance checks) and still holds every reader until the broker and attorney answers exist. Nothing sends. On 11 October the send screen with its Send button and the 5-minute send timer were added to the main code after four independent reviews (a short Lofty outage no longer ends a send); the code went online on 22 October with the timer off. On 14 October the hold waiting on the broker and attorney answers was removed on Billie's instruction, after a full independent review; no written answer is on file, and every other check still applies.

What it is: Pacing sends out so they don't all fire at once and don't overwhelm the sending service.
What's left: The settings screen (the test-copy opt-in and the resend switch), a verified agent email address, an alert to the agent and to Billie when a test copy fails, then the deploy-kit update and Billie's go-ahead.

Partly built(BS-4, OO-1b-2, OO-1b-1, OO-1a) UnsubscribeWaiting on: BillieLink built. The unsubscribe page, with an optional feedback form, is in the main code. On 3 October the app's one-click email header was fixed to carry one link that serves both the page and the one-click button, after legal review found the standard wants one; when sending goes through Lofty, Lofty adds its own one-click header instead, and the app's link is in the email's footer. Since 11 October each reader's copy carries its own unsubscribe link, made by the send step. A person unsubscribed in Lofty is also remembered in the app's own list, so clearing the flag in Lofty cannot restart their mail, and unsubscribe codes can no longer be mistaken for unfinished text. On 15 October Billie decided an unsubscribe follows the email address, not the person, and covers the newsletter only; because Lofty picks which address it sends to, the app now blocks every address the reader had when that email went out, and that change passed review the same day. Online since 22 October. On 19 October the page's optional third question was added and passed review: "What would make you want to get this newsletter again?", in a box of its own. The answers go to a new database table (applied on 22 October) that holds no email address, no code that identifies the reader and no time of day, and the unsubscribe never depends on it: if the table is missing the reader still sees "You are unsubscribed." It went online on 22 October.

What it is: A working link that actually removes someone from future newsletters.
What's left: The third optional question is built (19 October); it is online since 22 October with its database file (0020) applied, and nothing yet shows anyone the answers. The form already asks why they left and what they liked and did not like, never blocks unsubscribing, and saves what is typed. Billie also chooses how the page behaves: one button that confirms (the current setting) or unsubscribing as soon as the link is opened. The way back for readers who unsubscribed is in the code but not yet connected (15 October): a link their agent sends, which works once for 7 days, and a page where only the reader's own button press records the yes. The agent's own button on Your issue is built (16 October) and went online on 22 October, but the app has no Lofty key, so it cannot reach any reader. Before a Lofty key is added: a check at the Lofty test session that the agent cannot open the reader's link, (the final wording from the legal read and the check that the newsletter can really reach the reader were added to the code on 16 October). Then a legal wording check of the final pages and a check once it is online.

Partly built(Port4-A) From line shows the agent as senderStill being built, not waiting on a personWhen sending goes through Lofty, Lofty sets the sender line itself: the test email sent through Lofty on 2 October showed the agent's own name and email address as the sender. The app cannot change it on that path. The app's own piece that builds a sender name safely (quoting and length limits) is in the main code and was checked by a second reviewer; it matters only if the app ever sends another way.

What it is: Making sure the email looks like it's from the agent, not from a generic VYBE address.
What's left: Check the sender line again in the real Lofty test session. Whether the name shown should be the agent's display name or the name on their license is a question for the legal wording check; on the Lofty path it is whatever name the agent's own Lofty account uses.

Partly built(BS-5, NS-B2) PDF versionStill being built, not waiting on a personLofty's documented send call takes no attachment, so a print-ready version that a browser saves as a PDF was built instead. It keeps the footer and the identification block, carries no unsubscribe link, and never prints a reader's private unsubscribe address. On 19 October it was connected: a text link on the Your issue screen, "Open a printable copy", opens the agent's own approved newsletter as a clean page they can print or save as a PDF (it passed review and landed as 7ea5cad and 57460ab). It shows only for an approved newsletter, never for sample data or another agent's, and a strip at the top, hidden when printing, tells the agent not to email the copy to anyone who unsubscribed or asked to stop. It went online on 22 October.

What it is: Letting an agent send the newsletter as an attached PDF instead of an HTML email.
What's left: The link is connected and a headless browser saved a Letter-size PDF with the month in the title. Still to do: a check on a real phone and a real printer. A true attached PDF would need a new library or a paid rendering service; neither was added.

Partly built(BS-1, NS-A1) Email authentication against spam foldersStill being built, not waiting on a personCorrected 15 Oct: this row said not started. The test email sent through Lofty on 2 October passed all three checks receivers use against spam (SPF, DKIM and DMARC), read from the raw message; the domain's DMARC policy is set to none, the mildest setting. A checker that reads these settings is in the code, unwired; its known false passes were fixed on 15 October (reviewed); the three narrower malformed shapes it still let through (a repeated redirect, a repeated exp and an empty exp) were fixed and passed review the same day, so it can now be trusted as a go or no-go check; it is not connected to anything yet. (This row said they were still let through until 17 October; that was out of date.)

What it is: Technical email authentication (SPF/DKIM/DMARC-type setup) so newsletters don't land in spam.
What's left: Connect the checker to something that reads the real domain's settings before a send (nothing calls it yet). The one test the checker was missing, which holds the standard's own example, landed in the main code on 17 October. A stricter DMARC policy than none is the domain owner's choice, not a code task.

Partly built(BS-1, CS2, CS, WiringRebase-CX40) Bot protection on login and unsubscribeStill being built, not waiting on a personTwo pieces landed in the main code. 2 October: a piece that decides whether a request looks like a bot (a rate limit, a hidden trap field and a too-fast check). 9 October: protection against forged form posts on the five older screens (Your month, Your voice, Your sections, Where you work, Your properties), and the hidden trap field on the unsubscribe feedback box only. Both were reviewed by the second reviewer and landed. Nothing is deployed. Sign-in is a link to Auth0, so there is no form here to guard. On 9 October a follow-up of test and safety fixes also landed after review: the new tests no longer time out, no test can pass by accident on a refused form post, and the Your newsletter page checks identity once instead of twice. The same day an older test that timed out about 1 run in 5 got a longer time limit (reviewed); the full test run still fails now and then on a slow computer, in other tests.

What it is: Stopping automated bots from hitting sign-in or the unsubscribe link.
What's left: Whether Auth0's own attack protection is on for sign-in (not checked). A real-browser walk of the five screens. A form token on Write my draft landed in the main code on 17 October after review (the builder's own recommendation; you can still say no). Online since 22 October. A person who presses it from a page left open since an earlier sign-in gets a plain error screen with no words and no link, and a reload fixes it; the five older screens do the same, so one later fix will cover all six. A valid unsubscribe is never blocked, slowed or bot-checked, so the unsubscribe itself is not guarded.

Partly built(CanaryRebase, Port4-A) Small test send before full releaseStill being built, not waiting on a personNeeds the paid Cloudflare planRedesigned to Billie's 1 October design: each agent can switch on a test copy that goes to their own email first. The code landed on 2 October. Since 11 October the Send button refuses to send for an agent whose test copy is switched on, because sending through Lofty gives no delivery answer to confirm the test copy arrived.

What it is: Sending the agent's own test copy first, then releasing to their clients only once delivery to that address is confirmed.
What's left: Needs a verified agent email address (Billie, 2 October), alerts to the agent and to Billie when a test copy fails, a settings screen to switch it on, and a way to confirm the test copy arrived (Lofty's answers: can it send to the agent's own address, and does it report delivery). The test copy needs a working stop link and the normal footer.

5 · Scale-up0 of 4 built

Partly built(Fix1, Port4-B) Automatic monthly cycleStill being built, not waiting on a personThe calendar piece that works out each month's run dates from a send date, written by an outside coding tool, is now in the main code and was checked by a second reviewer. A test added on 28 September runs it on a computer set to a different time zone, closing a testing gap the review found. Nothing runs it yet.

What it is: The system reminding every agent, every month, that it's time to build their newsletter.
What's left: Build the monthly trigger that uses it. Billie decides whether it also sets a due date for the agent's answers and refuses a reminder before the month's form opens.

Partly built(NS-B2) Run manager (reminders to agents)Still being built, not waiting on a personThe schedule logic is in the code but not connected: each agent's own send day and time and their own reminder time, correct across daylight-saving changes, checked against an independent clock at 6,572 points.

What it is: Reminders to agents about their monthly input, and each agent's own send timing.
What's left: The settings design (design prompt 3B, Billie runs it), storing each agent's schedule, the reminder sender, and Billie's answer on whether an agent can turn reminders off.

Partly built(NS-B2) Onboard 160 agents, dashboard, recruiter demoStill being built, not waiting on a personLoading agents from a spreadsheet is in the code but not connected: it checks each row with the same rules as agent sign-up and reports one reason per refused row. It is deliberately NOT tied to the administrator invite, because a used administrator invite would make each agent an administrator. A leadership summary that returns counts only, never a reader's details, is in the code too.

What it is: Bringing all of VYBE's agents onto the app, plus a dashboard for leadership and a demo used to recruit new agents to the brokerage.
What's left: The admin page design (design prompt 6, Billie runs it), an agent invite flow (the agent invite email has been on hold since 18 September), wiring the leadership counts, and the recruiter demo (not started).

Partly built(NS-A1) Final end-to-end testStill being built, not waiting on a personA local test now runs the whole first-send chain through the real routes with a stand-in for Lofty: a reader who unsubscribes from their own delivered email is never sent again, while the other reader is. A written plan for the one real run was drafted and reviewed; the review found steps to fix before it can be used.

What it is: One full real run, start to finish, before calling the whole system done.
What's left: Correct the first-run plan (the pre-send test copy check, the release pin, the AI key and spending limits, and the other items the review lists), then the one real run itself after the deploy.

Waiting on the paid Cloudflare plan

Cloudflare's free plan allows 10 milliseconds of work per request. The paid plan (Workers Paid, $5 a month per account, read on Cloudflare's own page on 22 September) allows 30 seconds by default. On 5 October the account's dashboard showed the free plan. Billie said on 15 October that the card is now on the account; whether the paid plan has been switched on has not been checked since. The items below are the ones whose recorded measurements or design put them over the free limit. Separately: the paid plan has been active since 9 October, the database changes were applied on 5 October and on 22 October, and the new version went online on 22 October.

P1-03 · Email renderer, per agent and recipient (built). Measured on 24 September: building the email preview took about 65 to 85 ms of work per request when warm and 140 to 220 ms on the first request after a restart. The free plan allows 10 ms (error 1102).
P4-01 · Sender service (partly built). Expected, not separately measured: this step builds or checks each email with the same code, so it needs the paid plan too.
P4-03 · Send queue (partly built). Expected, not separately measured: this step builds or checks each email with the same code, so it needs the paid plan too.
P4-04 · Compliance checks on every version sent (built). Expected, not separately measured: this step builds or checks each email with the same code, so it needs the paid plan too.
P4-05 · Approval locked to the exact approved content (built). Expected, not separately measured: this step builds or checks each email with the same code, so it needs the paid plan too.
P4-13 · Small test send before full release (partly built). Expected, not separately measured: this step builds or checks each email with the same code, so it needs the paid plan too.

What is on Cloudflare today

The app is live. Since 23 September the real app runs on Cloudflare with Google sign-in and a working database. The version online now went up on 22 October and carries everything landed in the main code through that day except the shared VYBE Note writer (landed in the main code afterwards, switch off) and the video watch page. The database itself is up to date: on 5 October the five later database changes were applied to the live database, one at a time and each checked (49 tables, up from 39); the online app does not use them yet. What holds back the new version is the paid Cloudflare plan (the free plan allows 10 milliseconds of work per request, and the email preview measured 65 to 85). The account's dashboard showed the free plan on 5 October; Billie said on 15 October that the card is now on the account, and whether the paid plan is switched on has not been checked since. Putting the new version online also needs a final review of the exact package and Billie's yes. Sending is built in the code but switched off (no timer and no Lofty key), so nothing can be emailed from the live app. Taken from the deployment and status records of 5 October 2026.

On CloudflareStoryboard pageThe page Steve reviewed. Anyone with the link can open it; it is hidden from search engines.

On CloudflareStoryboard feedback storageHolds notes typed into the storyboard. It can only receive notes; nothing in it can be read back over the internet.

On CloudflareNewsletter databaseBrought up to date on 23 September, then on 25 September with the license-record change, the 18 section types and 33,791 ZIP code areas. On 5 October the five later changes (About you and the check-in, newsletter approvals, unsubscribe feedback, tap recording and the send records) were applied, one at a time and each checked: 49 tables, up from 39. They only add empty storage; the online app does not use them yet. On 24 September it held one admin and one active agent, both Billie. AI spending caps of $20 were set on 24 September.

On CloudflareThe app itselfLive at vybe-newsletter-app.tekngoeak.workers.dev since 23 September. Since 25 September it serves version 1c3eddf5, the reviewed build 33fda64 (Core Build 1, the phone menu and Steve's first four fixes). Every screen past the sign-in page needs a Google sign-in.

PartlyProtection against forged form posts (CSRF)Live on the admin screens and the Your video page, in the version online since 25 September. The same protection for the five older agent screens (Your month, Your voice, Your sections, Where you work, Your properties) was added to the main code on 9 October after review, and went online on 22 October.

On CloudflareMarket data upload and propertiesLive since 24 September: the admin upload for monthly market figures with a source credit, and the agent's Your properties page.

Not thereFile storage, send queue, access protection, custom web addressNot set up. The card is now on the account (Billie, 15 October), so this no longer waits on a payment method. The sending built so far does not use a Cloudflare queue: it runs on a 5-minute timer and the app's own database, and the timer is switched off.