Propertyware: now vs. later
Pipeline: Steve (Propertyware, new PMS) and Brad (AppFolio, same rails as Vanessa). Should we build the Propertyware integration now or delay it? Context: the current milestone is proving the agent runs Vanessa's WO loop solo — see vault/decisions/2026-05-31-minimum-product-before-expansion.md.
Recommendation — delay
Delay Propertyware. Do Brad next.
The current question is "does the agent's autonomy generalize beyond Vanessa." Brad answers it on the same rails with one variable changed; Propertyware answers nothing new while costing a full new integration. Sequence: finish solo-on-Vanessa → Brad → Propertyware as a deliberate pluggability project. One open variable could flip this — see bottom.
The two columns
Build Propertyware now
Steve onboarded in parallel with the Vanessa proof.
Pros
- Locks Steve before warm goes cold. A trial left waiting can churn.
- Forces PMS-pluggability early. The eventual moat is being PMS-agnostic — build the abstraction while there are only 2 PMSes to reconcile, before AppFolio assumptions calcify.
- Stronger market story. Two PMSes ≠ single-vendor dependence — matters for a fundraise/YC narrative.
- Surfaces what's truly general vs. AppFolio-specific in the agent, earlier.
Cons
- Confounded experiment. Tests autonomy and a brand-new integration at once — if it's rocky you can't tell which broke.
- Net-new code both ends. No reports API for intake, no WO-Texts widget for dispatch — days-to-weeks of plumbing.
- Breadth before the thesis is proven. The exact trap named in the wedge decision.
- Unpaid upside. Steve is a free trial — real cost, zero revenue at risk.
- Splits focus from the solo-on-Vanessa proof, which is the actual milestone.
Delay Propertyware
Brad (AppFolio) is the next customer; Steve waits.
Pros
- Clean experiment. Brad isolates "does autonomy generalize across customers" with one variable.
- Cheap next step. Brad is config on existing rails — creds, vendor roster, properties, chat-guid — not new code.
- Compounds the proof asset. Two AppFolio customers running solo = "works beyond the first warm customer" (the YC ask).
- Keeps focus on the binding constraint. Defer breadth until there's something worth generalizing.
- Better architecture later. Propertyware becomes a deliberate pluggability project, not bolted on under trial pressure.
Cons
- Steve may lose interest while waiting.
- Over-fit risk. The longer the agent stays AppFolio-only, the harder the eventual abstraction.
- Narrower market story if you're raising on a single-PMS proof.
- Depends on Brad being real. If Brad is soft, delaying Steve could leave no active second customer at all.
What actually decides it
- The milestone is autonomy, not breadth. Propertyware advances reach; it does nothing for "can the agent run a loop solo" — the open question right now.
- Clean > confounded. Brad changes one variable (customer); Steve changes two (customer + PMS). You learn more, faster, from the clean test.
- Cost asymmetry. Brad ≈ configuration. Steve ≈ a whole new intake + dispatch layer. Same "+1 customer" slot, ~10× the build.
What would flip it
Relative readiness of Steve vs. Brad.
If Steve is hot and ready to pay while Brad is a soft lead, the revenue + "a real second customer in hand" logic could override the clean-experiment argument — a paying Propertyware customer beats a hypothetical AppFolio one. The strategic case assumes Brad is real and roughly as ready as Steve. Settle that before committing.
Delaying Propertyware ≠ dropping it. It's sequencing it behind the proof it depends on. The pluggable-PMS surface is still the long-term moat — it's just not what proves the product this quarter.