Skip to content

Layer 5: Execution

See the system index for how this layer fits the whole system.

Purpose

Apply everything above to a specific building, on a specific cadence, with specific owners. This is where the system meets a real market like Salem or St. Louis.

Research lineage

  • Multifamily lease-up marketing, the direct analog to our cold-start problem: Resident360 new-construction lease-ups and Rentsync absorption pacing. Filling a new building to stabilized occupancy (90 to 95 percent) in 6 to 12 months is an established discipline with a phased timeline, pre-leasing of a waitlist before doors open, budget tied to the absorption curve rather than to calendar milestones, and leasing velocity (units per month) as the operating metric.
  • Amazon PR/FAQ, Working Backwards, for the form of the alignment-facing documents (investors and Paul): a short narrative that starts from the customer and the outcome.

What plugs in here

  • Market instances: cold-start-instances/_template.md and the per-market files created from it.
  • Cadence and roles: the periodic retros in ../4-learning-system/runs/ and the running ../../log.md.

The lease-up phase timeline (to fold into instances and the playbook)

This is the gap the research exposed. The cold-start motion should run on a phased timeline borrowed from lease-up, with the channel mix and budget shifting by phase:

  • Pre-open: build a waitlist roughly 90 days before opening, capturing high-intent leads.
  • Grand opening: convert the waitlist first, with professional assets in place.
  • Stabilize: paid plus local plus referral, pacing budget to the absorption curve, until the building reaches roughly 90% occupancy.

Leasing velocity (move-ins per month) is the operating number, and it is the same as the cold-start North Star in Layer 2.

Cadence and roles

Cadence. A recurring marketing sync on a fixed interval reads the scorecard (spend → visits → move-ins → occupancy), reviews any running experiment against its pre-committed decision rule, and picks the next one or two levers by ICE. Results are logged in ../4-learning-system/runs/. The sync becomes a skill once the method stabilizes (deferred until then, to avoid freezing a process we are still shaping).

Roles.

  • Aaron — internal and system work: the growth model, the scorecard, experiment design, and the ad accounts (he runs them).
  • Community manager (e.g. Matador in Salem) — runs the location, the tours, the close (~80%), and local community; logs tours reliably so the close rate becomes measurable going forward.
  • Juan — customer-facing contact.

Market instances

  • Salem — populated: the worked example, carrying occupancy (57%, 28 of 49), the back-calc, the diagnosis (front-door collapse from the ad shift), the committed lane call, the first experiments, and the scorecard.
  • St. Louis — next building; copy the template when timing firms up.
  • Template: cold-start-instances/_template.md.

Gaps and next steps

  • Done (2026-06-23): Salem instance populated with real numbers; cadence and roles written above.
  • Add the lease-up phase timeline (pre-open / grand-opening / stabilize) to the instance template and the playbook, so future buildings inherit a phased budget curve.
  • Decide when the recurring sync becomes a skill (deferred until the method stabilizes).

Drift fixed (2026-06-23 audit): the instance template's lane emphasis contradicted the playbook (it listed community and referral as primary and paid as mere ignition). The template now matches the playbook's committed engine: high-intent capture and targeted paid first, community and referral as the parallel second act.