Launch & Upgrade Plan

The honest position

This section describes Tour Dash as of the original plan, below. As of 19 August 2026 the database and real accounts described as missing here have shipped — see the Phase 1 Shipped report. Left as written since it is what was true when this plan was proposed.

Tour Dash today is a complete, high-quality prototype. Every screen is built, the design system is locked and applied consistently across light and dark, the code compiles clean, and it is deployed and reachable. What it does not have is a system of record — no database, no real accounts, no payments. The data on every screen is realistic sample content written into the pages themselves.

This is worth stating plainly because it changes what the remaining work is. The hard, ambiguous half of building a product — deciding what the thing does, what each screen shows, what the user can act on — is already finished and visible. What remains is well-defined engineering.

The interface has already specified the backend. Every screen declares exactly what data it needs.

Concretely: the application preview panel already expects a poster's name, rating, review count and completed-job count. The applications panel already expects a list of applicants with statuses that move to approved or rejected. The wallet already expects transactions with a type, amount, date and status. These are not guesses to be made later — they are contracts already written into the components. That is why the timeline below is seven weeks and not seven months.

Built versus simulated

A screen-by-screen read of what is real today.

Phase 0 — Launch readiness

About one week. Short, unglamorous, and worth doing before anyone outside the project sees the URL.

• Split the download. The application currently ships as one file of roughly 719 KB compressed, because the mapping library and the charting library load on every screen, including the sign-in page. Loading each only where it is used should cut the initial download by well over half. On an agent's phone in a driveway, this is the difference between usable and abandoned.
• Restrict the map key. The Mapbox key is embedded in the published application, as it must be. It needs to be domain-restricted so it cannot be lifted and billed against.
• Write the policies. Terms of service, privacy policy, cancellation policy and a fee schedule. These cannot be skipped once the platform handles payments, and the cancellation policy in particular needs to be written before it can be enforced in code.
• Production hygiene. Social preview image, search engine directives, and analytics so early usage is measurable rather than guessed at.
• Source backup. Connect the local project to its private repository so history is preserved off the machine.

Phase 1 — A real system of record Shipped

Scoped at three weeks — shipped same-day. Tour Dash stopped being a demonstration and started being a product. The platform is Supabase — a managed database with accounts, file storage and live updates included. Full detail in the Phase 1 Shipped report.

What got built

• Real accounts ✓ — sign-up, sign-in, password reset. Profiles carry brokerage, license number, service area and radius, all of which sign-up already collects.
• The data model ✓ — profiles, opportunities, applications, appointments, transactions, reviews and notifications, with access rules enforced at the database itself so an agent can only ever see what they are entitled to see.
• Photo storage ✓ — property images uploaded when posting a job.
• Server-side location search ✓ — the radius filter moved from the browser into the database, so the map stays fast when there are thousands of listings instead of three.
• Live updates ✓ — new opportunities appear on the map without a refresh. This also lays the groundwork for instant dispatch in Phase 3.
• Messaging — carried forward. Unlike everything above, no screen for it existed yet to wire up, so it's scoped as its own short pass rather than rushed in.

The migration was deliberately low-risk, as planned: the sign-in layer was swapped underneath while keeping the exact same shape the screens already expected, so no screen had to change. Then the sample data was replaced one page at a time, with the application working throughout — verified against the live app, not just compiled.

Phase 2 — Trust and money

About three weeks. Tour Dash becomes a business here.

• Escrow payments. Stripe Connect. The listing agent funds the job when they accept an applicant; the money is held; it releases to the covering agent on verified completion, with the platform fee taken at release. Neither side has to trust the other — they both trust the process.
• License verification. Sign-up already collects a real estate license number. Checking it against state records at registration is the single highest-leverage trust signal available, and it is a barrier to the low-quality supply that kills marketplaces like this one.
• Two-sided reviews. Both parties rate each other after completion, and the ratings persist and compound into a real reputation.
• Enforced cancellation windows. A late cancellation carries a defined consequence. Written policy alone does not change behavior; enforcement does.

Phase 3 — Where Tour Dash actually wins

Everything above produces a competent marketplace. It does not yet produce a reason to choose Tour Dash over the brokerage group chat that agents already use for free. These three features do — and they are stronger together than apart.

Post it, it gets covered, and you get a receipt you can forward to your seller.

Second tier, worth scoping

• Time-boxed access codes — lockbox instructions that unlock shortly before the appointment and record who viewed them. Removes the most common source of friction and of security anxiety in the whole workflow.
• Reliability score — on-time rate, no-show rate, acceptance rate and response time, shown as a badge alongside the star rating. Stars measure whether someone was pleasant; this measures whether they can be counted on, which is what a listing agent is actually buying.
• Brokerage accounts — a shared coverage pool sold by the seat to a brokerage covering forty agents. Predictable recurring revenue, a much shorter sales cycle than recruiting agents one at a time, and it solves the cold-start problem by bringing supply and demand in together.
• Coverage density layer — a live view on the existing map of where supply is thin. Useful to agents deciding where to work, and useful internally as a map of where to recruit next.

Phase 4 — Going to market

A marketplace with thin supply fails on first impression and does not get a second one. The go-to-market plan is built around avoiding that.

• One county, not one state. The existing sample data is anchored in northern New Jersey, which is as good a starting point as any. Density is what makes the product feel instant; geographic breadth at launch guarantees the opposite.
• Supply before demand. Recruit and verify a meaningful roster of licensed agents before opening posting to listing agents. The first listing agent to post a job must have it covered, or they do not come back.
• Two revenue lines. A commission on each completed job, plus brokerage seat pricing. The brokerage line is likely to be the faster path to predictable revenue and should be tested early rather than treated as a later expansion.
• A separate front door. A marketing page that explains the product and captures interest, kept distinct from the application itself. The application should not have to do the job of selling.

Summary