← All documents

Information architecture · Working draft

Eight areas, most of them built as real wireframes now — what's on each screen.

Every page the platform needs at launch — marketing site, onboarding, the agent dashboard, the Client Portal, brokerage admin, Closing Boss's own operator admin, and the public site each agent gets. §01–§05 and §07 are wireframed and running in the app today; §06 (master admin) and the provisioning plan in §08 are scope, not yet built — each section says which.

01 — Marketing site

Public, unauthenticated, sells the bundle.

ScreenWhat's on it
HomeThe bundle pitch — live listings, KeyRingOS CRM, card, one system. Pricing teaser, CTA into signup.
PricingAgent OS and Brokerage & Teams, side by side — the tables from spec.html §05, not re-derived here.
DemoA live, click-through example site and dashboard — the fastest way to answer "what do I actually get" without requiring a signup first.
For BrokeragesThe brokerage-adds-its-own-realtors pitch, separate from the individual-agent page — different buyer, different questions.
How it worksThe honest timeline from spec.html §02 — site and card fast, listings depend on the board. Sets the expectation before signup, not after.
AboutWho's behind Closing Boss — the LFG track record (business plan §01), same credibility argument used with investors, now aimed at prospective agents.
BlogSEO surface area — the ongoing-SEO commitment from spec.html §06 needs content to actually rank, not just well-structured listing pages.
Contact usFor everyone the self-serve flow doesn't fit — brokerages sizing a custom plan, press, anyone who wants a human before signing up.
Decided — nav is a mega-menu, not a flat bar. Home ships with three dropdowns — Features (5 platform areas, each linking to its own card on the page), Solutions (Solo Agents / Agent Teams / Brokerages, both pointing at Pricing today since there's still only two real plans), and Compare (5 named competitors, each linking to a real, sourced pricing card on the page, not a fabricated feature-gap claim) — plus top-level Pricing and MLS Lookup links. For Brokerages, About, and Blog are still real, planned destinations from this table — not yet built as their own routes, so they're deliberately left out of the menu rather than linked as pages that don't exist. Contact us is now partially covered by the MLS Lookup lead-capture form. The feature-area layout also changed from 8 alternating full-width sections to a tighter 5-card grid (one card per Features menu item — CRM & Unified Inbox, MLS Search Sites, eSign & Contracts, Automated Marketing, Client Portal); Tracking links and Analytics are still real, built features, just no longer their own top-level marketing sections.
MLS Lookup is a lead-capture form, not a live compatibility checker. No board- compatibility database exists anywhere in this codebase — SimplyRETS backs live listing search, not a "which boards are supported" directory. Building a real-time yes/no tool would mean fabricating that data. The nav item is real; what it opens is an honest "we'll confirm within one business day" form, same pattern as the public site's existing valuation/consultation forms.
02 — Signup & onboarding

One flow, ends in a live card even before the MLS approves.

ScreenWhat's on it
Create accountEmail + password. No MLS questions yet — that's a separate step so a stalled board approval never blocks account creation.
Choose planAgent OS or Brokerage & Teams — sets pricing and which dashboard the account lands in; every Agent OS signup gets the same feature set.
Business detailsName, license number, brokerage, headshot and logo upload — the brand inputs the templated engine needs.
Connect MLSBoard selection, membership confirmation, IDX authorization e-signature — the flow from spec.html §04, step by step.
PaymentSquare checkout — no setup fee to charge anymore; just the first month's $149 (or $189 if billed monthly).
Onboarding status"Your card and site are live; listings pending board approval" — a real tracker, not a spinner, since the wait is sometimes ~10 business days and hiding that would be worse than stating it.
03 — Agent dashboard

Six groups in the rail: Site, Manage, Marketing, Insight, and Settings behind its own shell.

Wireframed and built out module by module since this document's first pass — the groupings below are what actually shipped, not the original flat list. The rail itself stays scoped to things an agent opens often; Settings is still the one shell everything configured-once-and-left-alone lives behind (see the flag at the end of this section).

ScreenWhat's on it
Dashboard homeThe Daily Command Center — a command bar of four real numbers (active pipeline volume, new leads this week, pending closings, tasks due today), today's action items with working checkboxes, a recent-activity feed, and a pipeline mini-funnel, all live-computed off the same Contact/Activity records the rest of the CRM reads. Deliberately not a vanity-metrics page — no fabricated trend percentages, no invented real-time precision.
SpotlightRenamed from Showcase. Star, hide, or add board listings one at a time, on top of the default that every synced listing just shows automatically. Live SimplyRETS + a real Postgres table (showcase_overrides), not a fixture. The full IDX board search stays a separate, uncurated surface (Browse) — see §07.
InboxUnified thread per contact — reply, internal notes, insert an MLS listing, quick templates, book a showing, move pipeline stage, create a task — one composer, not a duplicated one per module.
ContactsList + detail. Detail reconciled to four tabs — Activity, Email (the real Inbox thread inline), Tasks, Documents — each backed by real data, not five arbitrary ones.
PipelineKanban by deal stage — separate boards for buyer and seller. Cards open an inline overlay for quick edits rather than always navigating away.
TasksThe daily action queue — one consistent checkbox as the done-control everywhere (no mixed checkbox/button patterns), a superset "all open" tab, real due-date picker.
CalendarMonth/week views over the same Contact/Activity data Tasks and Pipeline already read — no separate CalendarEvent entity. Real drag-to-add, per-event time range, reschedule logging to the contact's timeline.
Documents & e-signUpload wizard (drag-and-drop, multi-signer with on-the-fly contact creation), per-signer field checklists, a real void-delete (not a hard remove), and a signing action that's now genuinely reachable two ways — the agent's "Mark as signed," or the client's own click inside their Portal (§04).
Marketing — Campaign dashboardThe executive view of every drip/autoresponder sequence — real enrollment counts, status (Active/Paused/Draft), open rate, deep-links into the editor.
Marketing — Drip campaignsThe sequence editor — steps as a plain card list (delay label between them, not a canvas), a template library with category filters and live preview, Clone/Duplicate, a grouped Active/Drafts/Templates switcher.
Marketing — Listing alertsReal per-contact saved-search alerts (seeded off the contact's actual saved-search fields), live-recomputed matching-listing counts against real inventory, a real Preview Email.
Marketing — Listing graphicsThe one Marketing module that's fully live end to end — a real client-side canvas export (social post / story / flyer sizes) to an actual downloadable PNG, no simulated backend involved.
Insight — AnalyticsSite stats and SEO status, moved under its own Insight group alongside Tracking links rather than living flat in the main rail.
Insight — Tracking linksCreate a named short link and see its real clicks/leads, tied to the same source-attribution every other lead carries.
Settings — Site & profileBio, headshot, homepage hero, logo, and the theme picker.
Settings — Digital cardMoved here from the main rail — preview, QR code, share link, card-specific fields. Lives in Settings rather than as a daily-use screen, since it's configured once and handed out, not opened repeatedly.
Settings — Lead captureMoved here from the main rail — every way a visitor can reach out (home valuation, consultation booking, contact/inquiry forms), consolidated in one place.
Settings — TestimonialsFeatured/hidden testimonials shown on the public site.
Settings — DomainThe default subdomain is always live (see §08 for the provisioning mechanism); add a custom domain with the DNS records to point at it — verification and SSL status shown once added.
Settings — TeamAdd or remove realtors under one brokerage. Brokerage & Teams plan only.
Settings — BillingCurrent plan, invoices, payment method — Square-backed.
Settings — NotificationsNew lead alerts, weekly summary, board status changes, document signed/declined, product updates.
Settings — AccountLogin/password and MLS/board connection status.
Settings is one shell, not eight top-level rail items. Everything above sits behind a single "Settings" entry with its own secondary sub-nav once inside — same shape as Tie Out Bureau's settings pattern. Marketing and Insight followed the same shell pattern once each grew past a couple of screens, for the same reason: keep the primary rail scoped to things an agent opens often (Inbox, Contacts, Pipeline, Documents) rather than every screen flattened into one long list.
04 — Client Portal

The first screen a client sees, not the agent — tokenized, no password.

Lives outside the agent dashboard entirely — /portal/<token>, no rail, no internal nav. A per-contact token resolves the link; real lookup, not real security (no auth system backs it yet, see §08's real gap).

ScreenWhat's on it
Active transaction viewShown once a contact reaches Under Contract. The real transaction checklist as a milestone stepper, the real documents attached to that deal with a client-initiated "sign" action (the same underlying state change as the agent's own Mark as Signed), and a submit-a-question field that posts into the agent's real Inbox thread for that contact.
Nurture viewShown for every other contact. Real favorited listings, the real listing alerts that contact is enrolled in with a live matching count, and a submit-a-home-for-review field feeding the same real thread mechanism.
Invalid-link stateAn honest "this link isn't valid" screen for a bad/expired token, not a crash.
Not built — multi-transaction switcher. A client with two concurrent deals (selling while buying) needs a contact to hold more than one active deal at once. This whole platform's data model is Contact = Deal, 1:1, everywhere — Pipeline, Documents, Calendar and Marketing all depend on that. Extending it is a real, separate data-model decision, not a Portal-sized feature — deliberately deferred rather than faked with a second deal bolted onto one contact.
05 — Brokerage admin

Brokerage & Teams plan only — sits above individual agent dashboards.

A customer-facing surface — a brokerage's own office view of the realtors under it. Not to be confused with §06, which is Closing Boss's own internal operator view across every tenant. Different audience, different data.

ScreenWhat's on it
Brokerage dashboardRoster overview — every agent's status, aggregate lead activity across the office.
Manage realtorsAdd or remove agents under the brokerage plan; each still gets their own full dashboard, site and card — this screen doesn't touch their individual data, just membership in the plan.
Brokerage billingOne invoice for the whole office rather than one per agent.
06 — Closing Boss master admin · Plan, not yet wireframed

admin.closingboss.io — LFG's own operator view across every tenant, not a customer-facing screen.

New since the last pass through this document, and genuinely not started — no wireframe exists yet, this is scope, not a built screen. Distinct from Brokerage admin above: that's a customer managing their own office; this is Closing Boss's own team running the platform. Needed once there's more than a handful of tenants to keep track of by hand.

ScreenWhat's on it
Tenant listEvery agent account — plan, MLS board/connection status, custom-domain status, real lead/contact volume. Search and filter across all of them.
Platform healthMRR, active tenant count, and the same referral/sales-lead attribution PROJECT.md §10's commission math already depends on — this is the screen that makes that number answerable from data, not the CRM.
Tenant detailOne agent's account from Closing Boss's side — provisioning status, board connection history, billing state. Impersonation ("view as this agent") lives here if built — see the flag below before it does.
Impersonation is a trust surface, not a checkbox. If "log in as any tenant" gets built, it needs audit logging (who impersonated whom, when) and a visible banner on the agent's own side while it's active — designed in from the start, not retrofitted after the first support question about it.
07 — Public agent site

What a prospective client actually sees.

ScreenWhat's on it
Agent homeHero with a background image, headline, and the location-first smart search bar (see below) — the agent's own Showcase listings featured up top, generated, not built by the agent.
Search resultsFilterable list — location, price, beds, property type — the same query the smart search bar pre-fills. List-only for v1; a map view is real added scope (maps provider, clustering, bounds-based search), deliberately deferred rather than defaulted into.
Listing detailOne property — photos, details, the mandatory brokerage branding and source attribution from the business plan §09. Opens as an overlay on top of search results (Next.js intercepting routes — a real, shareable URL either way, modal only when navigated to from within the app), full standalone page on a direct link or refresh.
About / bioThe agent's profile — same content the dashboard's Site & Profile screen edits.
Contact / lead captureFeeds directly into the agent's CRM, not a separate inbox.
Digital card — public viewWhat a QR scan or shared link actually opens. Separate from the main site nav on purpose — this is a one-person handoff, not a browsing session.
Home valuation"See what your home is actually worth" — a seller-lead capture form, not a real AVM. Address, condition, upgrades, bed/bath changes since public record, timeline to sell — a longer form than a Zestimate-style tool needs, on purpose: it's what makes the agent-prepared number credible instead of competing with Zillow's free instant one. Address captured even if they abandon before finishing.
Schedule a consultationDay/time booking for a real conversation — 20 minutes, no pressure. Another lead-capture channel feeding the same CRM as everything above, managed from the dashboard's consolidated Lead Capture screen.
Buyer sign inA buyer account, separate from agent/brokerage auth entirely and platform-wide, not scoped to this agent's site — decided, see the flag below.
Saved searches & favoritesA signed-in buyer's persistent view — saved search criteria, favorited listings, notified when a new one matches. Follows the buyer across every KeyRingOS site they visit, not just this one.
Blog index & postKeyRingOS-syndicated market content, displayed under the agent's own site — see the flag below on why there's no authoring screen in the dashboard for this.
Decided — buyer accounts are platform-wide, not per-agent. One account follows a buyer across every KeyRingOS site they visit — closer to what Real Geeks' MoveTo app and Zillow itself do, and the only sane home for a future "buyer looking in a new area gets matched to an agent" feature. Real consequence for the data model, not just the UI: buyers are one of the only entities in the whole system that isn't scoped to a single agent or brokerage — CLAUDE.md's tenancy rule ("every table carries an owner") gets an explicit, deliberate exception here, not an oversight.
Decided — blog content is KeyRingOS-syndicated, not agent-authored. Matches spec.html §06's original framing: ongoing SEO is a platform commitment, not something added to an agent's to-do list. No authoring UI in the dashboard for this — an agent's site carries the content, but doesn't write it. Revisit only if agents actually ask for their own voice here; "both" (syndicated by default, optional agent posts on top) is the fallback if so, not the starting design.
08 — System

The screens everything else assumes exist — and the tenant-provisioning plan behind them.

ScreenWhat's on it
LoginEmail + password, routes to the right dashboard (agent vs. brokerage admin).
Forgot passwordStandard reset flow.

Everything below is real-build plan, not a wireframe — this whole platform is still fixture-only today (one hardcoded agent identity, no agents table, no auth), same status PROJECT.md §11 already states. Written down now so the shape is settled before it's needed, not designed under pressure once agent #2 signs up.

URLPurpose
<slug>.closingboss.ioDefault tenant address, assigned at signup — the agent's public site, listings, digital card, home valuation, and Client Portal all live under it.
<slug>.closingboss.io/portal/<token>Client Portal, namespaced under the agent's own subdomain rather than a bare closingboss.io/portal/... — a client should feel like they're in their agent's world, not a shared platform URL.
Custom domain (optional)Maps onto the same tenant via Render's Custom Domains API — every route above resolves identically once mapped, share links keep working through the switch.
app.closingboss.ioWhere an agent actually logs in and works — the dashboard itself doesn't need a separate address per tenant, only the public-facing surfaces do.
admin.closingboss.ioClosing Boss's own operator view — §06.
Real constraint the routing plan has to respect: SimplyRETS bills per board, not per agent. A signup on an already-connected board is instant; a signup on a new board triggers a real $99 one-time connection cost and isn't same-day by default (PROJECT.md §7's concentrated-vs-scattered table). The provisioning flow has to check board status before promising "live in under a second" — that promise only holds when the board's already connected.

Provisioning, sketched: signup creates a real tenants row (slug, agent identity, plan, referral/sales-lead source — required per PROJECT.md §10's commission math, missing from every version of this proposal sketched so far), checks whether the chosen MLS board already has a live connection, seeds sensible defaults (a default theme, empty CRM tables, a starter drip template), and the subdomain resolves the moment DNS + the tenant row both exist. The heavier real work isn't the routing — it's giving every fixture-backed table in this app (contacts, activities, envelopes, campaigns, alerts...) a real tenant_id and RLS policy, the same pattern already proven on showcase_overrides (migrations/0001_showcase.sql) — that migration, run everywhere else, is most of the actual build.