Objective
Live pilot with 1–2 real brokerages across 2–3 states by month 6: real agents, real clients, real transactions, real legal and financial stakes.
Key inputs
Flagged risk, in detail: earnest money (the buyer's good-faith deposit) can
legally only be held by a licensed title/escrow company, a licensed brokerage's trust account
(under a named Broker of Record), or an attorney's escrow account — never by RealEZ
directly, unless RealEZ itself becomes one of those. Each path requires state-specific
licensing that commonly takes 3–6+ months
per state, plus a bond or minimum
net worth, before you can even apply — and real estate escrow's exemption from
money-transmitter law varies by state, so getting the structure wrong risks being classified
as an unlicensed money transmitter, a serious regulatory matter in most states, not a bug to
fix later. The constraint is licensing timeline, not engineering — a trust ledger is
buildable in weeks; being legally authorized to hold the money is not, across 2–3 states
in 6 months.
Recommendation: partner with an already-licensed escrow/title company (or the
pilot brokerage's existing one) via API or manual reconciliation for Phase 1 — RealEZ's
software still owns the experience (status, reminders, timeline), while the licensed partner
holds actual custody. Treat true self-custody as a Phase 2+ project, owned by the Compliance
cofounder (not a build-team hire — see
Team): pick broker-trust
vs. title-license, recruit the right licensed person, start state applications, build
audit-grade trust accounting, get counsel sign-off before touching a real dollar.
Team (4 new FTE hires + 1 project-based)
You (part-time — architecture sign-off, not day-to-day, for now) + 1 FTE Backend Engineer + 1 FTE Flutter Engineer, plus:
- Senior Backend Engineer #2 — the tech lead
- Technical Product Manager — owns vision/roadmap now that the founder is part-time
- HR/Payroll/Admin
- QA/Automation Engineer
- UI/UX Designer — project-based, not an FTE hire
No dedicated GTM or Compliance hire — both are owned by other cofounders. No dedicated DevOps/Platform Engineer or second mobile engineer either: the tech lead covers foundations with AI-assisted tooling, and one Flutter engineer covers all 5 portals — see Team for why, and for the risk that puts on the mobile timeline.
Timeline shape
Months 1–2 Foundation & Scaffolding (CI/CD, IaC, and the security baseline required in week 1; QA starts immediately alongside, not later; repo and app scaffolding for all 5 portals; POC-level work on both pillars starts here too, not after foundations are "done") · Months 3–4 Build (POCs turn into feature-complete pillars) · Months 5–6 Harden & Launch. See Gantt.
Exit criteria
- 10–20 real transactions closed end-to-end across the pilot brokerages
- E-signature engine reviewed and approved by outside counsel, no open exceptions
- Escrow-partner trust flow running with zero reconciliation discrepancies
- Native iOS + Android apps live for all 5 portals
- Jurisdiction rules validated for all pilot states by counsel
- Pen test complete, critical/high findings remediated
Top risks
- Money-transmitter/escrow licensing arriving late or being shortcut (see the flagged risk above)
- Native mobile apps for all 5 portals resting on one Flutter engineer — a much bigger ask than Agent + Client alone, and the risk most worth watching on this plan
- Legal review as a bottleneck across e-sig, escrow, and 2–3 state pilot agreements
- Jurisdiction-rules workload across 2–3 states may still warrant using more of the remaining headcount headroom (see Team)
- The founder going part-time lands hardest here — this is the heavier-scope plan, and it now runs on the tech lead and Technical Product Manager without the founder's own hands-on time as backup capacity
Objective
Have the product ready — technically and legally-reviewable — for a live pilot with 1–2 real brokerages in a single state, contingent on Compliance and GTM (owned by other cofounders) landing their pieces on a compatible timeline.
Key inputs
Two product pillars
Everything else (auth, e-sig integration, jurisdiction rules, dashboards) is necessary infrastructure. These two get the concentrated senior engineering and design investment, because they're also a pipeline: gaps disclosed in the Transitional Document are what drive bookings through Merchant Integration.
Team (4 new FTE hires + 1 project-based)
You (part-time — architecture sign-off, not day-to-day, for now) + 1 FTE Backend Engineer + 1 FTE Flutter Engineer, plus:
- Senior Backend Engineer #2 — the tech lead
- Technical Product Manager — owns vision/roadmap now that the founder is part-time
- HR/Payroll/Admin
- QA/Automation Engineer
- UI/UX Designer — project-based, not an FTE hire
Identical roster to Full Pilot — see Team for why DevOps and a second mobile engineer stay out even with room for 8–10 at no additional cost.
Timeline shape
Month 1 Foundation & Scaffolding (CI/CD, IaC, and the security baseline required in week 1; QA starts immediately alongside; repo and app scaffolding for all 5 portals; POCs for both pillars start here too, not after foundations are "done") · Months 2–3 Core Build (POCs turn into feature-complete pillars) · Months 4–5 Test & Polish. See Gantt.
Exit criteria
- Transitional Document feature-complete and demoable end to end
- Merchant Integration live: vendor onboarding, real payments, accurate commission tracking
- 3rd-party e-signature wired into the transaction flow, signed docs stored/retrievable
- Jurisdiction rules validated for the single pilot state
- Native iOS + Android apps live for all 5 portals
- QA regression suite passing; pen-test critical/high findings remediated
Top risks
- Hiring four seniors fast enough to hit the 5-month window
- E-sig vendor contracting delay blocking backend integration
- Native mobile apps for all 5 portals resting on one Flutter engineer, on a tighter timeline than Full Pilot's 6 months
- Testing compressed into the last two months, even with QA starting earlier