The Design Registry

Business Plan 4.0

Version: 4.0
Prepared: August 2026
Status: Brand-aligned strategic, product, operating and commercialization plan
Planning horizon: 2026–2030
Publication: Public strategic source of truth; financial assumptions remain illustrative until approved

1. Executive Summary

Every professionally designed home deserves to be remembered.

The Design Registry gives the thinking, people, products and craft behind a professionally designed home one permanent place to live. During the active Project, it connects Designers, Clients and Providers around the right work and information. When the Project ends, the approved record remains.

The complete Registry manifesto is governed and maintained in the Brand Guide. This Business Plan applies that belief to the company, product, operating model and economics without reproducing the manifesto in full.

1.1 The company in one view

The Design Registry is a Designer-first technology company building the operating network and permanent record for professionally designed homes. During an active Project, the platform connects the Designer, Client and specialized Providers around one permissioned source of truth. As the work progresses, that operational record accumulates drawings, specifications, selections, approvals, revisions, commercial commitments, deliveries, installations, photographs, warranties and decisions. At completion, the Project does not disappear into an archive; it matures into the Registry for the home.

The company begins with a free, high-value operating system for independent and emerging Designer Studios. Free access is a distribution strategy, but it is also a product principle: the platform must make a Designer's life meaningfully easier before asking the Designer to participate in a paid service or marketplace transaction. Designers can bring their own Clients, Projects and Providers, preserve their own brand and operate independently.

Providers receive more than a referral inbox. Each Provider type receives a tailored operational workspace designed around the work it performs: Vendors answer product requests and update orders; warehouses receive, photograph, locate and release Items; white-glove teams execute manifests and publish day-of delivery progress; millworkers manage drawings, approvals and fabrication; trades manage scope, scheduling, changes and deficiencies; photographers manage briefs, shot lists, rights and deliverables. This operational value gives Providers a reason to keep Project status, evidence, commercial records and payments inside the platform.

Clients receive a calm, Designer-led experience for decisions, presentations, approvals, milestones, financial commitments, delivery information and the final record of their home. They see what is meaningful to them without being exposed to the operational noise, private notes, sourcing strategy or internal economics required to deliver the work.

The business monetizes the network around the free core through selected Registry-generated opportunities, Provider and product transactions, procurement and managed services, payment-related services, optional premium capabilities and future local studio programs. The model is designed so revenue follows delivered value. Marketplace participation remains optional and the Designer's relationship with the Client remains central.

The strategic outcome is not the largest collection of dormant accounts. It is a trusted network of activated businesses coordinating real Projects, creating durable records and returning because the system makes every participant's work clearer.

1.2 The business thesis

The plan rests on six connected beliefs:

1. Design work is valuable enough to preserve. The knowledge created during a professionally designed home remains useful for maintenance, replacement, renovation, warranty, insurance, resale and future stewardship.
2. The Designer is the natural centre of coordination. The Registry should increase the Designer's leverage without replacing the Designer's authorship, judgment or brand.
3. The Project is the best adoption wedge. A participant should gain value from organizing one active Project before migrating an entire business.
4. External participation requires reciprocal value. Providers will update the Registry only when its tools also reduce their own sales, scheduling, evidence, invoicing and payment work.
5. A connected record compounds. Every structured decision, Item, participant, handoff and outcome improves future service, reporting, matchmaking and intelligence.
6. Luxury is experienced as clarity and confidence. The product and brand should feel calm, precise and restrained. Technology supports the craft; it does not compete with it.

2. Company Overview

2.1 Company name

The Design Registry

2.2 Category

• Designer-first operating network and permanent home record
• Project operating system and knowledge layer
• Vertical SaaS for professional design delivery
• Private, qualified Provider network and workflow marketplace
• B2B2C Project collaboration platform
• Local studio and community infrastructure

The public category should be expressed in this order. The company leads with the Registry and the permanent value it creates, explains the Designer-first operating network second, and describes enabling software categories only when the audience needs the detail. “CRM,” “project management software,” “marketplace” and “AI platform” describe components; none is the brand's defining idea.

2.3 Mission

Help independent Designers spend more time designing by connecting the operational, commercial and physical work surrounding every Project while preserving a complete, permissioned record of its decisions, people, products, revisions, installations and outcomes.

2.4 Vision

Create the trusted operating network through which independent design studios, Clients and specialized Providers coordinate exceptional Projects—and ensure that every meaningful decision and contribution remains useful long after delivery.

2.5 Brand promise

Every professionally designed home deserves to be remembered.

The supporting product promise is:

The Project ends. The Registry doesn't.

Designers retain their brand, clients and initial design fees on projects they bring. Marketplace participation is optional. The Registry provides infrastructure and opportunity without attempting to erase the Designer’s identity.

2.6 Values

• Designer first
• Exceptional standards
• Quiet, confident service
• Respect for professional relationships
• Transparency and durable records
• Technology in service of craft
• High-quality network participation
• Human judgment supported by AI

2.7 Brand psychology

The Design Registry should create four feelings in sequence:

1. Recognition: “This understands how much invisible work goes into a designed home.”
2. Relief: “I no longer need to hold the entire Project together in my head, inbox and spreadsheets.”
3. Confidence: “Everyone sees the right information, decisions are preserved and I know what happens next.”
4. Pride: “The record feels worthy of the work and strengthens how my studio is experienced.”

This psychology applies across marketing and product. Marketing begins with the cultural truth that design work disappears, not with a software feature list. The product then proves the promise through calm hierarchy, exact records, purposeful white space, visible provenance and carefully controlled collaboration.

The brand must never make a Designer feel displaced by the platform. The Designer is the author and leader; the Registry is the structure that remembers. Provider contributions are credited without competing for the Client relationship. The Client feels looked after without seeing every operational complication. The dot represents the precise point where the people, work and record connect—and the continuity that remains after completion.

2.8 Brand experience standards

Every company surface must be:

• Calm by default: prioritize the next decision or exception instead of displaying all possible information.
• Editorial rather than promotional: use direct, confident language and meaningful hierarchy; avoid exaggerated claims and software clichés.
• Beautiful but operational: refinement must improve comprehension, not hide controls or weaken accessibility.
• Specific: name the Project, room, Item, version, person, date and consequence when they matter.
• Respectful of authorship: preserve the Designer's brand and clearly attribute professional contributions.
• Truthful about capability: distinguish released, configured, beta, planned and AI-suggested behaviour.
• Durable: consequential records are versioned, attributable, exportable and understandable years later.

3. The Problem

3.1 Designers operate fragmented businesses

Interior Designers routinely coordinate:

• Lead intake
• Client qualification
• Proposals and agreements
• Seven-Phase Project delivery
• Product and material specifications
• Construction selections
• Decorating and FF&E
• Budgets
• Procurement
• Vendor communication
• Receiving and storage
• Delivery
• Installation
• Photography
• Invoicing and payment

Much of this information remains divided across spreadsheets, email, messaging applications, shared drives, accounting systems, calendars, Vendor websites and paper notes.

The cost is not simply inconvenience. Fragmentation produces duplicate entry, inconsistent versions, missed deadlines, unclear responsibility, budget surprises and significant mental load for the Designer.

3.2 Providers operate outside the Designer’s system

Most platforms end at the Designer Studio. Warehouses, delivery companies, trades, Vendors and fabricators typically use separate systems—or no formal system. The Designer becomes the manual integration layer.

Examples:

• The warehouse receives a damaged chair but the condition report remains in email.
• The delivery company is en route, but the Designer cannot see its location.
• A millworker changes a fabrication date without updating the Project schedule.
• A Vendor sends a revised quote that must be manually re-entered.
• An installer discovers a deficiency but the issue is not tied to the specific item and room.

3.3 Emerging Designers lack operational leverage

New and mid-tier Designers may have strong creative ability but limited access to:

• Structured operating systems
• High-quality Providers
• Reliable lead sources
• Professional client experiences
• Sophisticated procurement support
• Business analytics
• Administrative staff
• Physical studio and sample resources

This limits growth and creates an uneven client experience.

3.4 Providers face inefficient sales and administration

Providers repeatedly prepare quotes from incomplete information, chase approvals, reconcile changes and wait for payment visibility. Smaller Providers may lack a practical CRM, Proposal, Work Order and invoicing system tailored to their work.

3.5 Clients experience avoidable uncertainty

Clients often do not know:

• What decision is required next
• Whether an item has been ordered
• Where an item is stored
• When delivery will occur
• What has changed in the budget
• Which Proposal or selection is current
• Whether the Project remains on schedule

The Design Registry creates a calm, selective client experience without exposing internal operational complexity.

4. Market Context

4.1 Large underlying housing economy

Canada’s housing economy is substantial. Statistics Canada reported that the net stock of housing assets reached approximately $4.4 trillion in 2025 and residential investment activity supported more than 1.2 million jobs. This does not define The Design Registry’s addressable market by itself, but it demonstrates the scale of the underlying economic system around housing. Statistics Canada, Housing Economic Account 2025

4.2 Renovation activity is widespread

CMHC’s 2024 Mortgage Consumer Survey reported that 45% of mortgage consumers had renovated in the prior three years. Approximately half of renovators spent between $10,000 and $50,000, while 35% spent less than $10,000. The $10,000–$80,000 Registry-generated lead strategy therefore targets an active middle segment while allowing the core software and Provider marketplace to serve larger projects. CMHC Mortgage Consumer Survey 2024

4.3 Costs and complexity are increasing

Statistics Canada’s Residential Renovation Price Index reported continued renovation-cost increases in 2025. Rising costs make accurate budgets, controlled changes and reliable procurement more important to Designers and clients. Statistics Canada, Residential Renovation Price Index

4.4 Software demand is established

Multiple vertical platforms now market specifications, procurement, client portals, invoicing and Project management to Designers. This validates the need while raising the competitive standard. The Design Registry must not compete solely as another specification or mood-board tool.

4.5 Market thesis

The opportunity is not merely to digitize a Designer’s spreadsheet. It is to connect the separate businesses that execute the physical Project and make the resulting network useful enough that participation becomes habitual.

4.6 Interior design industry structure

The Canadian interior design industry is large enough to support a focused vertical platform and fragmented enough to make workflow standardization valuable. Innovation, Science and Economic Development Canada reports 5,676 Canadian interior design businesses in its 2024 financial-performance dataset. Average annual revenue was approximately $314,000, while the top quartile averaged approximately $938,000. The broad spread between the typical studio and the top quartile reinforces the Registry's central thesis: many capable Designers operate meaningful businesses without the administrative leverage or integrated systems of larger firms. ISED Canadian Industry Statistics — Interior Design Services

The wider specialized-design category is dominated by small operators. ISED reports 19,945 non-employer or indeterminate establishments compared with 5,177 employer establishments in 2024. Ontario contained 8,838 non-employer or indeterminate establishments and 2,376 employers in the broader category. The Registry is therefore not designing only for established multi-user studios; the core user is often an owner-operator who must sell, design, specify, purchase, coordinate and collect payment with limited administrative support. ISED Canadian Industry Statistics — Specialized Design Services

4.7 Initial market evidence

Ottawa–Gatineau's Ontario portion had 1,135,014 residents and 474,806 private dwellings in the 2021 Census, providing a substantial first-market housing base without the operating complexity of immediately launching across the Greater Toronto Area. Statistics Canada 2021 Census Profile

Ottawa is suitable for the first operating-density experiment because the Registry can manually curate the initial network, observe handoffs in person, test a studio location and build repeat working relationships among a constrained set of Designers and Providers. Toronto offers a much larger opportunity but should be treated as a second-market replication test rather than proof of the original model. Toronto's scale may generate greater demand while also creating more category fragmentation, longer travel times, higher acquisition costs and a greater requirement for localized Provider pools.

The initial market-selection thesis is therefore:

1. Prove workflow adoption and trusted supply in Ottawa.
2. Demonstrate that one Project can coordinate several independent businesses.
3. Validate transaction and lead economics without depending on paid media.
4. Document the operating playbook.
5. Enter Toronto only after the playbook can be repeated by a market lead rather than the founders alone.

4.8 Market-size framework

The Registry should avoid presenting a single inflated top-down market number. The useful market model has four layers:

The business should report both activated and monetized network counts. A free account with no Project activity is distribution, not traction.

5. Customer Segments

5.1 Primary: emerging and mid-tier independent Designers

Characteristics:

• Solo principals or small teams
• Residential focus
• Professionally ambitious
• Managing meaningful Projects but still dependent on spreadsheets
• Limited administrative support
• Interested in better Providers and stronger client experiences
• Protective of their brand and client relationships

5.2 Secondary: established Designer Studios

Larger studios may adopt the platform for Provider coordination, studio-location participation, lead matching or specific operational modules. They require more sophisticated roles, reporting, integrations and data control.

5.3 Providers

Canonical Provider categories:

1. Vendors & Product Suppliers
2. Millwork & Custom Fabrication
3. Contractors & Specialty Trades
4. Photography
5. Measurement & Drafting
6. Receiving, Warehouse & Storage
7. White-Glove Delivery
8. Installation Services
9. General Service Providers

5.4 Clients

Clients are invited by Designers or enter through Registry-generated lead channels. They use a limited, beautifully branded Project experience.

5.5 Studio-location participants

• Member Designers
• Clients
• Vendors and product representatives
• Provider partners
• Industry educators
• Event guests

6. Product and Service Ecosystem

6.1 Free Designer operating system

Core capabilities are intended to include:

• CRM and clients
• Website lead capture
• Pipelines
• Project Opportunities
• Matchmaking
• Projects and templates
• Seven-Phase Project workflow
• Spaces and rooms
• Construction materials
• Decorating and FF&E items
• Budgets
• Procurement
• Tasks and calendar
• Files, notes and activity
• Client approvals
• Provider coordination
• Proposals
• Invoicing
• Reporting

6.2 Free Provider business tools

Providers receive:

• Provider CRM
• Contacts and opportunities
• Offers
• Proposal builder
• Work Orders
• Tasks and calendar
• Files and communications
• Category-specific operations
• Invoicing and payment visibility
• Business reporting
• Branded documents and workspace

The objective is to make the Provider portal useful for the Provider’s own business—not merely a compliance interface imposed by Designers.

6.3 Client portal

Clients receive:

• Designer-branded experience
• Project summary
• Current stage and milestones
• Selections and approvals
• Comments and decisions
• Shopping lists and presentation packages
• Calendar and appointments
• Relevant files and communications
• Proposals and agreements
• Invoices and payments
• Delivery and installation windows
• Relevant tracking
• Completed Project archive

Clients do not see wholesale costs, internal margins, internal notes, Provider comparisons or unrelated operational data.

6.4 One Project, multiple views

Project
├── Designer Studio: full control
├── Client: decisions and appropriate progress
├── Vendor: assigned products and orders
├── Warehouse: receiving, condition and storage
├── Delivery: manifest, route and tracking
├── Installer: assigned items, rooms and deficiencies
├── Millwork: drawings, fabrication and milestones
├── Contractor: scope, schedule and site work
└── Photographer: brief, shoot and deliverables

6.5 Product thesis: a Project becomes a Registry

The product has two connected modes rather than two separate products.

Active Project mode helps people deliver the work. It is dynamic, deadline-aware and action-oriented. It contains tasks, schedules, approvals, items, budgets, Offers, commercial records, communication, evidence and exceptions.

Permanent Registry mode preserves what should remain after delivery. It is calmer, curated and organized around the home rather than the administrative process. It retains the approved and installed truth: spaces, final specifications, drawings, products, finishes, professional contributions, photographs, manuals, warranties, decisions, care information and meaningful history.

Completion is therefore not a blunt archive action. It is a governed transition:

Opportunity → Active Project → Substantial completion
→ Registry readiness review → Published home Registry
→ Aftercare, warranty, replacement and future work

The active Project remains the authoritative source. Registry mode is a durable projection of approved records, with history and provenance intact. A correction never silently rewrites what was previously approved or installed.

6.6 Registry chapters

Every Registry is organized into stable chapters so information remains understandable beyond the original Project team:

1. Home: identity, address controls, property context, Designer, Client and completion summary.
2. Vision: Project brief, inspiration, design intent and presentation story.
3. Spaces: rooms, floor plans, elevations, measurements and spatial relationships.
4. Materials & Finishes: installed construction selections, finish schedules, paint, stone, tile, hardware, plumbing, lighting and related care.
5. Furniture & Objects: approved and installed FF&E, accessories, art, sources and replacement information.
6. Drawings & Documents: final issued drawings, specifications, permits where appropriate, manuals and close-out documents.
7. Craft & Contributors: the Designer and authorized Providers whose work formed part of the completed home.
8. Installation & Completion: delivery evidence, placement, deficiencies, resolutions and final photography.
9. Care & Afterlife: warranties, maintenance instructions, service history, replacement paths and future renovation context.
10. Story & Timeline: curated milestones and decisions that explain how the home came together.

Not every chapter is public or visible to every participant. Residential security, financial information, private contact data and internal professional notes remain permissioned.

6.7 Registry events and provenance

The platform should treat consequential activity as a Registry Event. An event records what happened, when, to which object, through which Workspace, by which person or automation, using which version, and with what supporting evidence.

Examples include:

• A finish was selected, revised, approved and installed.
• A drawing version was issued and superseded.
• A Proposal was accepted and converted to a Work Order.
• An Item was ordered, received damaged, repaired, released and installed.
• A Client approved a budget change.
• A Provider completed a milestone and submitted evidence.
• A warranty or manual was associated with the installed Item.

This event model supports the activity timeline, audit history, Client updates, Project reporting, AI summaries and the permanent record without maintaining separate histories for each audience.

6.8 Shared-component architecture

The platform follows build once, reuse everywhere. Shared modules are not merely visual components; they are consistent behaviours and data contracts used across Admin, Designer, Client and Provider experiences.

Configuration determines terminology, fields, visibility, actions, evidence and default layout by Workspace and Provider type. Separate code paths are justified only when the work itself is materially different.

6.9 Workspace and entity architecture

The network distinguishes between a durable Entity and an authenticated Workspace.

• A Designer Studio, Provider business, Client household, contact or property can exist as an Entity before anyone signs in.
• Approved Designer and Provider Entities can be provisioned into Workspaces without creating duplicate organizations.
• A User can belong to multiple Workspaces while retaining one identity.
• A Workspace owns its CRM, templates, teammates, branding, connected accounts and private records.
• Project assignments create narrowly scoped cross-Workspace access; they do not expose an entire business.
• Clients receive a controlled Workspace or Project portal appropriate to their participation.

Profiles use one shared design language while exposing fields and modules relevant to the profile type. The goal is recognizable consistency without pretending that a User profile, Designer Studio profile, Provider profile and Project profile contain identical information.

6.10 Pipeline, form and automation layer

Pipelines govern acquisition and qualification before operational work begins. The platform supports three classes:

1. System lifecycle pipelines for Designer Applications, Provider Applications by type, Client intake, Project Opportunities and other governed Registry processes.
2. Workspace CRM pipelines for Designer and Provider leads, opportunities and relationships.
3. Project lifecycle projections that reflect Project readiness and Phase progress without replacing the Project's detailed operating model.

Every pipeline can define stages, colours, allowed transitions, required fields, validation, forms, record layouts, notifications and automations. Published pipeline versions are immutable for historical records; changes create a new version and an explicit migration decision.

Automations can create Tasks, request information, send in-app messages, email or SMS, schedule calling actions, assign an owner, update a field, create an Entity, provision a Workspace or recommend a stage move. Consequential external communication and irreversible actions remain approval-aware and fully logged.

6.11 Commercial record chain

Commercial work begins inside the Project and preserves scope from request through payment:

Project need → Work Package → Offer / request for Proposal
→ Proposal version → acceptance and award → Work Order
→ Change Order when scope changes → Invoice → Payment and allocation

Each conversion carries forward the accepted version instead of asking a participant to re-enter it. The platform records payer, payee, currency, taxes, schedule, terms, included Items, exclusions, evidence requirements and relationship to the Project budget.

The Designer can issue branded Client Proposals. Providers can respond to work offered by a Designer or the Registry and use the same tools for their own authorized business. Providers see only Offers and accepted work assigned to them. Confidential sourcing prevents participants from seeing competitors, private rates, internal rankings or unrelated proposals.

6.12 Communications and decision memory

The Designer's inbox is a central operating surface. Communication must support Admin-to-Designer, Admin-to-Client, Admin-to-Provider, Designer-to-Client and Designer-to-Provider relationships across in-app messages, email, SMS and calling.

Threads can be associated with Projects, Entities, Items, commercial records and Tasks. Inbound email is matched using participants, addresses, thread headers, Project references and user confirmation when confidence is low. Calls can use purchased numbers and preserve call logs, recordings where legally permitted, transcripts, summaries and follow-up actions. Internal Notes and @mentions remain distinct from external messages.

The goal is not to trap communication inside a proprietary inbox. It is to prevent important decisions from becoming detached from the Project and permanent record.

6.13 Product success loop

The product compounds through a simple loop:

A Designer organizes one Project
→ invites the Client and selected Providers
→ each participant receives operational value
→ structured updates improve Project clarity
→ the Project creates a complete Registry
→ the network gains trusted performance and matching signals
→ the next Project is easier to begin and deliver

The company should measure this loop using activated Projects, invited and active participants, external workflow completion, decision cycle time, Item and evidence completeness, multi-Workspace retention and Registry readiness—not raw account creation alone.

7. Project Operating Model

7.1 Projects are the operational centre

Leads create relationships. Pipelines qualify and convert. Entities participate. The Project coordinates actual work.

7.2 Seven canonical stages

1. Concept
2. Design
3. Design Package
4. Construction Administration
5. Decorating
6. Procurement
7. Installation

Project templates configure relevant stages, tasks, milestones, fields, deliverables, notifications and Provider dependencies.

The seven Phases form a common operating language, not a row of decorative tabs. Each Phase has a purpose, entry conditions, work, required decisions, deliverables and completion gates:

Projects may contain work from several Phases at once. The current Phase communicates overall maturity; it must not hide legitimate cross-Phase work. Automatic Phase movement occurs only when configured completion rules are met and authorized people can see why the system recommends or performs a transition.

7.3 Item systems

Construction items and decorating items share a foundation but retain different category, specification, pricing and workflow needs.

Items connect to:

• Space/room
• Category
• Budget allocation
• Vendor
• Quote/Proposal
• Purchase Order
• Receiving
• Condition
• Storage location
• Delivery
• Installation
• Deficiency
• Invoice/payment

7.4 Spreadsheet transition

Designers can import existing item lists. AI and validation map columns, normalize categories, identify duplicates and request confirmation for uncertain data.

Imports support CSV/XLSX upload and controlled Google Sheets connection. The mapping experience previews source rows, proposes destination fields, preserves the original file, explains transformations and isolates rejected or uncertain rows. A repeat import can update existing Items only through stable identifiers or a reviewed matching process; it must not silently duplicate a Project budget.

7.5 Project profile and command centre

The Project profile is the most important shared profile in the system. It should be visually exceptional while remaining operationally precise. Its overview answers:

• What is the home and the design intent?
• Who is responsible and who is participating?
• Which Phase is current and what is blocking progress?
• Which Client decisions are due?
• What changed in schedule or budget?
• Which Items or Provider commitments are at risk?
• What should this User do next?

Core content includes Project identity, property details, address controls, Client and Designer, Project Vision & Inspiration, featured imagery, floor plans, spaces, Phase health, milestones, people, budget position, upcoming work, recent decisions and exceptions. Every card links to the underlying record rather than becoming a disconnected summary.

7.6 Project builder and templates

Workspace owners create Project templates in Settings. A template can define:

• Included Phases and permitted overlaps
• Phase descriptions, entry rules, exit gates and target durations
• Milestones, Task groups, dependencies and assignee roles
• Required deliverables, Files, forms and Client decisions
• Space, Item and budget category structures
• Standard Work Packages and Provider categories
• Calendar events and resource requirements
• Notification and automation recipes
• Time-tracking expectations
• Registry completion checklist

Templates are versioned. Creating or editing a template never silently changes a live Project. A Project may adopt selected improvements through a previewed migration that identifies additions, conflicts and preserved custom work.

7.7 Tasks, calendar, resources and time

Tasks can belong to a Workspace, Project, Phase, space, Item, decision, Work Package or commercial record. They support owners, collaborators, dependencies, checklists, due windows, recurrence, evidence and status. Views include personal work, Workspace work, Project work, waiting-on and exceptions.

The Project calendar combines milestones, Client meetings, site visits, Provider appointments, measurement, photography, receiving, delivery, installation and payment dates. Google Calendar synchronization respects source ownership and avoids uncontrolled two-master edits.

Resource scheduling identifies people, crews, rooms, vehicles or other constrained resources. Time entries are attributable to a User, Project, Phase and optionally Task or Work Order, allowing a Designer or Provider to understand Project hours, utilization and profitability without exposing internal labour data to unauthorized participants.

7.8 Integrated budgets and Items

Budgeting is embedded in the Item process rather than maintained as a separate spreadsheet-shaped summary. A category holds its allocation, approved changes, committed value, actual value and forecast; Items supply the underlying quantities and prices.

The financial model distinguishes:

• Client-facing price from internal cost
• Tax-inclusive and tax-exclusive values
• Estimate, quoted, approved, committed, invoiced and paid amounts
• Product cost, markup, freight, duty, receiving, storage, delivery, installation and other landed costs
• Allowances, contingencies, credits and Change Orders
• Workspace-private margins from Client-visible totals

Budget rollups can be viewed by Project, Phase, space, category, Provider and commercial status. Every number should drill down to the records that produced it.

7.9 Provider integration inside the Project

Providers are added through deliberate assignments and Work Packages rather than broad Project membership. An assignment defines scope, dates, authorized Items, shared Files, contacts, permitted actions, commercial relationship and access expiry.

The Project provides a consistent handoff pattern:

1. The Designer identifies a need using Project records.
2. The system packages only the relevant context.
3. Matchmaking may recommend eligible Providers with reasons.
4. An authorized person sends confidential Offers.
5. The selected Proposal becomes a Work Order.
6. Provider-specific milestones and evidence appear in the Project.
7. Exceptions return to the responsible queue.
8. Completion and payment update both the Project and Provider history.

This model supports Designer-selected Providers as well as Registry-recommended Providers. Marketplace participation is not required to use the Project.

7.10 Project page, presentation and PDF

Designers can create a polished, Client-facing Project webpage from approved Project content. The page can combine the Project Vision & Inspiration, narrative, floor plans, imagery, spaces, selections, material palettes, budgets, milestones and approval calls to action. It can be shared through controlled access and exported as a presentation-quality PDF.

AI can propose structure, draft narrative, select authorized Project content and adapt layout from prompts. The Designer reviews every publication. AI cannot publish private notes, hidden financials, unapproved Items or restricted residential information. Published pages are versioned so a Client decision always refers to the exact presentation reviewed.

7.11 Registry completion and aftercare

Completion readiness is measured, not assumed. The system identifies missing final specifications, unresolved deficiencies, absent warranties, incomplete Provider evidence, unpublished photography, open commercial records and permissions requiring review.

The Designer controls the curated Client handoff. The completed Registry includes only approved information and continues to support warranty claims, maintenance, product replacement and future Projects. Operational records remain available according to retention and access policy, while the everyday Client experience becomes quieter and centred on the finished home.

8. Provider Portal & Network Strategy

External partners are called Providers throughout the product and business. They are not a secondary marketplace attached to Designer software. They are the businesses that translate design intent into physical outcomes, and their participation is essential to the Registry's product value, network defensibility and revenue model.

The Designer is the relationship and creative centre. Providers extend the Designer's ability to measure, quote, fabricate, source, receive, store, deliver, install, photograph and maintain the work. Each Provider creates a handoff where information can be lost, time can be wasted and financial value can be created. The Design Registry connects those handoffs without forcing the Designer to become the manual integration layer.

The strategic equation is:

Designer adoption creates Projects
→ Projects create real Provider demand
→ Provider portals make external work easier to execute
→ Provider updates make the Project more valuable to the Designer and Client
→ commercial records and payments remain connected
→ the completed work strengthens the permanent Registry
→ trusted operating history improves future matching and transaction volume

The Provider network therefore serves four businesses at once:

1. Product value: live external status makes the Project more useful than a private Studio tool.
2. Distribution: Designers naturally invite the Providers already required by active Projects.
3. Retention: Providers return because the portal helps run their own work, not only because a referral arrived.
4. Revenue: qualified demand, commercial records, products, procurement, payments and managed services create multiple contribution opportunities.

8.1 Common Provider foundation

Every Provider receives shared modules plus category-specific operations.

The common foundation includes a branded Workspace, business and User profiles, teammates, customizable role labels, CRM Pipelines, Offers, Proposals, Work Orders, Change Orders, Invoices, payments, Tasks, Calendar, Communications, Files, Notes, Activity, reporting and connected accounts. Navigation shows only relevant modules and later respects granular permissions.

A Provider may use these tools for Registry-assigned work and its own authorized leads or Clients. This matters strategically: a Provider that sees the portal only when the Registry sends work has weak retention. A Provider that can manage daily operations, teammates, opportunities and Invoices has a reason to return between referrals.

Every Provider receives the Offers feature. Accepted Offers or awarded Proposals create Project-scoped work; they do not reveal unrelated Project or Designer data. Category modules configure status, evidence and dashboards over the shared foundation.

8.2 The Provider value exchange

Provider participation cannot rely on compliance alone. Every update requested by the Registry should save the Provider work, improve payment readiness, reduce ambiguity or strengthen future opportunity.

The Registry should never ask a Provider to re-enter data already available from an approved source. The system should prefill the Work Package, Item manifest, contacts, locations and dates, then ask the Provider only for information it owns or must confirm.

8.3 Provider lifecycle

Project demand or direct application
→ category-specific application
→ qualification and verification
→ Provider Entity and matching profile
→ Workspace provisioning and onboarding
→ first Offer or own CRM opportunity
→ Proposal and award
→ Work Order and category operations
→ Invoice, payment and reconciliation
→ outcome review and repeat selection
→ ongoing CRM, reporting and network participation

Approval does not equal activation. A Provider becomes activated through a meaningful operating action and retained through a second Project, repeat CRM activity or regular use of its business tools.

Applications are tailored to category risk. A Photographer and a warehouse should not complete the same form or provide the same evidence. Each Provider type also answers relevant matchmaking questions covering service area, specialties, Project scale, capacity, lead time, commercial fit and operational capability.

8.4 Provider Workspace and dashboard

The Provider dashboard is configured around category-specific daily work while retaining the shared Design Registry shell. Common priorities include:

• Offers requiring response;
• Proposals awaiting action;
• awarded or active Work Orders;
• today's appointments, site work, receiving or deliveries;
• missing information and blocked work;
• evidence required for milestone completion;
• Items or shipments with exceptions;
• Invoices, payment status and reconciliation;
• credentials or profile information approaching expiry;
• new leads and CRM follow-ups; and
• performance and operational reporting.

The Workspace owner manages the business profile, brand, teammates, role labels, templates, connected accounts and notification preferences. Navigation reflects the Provider type and later permission settings. A warehouse may lead with Receiving and Inventory; a Photographer may lead with Shoots and Deliverables; a Vendor may lead with Products, Quotes and Orders.

8.5 Offers, commercial conversion and payment

All Providers receive Offers. An Offer contains a versioned Work Package assembled from the Project and may request availability, a fixed acceptance or a Proposal. Providers can accept, decline, request clarification or submit a versioned response without seeing competing Providers or private selection logic.

When awarded, accepted scope becomes a Work Order. Changes become explicit Change Orders. Completed milestones and evidence support Invoicing. Payment state remains connected to the underlying work whether funds move through Stripe, bank payment or an approved external/manual method.

This connected chain is central to retention and monetization. It reduces scope disputes, makes payment readiness visible and allows the Registry to calculate fees or commissions from the correct event instead of relying on retrospective reporting.

8.6 Providers across the Designer journey

The platform should introduce each Provider category at the moment its participation becomes useful. This keeps navigation and data calm while ensuring the Project template can anticipate future dependencies.

8.7 Vendors & Product Suppliers

• Product and sample catalogue
• Trade and retail pricing
• Availability and lead times
• Quote and sample requests
• Offers and Proposals
• Order acknowledgements
• Shipment tracking
• Warranty/return workflow
• Product data feeds and approved APIs

Proper Goods Club becomes one Vendor participant rather than a standalone pipeline or platform category.

Vendors are strategically important because product selection and purchasing occur throughout Design, Decorating and Procurement. Their data can remove repeated clipping, manual quote entry and order chasing. A Vendor portal can support both direct catalogue/API participation and lower-technology workflows using structured requests and uploads.

Potential revenue includes commissions, referral economics, trade/resale contribution, data/API programs, promoted education that is clearly separated from matching, payment services and managed procurement. The Registry must protect Designer choice and avoid turning commercial preference into hidden recommendation bias.

8.8 Receiving, Warehouse & Storage

• Expected receipts
• Carrier and tracking information
• Receiving appointments
• Item identification and scanning
• Quantity verification
• Condition inspection
• Required photographs
• Damage and exception flags
• Unidentified-item workflow
• Rack/zone/bin location
• Storage duration
• Repair/claim status
• Project pull lists
• Release authorization
• Load-out confirmation
• Recurring charges
• Chain of custody

Warehouses create the physical source of truth between shipment and installation. Their updates determine whether the Designer can trust quantity, condition, location and readiness. A strong warehouse portal replaces intake spreadsheets, photo texts, storage-location notes and manual pull-list coordination.

Revenue may include transaction fees, managed receiving/storage programs, recurring operational software, payment services or negotiated network economics. The Registry must distinguish Provider revenue from storage charges passed to the Client and preserve chain-of-custody evidence for claims.

8.9 White-Glove Delivery

• Offers and quote requests
• Delivery manifests
• Pickup/drop-off details
• Crew and vehicle assignment
• Route planning
• Load verification
• Live location
• En route/arrived/completed states
• Access/elevator/parking instructions
• Delivery photographs
• Proof of delivery
• Signature
• Damage and deficiency reporting
• Failed-delivery reasons
• Installation handoff

White-glove delivery is the most visible physical handoff to the Designer and Client. Live status, access instructions, manifest accuracy and proof can materially improve install-day confidence. The portal must be fast on mobile and useful to dispatchers, crews and authorized observers without exposing unrelated residential information.

Revenue may include transaction fees, dispatch or managed-service economics, payment services and future multi-vehicle or multi-location premium software. Location sharing is time-bound, purpose-limited and visible only to authorized participants.

8.10 Millwork & Custom Fabrication

• Scope and quote packages
• Site measurements
• Shop drawings
• Material and finish approvals
• Fabrication stages
• Change requests
• Quality-control evidence
• Delivery and installation milestones

Millwork connects design intent to one of the highest-value, highest-change categories in a Project. Version integrity is essential: measurements, shop drawings, finishes, approvals, fabrication and installation must refer to the accepted scope. The portal should reduce disputes by making superseded drawings and approved changes unmistakable.

Revenue may include transaction or referral economics, managed coordination, payment services and premium workflow/API capabilities for larger fabricators.

8.11 Contractors & Specialty Trades

• Bid/Offer workflow
• Scope and exclusions
• Site schedule
• Crew assignment
• Permits and inspections
• Daily or milestone updates
• Change Orders
• Deficiencies
• Completion evidence

Contractors and trades participate across pricing, construction and close-out. They need concise scope, site context, schedule, responsibilities and approved changes—not access to the Designer's complete internal system. Mobile milestone updates and deficiencies should connect directly to Tasks, Items, spaces and commercial records.

Revenue may include category-specific transaction fees, qualified referrals, payment services, managed tendering or coordination and premium operational tools. Professional, licence and insurance requirements vary by trade and market.

8.12 Photography

• Creative brief
• Shot list
• Location and schedule
• Styling requirements
• Asset delivery
• Revision workflow
• Usage rights and licensing

Photography completes the public and archival story of the work. The portal must preserve brief, styling responsibility, shot list, access, schedule, image selection, revision, delivery and rights. Approved assets can feed the Registry and authorized marketing while maintaining explicit usage permissions.

Revenue may include referral or transaction fees, managed shoot coordination, payment services and future asset-delivery/storage capabilities.

8.13 Measurement & Drafting

• Site access and appointments
• Measurement scope
• Drawing standards
• Deliverables
• Review and revision
• File versioning

Measurement and drafting often begin the structured record. Their deliverables establish spaces, dimensions and drawings used by multiple later Providers. Accuracy, access, standard, version and acceptance must remain visible.

Revenue may include referral or transaction fees, packaged measurement/drafting services, managed scheduling and premium integrations for high-volume Providers.

8.14 Installation Services

• Room/item manifest
• Crew and schedule
• Sequence and dependencies
• Placement instructions
• Completion photography
• Deficiency list
• Client/Designer sign-off

Installation converts received Items into the completed physical environment. The portal should connect each Item to room, placement, readiness, assembly, condition, photography and deficiency. Installers receive only the information needed for the assigned work and can close issues without a parallel paper punch list.

Revenue may include transaction economics, managed installation, payment services and operational software for crews or multi-market businesses.

8.15 Provider experience principles

Provider workflows follow five rules:

1. The assignment arrives complete: scope, Items, location, timing, contacts, access and evidence requirements are packaged from the Project.
2. The next action is obvious: the dashboard prioritizes Offers, approvals, scheduled work, missing evidence, exceptions and payment.
3. Updates help the Provider operate: status entry should replace another spreadsheet, email or phone call.
4. Mobile supports physical work: receiving, delivery, installation and site updates are fast, camera-friendly and usable with unreliable connectivity where practical.
5. Evidence becomes reusable trust: confirmed performance strengthens future matching without exposing confidential details or reducing quality to one opaque score.

8.16 Category rollout method

Provider portals should not all be built to maximum depth at once. Each category follows a repeatable rollout:

1. Observe three to five real workflows.
2. Define the common Work Package and evidence recipe.
3. Configure the shared Provider modules.
4. Build only the genuinely category-specific operational surface.
5. Pilot with active Project work.
6. Measure independent status updates, exception resolution, time saved and repeat use.
7. Expand only after the Provider and Designer both receive value.

Receiving/Storage and White-Glove Delivery are strong early pilots because they create visible physical-state information that Designers currently chase manually. One construction/fabrication category and Vendors should follow to prove that the architecture supports both services and products.

8.17 Provider network revenue model

Provider-related revenue is not one fee. The commercial structure follows category, value and legal role:

• Qualified referral: a fixed or percentage fee for demand introduced and converted.
• Marketplace transaction: a contracted fee on accepted or completed Work Order value.
• Product/Vendor economics: commission, negotiated rebate, resale margin or procurement fee.
• Payment services: a disclosed platform or financial-operation fee where viable.
• Managed operations: markup or service fee for work the Registry actively coordinates.
• Premium Provider software: advanced locations, users, workflows, automation, reporting or APIs.
• Studio and education programs: approved presentations, samples, events and local network activity.

Each category has a commercial policy defining payer, rate, earned event, funds flow, direct cost, disclosure, cancellation/change treatment, dispute handling and accounting. Revenue is recognized on the Registry's actual fee or margin, never the entire Provider Work Order unless the Registry is legally and economically the principal.

The company should measure Provider economics by active relationship and category: acquisition and verification cost, Work Orders, gross value, recognized revenue, payment cost, direct support, claims, retained usage, repeat selection and contribution. A high-volume category with heavy exceptions can be less attractive than a smaller category with reliable repeat use.

8.18 Network defensibility

The Provider moat is created through accumulated operating value, not a static directory. Over time the Registry learns permissioned, contextual evidence about category fit, capacity, response, schedule, documentation and completed outcomes. Designers develop reusable relationships and Project templates; Providers accumulate profiles, commercial templates, teammates, history and reporting.

This information improves matching and execution while remaining portable and governed. The company must avoid opaque rankings, unfair concentration and data captivity. Retention should result from easier work and trusted history.

8.19 Provider success measures

Success includes application completion, approval cycle time, first useful action, Offer response, Proposal turnaround, on-time milestone rate, evidence completeness, updates without manual chasing, repeat Project participation, teammate adoption, Provider-created CRM activity, Invoice cycle time and retention.

The company should also measure burden: required fields per workflow, repeated entry, support contacts, mobile abandonment and time spent resolving access confusion. Provider compliance without Provider value is not durable activation.

8.20 Provider strategic gates

The network should expand category by category only when:

• active Designer Projects create credible demand;
• application and qualification standards are approved;
• at least two suitable Providers can reduce single-supplier dependence where practical;
• the first Work Package and evidence recipe are defined;
• the Provider receives direct operating value;
• the commercial model and disclosure are approved;
• Admin can monitor service levels and exceptions; and
• repeat use can be measured.

The company should not celebrate Provider count without activated work. The goal is a smaller, trusted and economically meaningful network—not the largest directory.

9. Matchmaking Strategy

9.1 Client-to-Designer

Match factors may include:

• Project type
• Budget
• Location
• Desired timing
• Service model
• Style preferences
• Rooms and scope
• Designer specialties
• Capacity and availability
• Language
• Communication preferences
• Prior match outcomes

9.2 Project-to-Provider

Match factors may include:

• Provider category and qualification
• Service area
• Project scale
• Item or material characteristics
• Capacity
• Lead time
• Required date
• Price/rate compatibility
• Insurance/licence status
• Quality/performance history
• Designer preferences
• Prior working relationship

9.3 Human-governed selection

AI produces fit explanations and ranked recommendations. Authorized humans review the shortlist and choose Offer recipients. Providers do not see competitors, private scores or internal selection notes.

9.4 Feedback loop

Outcomes improve recommendations:

• Offer response
• Proposal competitiveness
• On-time performance
• Exception frequency
• Evidence completeness
• Communication responsiveness
• Designer/client satisfaction
• Repeat selection

Performance data must be contextual, appealable and protected from misleading simplistic rankings.

9.5 Matchmaking operating workflow

Structured intake and eligibility
→ hard-constraint filtering
→ explainable fit recommendations
→ conflict, capacity and relationship review
→ authorized human shortlist
→ confidential invitation or introduction
→ response and selection
→ outcome and quality feedback

Hard constraints such as service area, required licence, insurance, timing or category eligibility are resolved before preferences. The system should not present a high stylistic match that cannot legally or practically perform the work.

9.6 Matching questions and profiles

Designer, Client and Provider profiles each contain relevant matching information. Questions are tailored by participant and Provider category, versioned, permissioned and reviewed for predictive value. The platform should not collect sensitive preferences merely because AI could process them.

The company distinguishes stated preference, verified qualification, current capacity, historical outcome and model inference. Users can correct their own profile and understand which information materially influenced a recommendation.

9.7 Network operations and fairness

Admin monitors unmatched demand, weak category coverage, repeated non-response, conflicts, concentration and match outcomes by market. Commercial value to the Registry cannot be disguised as objective fit. Sponsored placement, if ever permitted, must be separated visibly from match recommendations.

Material complaints and eligibility changes can affect future matching only through an auditable policy with notice, evidence and appeal appropriate to the risk. Private model scores are not shown as public ratings.

9.8 Matchmaking success

Success is measured through time to qualified shortlist, shortlist acceptance, invitation response, consultation or Proposal conversion, completed work, repeat selection, satisfaction, complaint rate and outcome quality. The company should compare AI-assisted recommendations with human decisions and monitor whether recommendations unfairly concentrate opportunity.

10. Registry-Generated Lead Program

10.1 Target segment

Initial qualified Project budgets:

• Approximately $10,000–$80,000
• Decorating, furnishing, targeted renovations and defined design scopes
• Clear ability and willingness to engage a professional Designer

Larger opportunities may enter the system when appropriate, but the initial program should prove repeatable qualification and matching in a narrower band.

10.2 Lead sources

• Design Registry website
• Studio locations
• Local search
• Referral partners
• Vendor referrals
• Events
• Designer referrals
• Content and social channels
• Select paid experiments after conversion data exists

10.3 Qualification

• Identity/contact validation
• Location
• Project type
• Budget
• Desired timing
• Decision-maker status
• Property status
• Service expectations
• Style/preferences
• Consent to matching

10.4 Commercial model

Working assumption:

• Designer retains the client relationship.
• Client and Designer contract through approved documents.
• The Design Registry earns 20% of the collected design service fee for Registry-originated leads.
• The Registry does not take 20% of the total Project budget.
• Designer-originated leads do not incur this fee.

Example assumption:

Project budget: $50,000
Design service fee: $7,500
Registry share at 20%: $1,500
Designer receives before tax/other costs: $6,000

The example is illustrative and not a pricing commitment.

10.5 Quality control

• Match only verified/eligible Designers.
• Define response standards.
• Monitor client experience.
• Do not pressure Designers into unsuitable work.
• Make origin and fee treatment clear in agreements.

11. Studio Location Strategy

11.1 Purpose

Studio locations are not ordinary coworking offices. They are local trust, acquisition and network infrastructure.

11.2 Functions

• Designer workspace
• Client meetings
• Material and product sample library
• Vendor presentations
• Events and education
• Content production
• Local brand presence
• Walk-in/appointment lead generation
• Provider-network meetings
• Project review and selection sessions

The space should be programmed around useful moments in the Designer and Client journey rather than general occupancy. A Client selection appointment, Provider education session, material review or completed-Registry story can create trust and product adoption simultaneously. Every event or appointment is attributable to a Workspace, relationship or campaign where consent permits.

11.3 Location model

Possible models:

• Company-operated flagship
• Partner-operated licensed studio
• Curated shared studio
• Vendor-supported sample space with governance safeguards

The initial preference should be a variable-cost partnership, shared space or scheduled program before a long lease. The company should learn which activities produce qualified Designers, Clients, Provider relationships, product volume or retention before defining a permanent footprint.

Vendor support cannot purchase hidden preference in matching or product recommendations. Samples, displays, sponsored education and commercial programs require visible governance and appropriate disclosure.

11.4 Pilot market

Ottawa remains a logical pilot based on the prior plan and founder network. Toronto can follow after demonstrating:

• Designer recruitment
• Qualified lead generation
• Match conversion
• Provider participation
• Studio utilization
• Healthy unit economics
• Scalable platform operations

11.5 Studio economics

Potential revenue/contribution:

• Registry-generated Project fees
• Product/procurement activity
• Vendor programs
• Events
• Optional memberships/services
• Increased Provider marketplace volume

The location should be evaluated as an acquisition and network-density asset, not solely by desk-rental revenue.

11.6 Studio operating system

The Admin product should manage location profile, hours, access, rooms, resources, events, appointments, sample assets, Vendor participation, leads, incidents, maintenance and local reporting. Designers can book appropriate spaces and invite Clients; Providers can participate in approved events or appointments without receiving broad location or Client data.

Tasks, Calendar, resource scheduling, Notifications, Files, attendees and follow-up use the same shared modules as Projects. This allows studio activity to connect to the relevant relationship without creating a separate events application.

11.7 Launch gate

A permanent location requires an approved twelve-month operating statement, defined owner, occupancy and event plan, measurable acquisition hypothesis, insurance/security plan and downside exit. The first test should answer whether physical presence improves qualified conversations, activation, product discovery, Client confidence or network density enough to justify its cost.

12. Branding and Personalization

12.1 Brand principle

Your brand. Your clients. Your business. The Registry behind it.

The Design Registry is expressed with editorial confidence, restraint and permanence. Black and white form the foundation; limited supporting colour communicates meaning rather than decoration. Rounded geometry softens operational precision without becoming playful. Typography, spacing, photography and motion should feel considered and architectural. The black dot is a recurring signature representing connection, continuity and the precise point at which work becomes part of the record.

The emotional promise precedes the functional explanation:

1. Belief: Every professionally designed home deserves to be remembered.
2. Meaning: The work, decisions and professional contributions should not disappear at completion.
3. Mechanism: One connected Project record grows into a permanent Registry.
4. Proof: Designers, Clients and Providers can see and complete the right work through calm, tailored experiences.
5. Commercial invitation: Join, apply or use an appropriate service only after the value is understood.

12.2 Workspace personalization

• Business name and logo
• Colours
• Approved typography
• Workspace imagery
• Branded dashboard greeting
• Contact information
• Email identity/signature
• Proposal, Work Order and Invoice templates
• Client portal branding
• PDF exports
• Terms and service descriptions
• Communication templates
• Pipeline labels and colours
• Role labels
• Forms and Project templates
• Brand voice for AI assistance

12.3 Branding hierarchy

• Designer’s client: Designer branding primary
• Provider’s own customer: Provider branding primary
• Registry-generated lead: Designer brand with appropriate Registry identification
• Registry marketplace transaction: participant branding plus Registry trust/transaction layer
• Internal Workspace: personalized identity inside shared Registry shell

Registry branding remains visible as quiet provenance, not a competing design studio. In Client-facing work, the Designer's authorship and brand lead. In Provider workspaces, the Provider's business identity leads its own CRM and documents. Shared transaction and record surfaces may identify The Design Registry as the trusted infrastructure connecting the parties.

12.4 Language hierarchy

Approved product language uses capitalized defined objects consistently:

• Project is the active operational record.
• Registry is the enduring, curated record of the professionally designed home.
• Designer includes an authorized design professional; Designer Studio is the organization.
• Provider is the umbrella term for external businesses, including Vendors and service Providers.
• Workspace is the private operating environment of one organization.
• Item is a structured material, product, finish, fixture, furniture piece or other selected object.
• Offer, Proposal, Work Order, Change Order, Purchase Order, Invoice and Payment describe distinct commercial records and must not be used interchangeably.

Public messaging should avoid leading with “all-in-one,” “disrupt,” “Uber for design,” “marketplace,” “AI-powered,” “CRM” or “project-management software.” These descriptions reduce the company to familiar categories and weaken the central idea. Where technical terms are needed, they follow the human value rather than replacing it.

12.5 Premium potential

• Custom domains
• Multiple brands/divisions
• Advanced themes
• Branded email domain
• Expanded document controls
• Reduced “Powered by” treatment where appropriate

13. Website Lead Plugin

13.1 Objective

Make The Design Registry useful before marketplace participation by connecting a Designer’s existing website directly to the CRM.

The lead plugin is both a distribution channel and an activation tool. It allows a Designer to receive immediate value from the Registry using demand the Studio already creates. A submission should arrive as a structured, attributed Pipeline Record—not another notification the Designer must manually copy from email.

The plugin remains visibly part of the Designer's brand. The Design Registry may appear as discreet infrastructure or trust provenance according to Workspace configuration, but it should not intercept the Client relationship or redirect qualified inquiries into a competing network flow without explicit consent.

13.2 Distribution

• JavaScript embed
• iframe fallback
• Hosted form link
• WordPress plugin
• Shopify-compatible embed
• Future Webflow, Squarespace and Wix options

The hosted link and iframe fallback provide the earliest launch path. Platform-specific plugins should follow observed volume rather than being built simultaneously. Each distribution method uses the same versioned Form definition, validation, accessibility, consent, attribution and submission API so the company does not create separate lead systems by website platform.

13.3 Features

• Designer branding
• Custom questions
• Conditional logic
• Project type/budget/location/timing
• Style preferences
• Image uploads
• Appointment booking
• Consent management
• Spam protection
• Campaign attribution
• CRM contact and lead creation
• Duplicate detection
• Pipeline assignment
• AI summary and qualification
• Automated email/SMS acknowledgement
• Optional Registry matching consent

13.4 Submission workflow

Client opens Designer-branded form
→ progressive questions qualify the inquiry
→ consent, attribution and form version are captured
→ duplicate person, household, property and opportunity checks run
→ canonical Contact and Pipeline Record are created or reconciled
→ AI prepares a sourced summary and flags missing information
→ acknowledgement is sent through an editable Notification template
→ Designer receives the inquiry in the correct Pipeline and Workspace
→ next Task, appointment or follow-up automation is created

The Client should receive a calm confirmation describing what happens next, expected response time and how information will be used. The Designer should receive the complete inquiry, not a generic “new lead” alert.

13.5 Designer configuration

Workspace owners can select a starter intake template and configure approved questions, conditional logic, budget bands, Project types, locations, required uploads, confirmation language, assignment rules and brand presentation. Canonical fields such as name, email, phone, address, budget, timing and consent use shared standardized components.

Customization should not permit unsafe or inaccessible forms. Protected requirements include consent records, spam controls, valid contact formatting, clear errors, keyboard/mobile support and retention of the exact submitted version.

13.6 Attribution and matching

Every submission stores source domain, page URL, referrer where available, UTM values, campaign, referral code, Designer Workspace, form version and timestamp. Attribution survives conversion into a Client, Project Opportunity and Project.

If the Designer cannot accept the opportunity, the Client is not silently moved into Registry matchmaking. The form may capture separate, explicit consent to be considered for another Designer. That path creates an Admin review and preserves the originating Designer relationship and referral policy.

13.7 AI and data quality

AI may summarize the inquiry, normalize scope, interpret uploaded inspiration, recommend follow-up questions and suggest qualification. It must distinguish submitted facts from inference and link suggestions to the source response. It cannot reject a Client, promise fit, assign a Designer or send a consequential response without configured authority.

Duplicate detection should consider email, normalized phone, household, property and existing open opportunities. Potential matches are reviewed rather than silently merged when identity is uncertain.

13.8 Success measures and release gate

Key measures include form completion, qualified inquiry rate, response time, duplicate rate, booking rate, signed Project rate, source accuracy, spam rate, accessibility errors and activated Projects by embed type.

The plugin is ready for broad distribution when a nontechnical Workspace owner can configure and publish it, submissions reliably reach the correct Pipeline, attribution survives conversion, consent is auditable, notifications are dependable and no duplicate or cross-Workspace exposure appears in testing.

14. Integration Strategy

14.1 Principle

The Design Registry is the operational source of truth while specialized connected tools continue to execute communications, accounting and external workflows.

An integration is not simply a settings connection. Every integration requires a named business owner, authoritative-field policy, permission scope, synchronization direction, freshness indicator, duplicate protection, failure queue, user-visible fallback, reconciliation method and revocation process. Connected tools should reduce repeated entry without creating two silent versions of the truth.

14.2 Resend

• Transactional email
• Invitations
• Notifications
• Branded sending
• Delivery/bounce tracking
• Template rendering

The Registry owns the notification event, audience decision, template version and relationship to the Workspace or Project. Resend executes email delivery and returns delivery, bounce and complaint events. A successful API request is not treated as successful communication until the relevant delivery state is recorded.

Workspace branding and sender identity must be authenticated and monitored. Failed or suppressed critical messages enter an Admin or Workspace queue with an alternative channel or manual follow-up path.

14.3 Twilio

• SMS
• Calling
• Call logs
• Reminders
• Communication automations
• Future delivery/client messaging

Twilio supports purchased business numbers, consent-aware SMS and calling, voicemail, recordings where permitted, transcripts and delivery events. Communications attach to the correct Project, Entity or commercial record and remain subject to Workspace access.

The company must manage number ownership, emergency limitations, call recording disclosure, messaging consent, quiet hours, opt-out, geography and retention. Automation can prepare or schedule outreach but should not create high-volume unsolicited communication.

14.4 Google Calendar

• Two-way synchronization
• Meetings
• Site visits
• Shoots
• Receiving appointments
• Delivery/install windows
• Provider schedules

The Registry owns Project milestones, dependencies and appointment context; Google Calendar remains the participant's personal or business calendar. Two-way synchronization must identify the source of each event and prevent an update loop.

Users choose calendars and visibility. Private calendar titles should not be copied broadly into Projects, and Project access should not expose unrelated personal events. Conflicts can inform scheduling without revealing restricted details.

14.5 Google Sheets

• Import/export
• Transition from spreadsheets
• Approved live reports
• Controlled operational collaboration

The platform must avoid uncontrolled two-master synchronization. Each integration defines authoritative fields and conflict behavior.

Initial use should emphasize migration, controlled import and approved export. Live synchronization is introduced only for a defined range and ownership model. Every import previews mapping and changes; every export states whether it is a snapshot or connected view.

14.6 Stripe

• Payment requests
• Deposits
• Client payments
• Marketplace payments
• Provider payouts where permitted
• Refunds/disputes
• Transaction reporting

Stripe executes supported payment and marketplace functions, while the Registry owns the commercial obligation, Invoice relationship, participant context and reconciliation status. The funds-flow design must be approved before the interface suggests the Registry can collect or pay out every transaction.

Large Project amounts may favour bank-based payment or recorded manual settlement. Payment method, processing cost, refund, dispute, payout, reserve and failure state must remain visible to authorized financial operators.

14.7 QuickBooks Online

• Customers and Vendors
• Invoices
• Payments
• Taxes
• Account mappings
• Reconciliation

QuickBooks is the accounting ledger; the Registry is the operational record. The connection maps customers, Vendors, tax codes, accounts, Items, Invoices, payments and credits according to an approved accounting policy.

Synchronization must not create duplicate customers or Invoices when names change. Conflicts and unmapped accounts enter a reconciliation queue. Accounting adjustments remain distinguishable from operational changes to an accepted Work Order.

14.8 Vendor APIs

Approved Vendor integrations may support product catalogue, pricing, availability, quotes, ordering and status updates. Integrations should begin with high-volume strategic Vendors rather than attempting universal coverage immediately.

Source, account eligibility, price type, currency, freshness and availability confidence must accompany imported product data. The Designer reviews consequential values before they become approved Item or Purchase Order information. Vendor terms determine whether images, descriptions and pricing can be stored, displayed, transformed or shared with Clients.

14.9 Integration operations

Admin maintains a connected-systems register containing owner, environment, credentials, scopes, renewal dates, data classes, dependencies, service limits, incident contacts and fallback. The platform exposes connection health, last successful synchronization and participant impact.

Integration events feed the same Admin exception model described in the Operating Model. AI may summarize failures, correlate repeated errors and recommend remediation, while authorized people control credential changes, financial corrections and participant communication.

14.10 Integration sequencing

The recommended order follows immediate product value:

1. Resend for invitations and transactional notifications.
2. Supabase-connected identity, data, storage and realtime foundations.
3. Google Calendar for Project appointments and schedules.
4. Google Sheets for migration and structured import.
5. Twilio for consent-aware SMS and calling.
6. Stripe once commercial records and funds flow are approved.
7. QuickBooks after Invoice, payment and accounting mappings are stable.
8. Selected Vendor APIs based on observed Project volume.

An integration exits pilot only when the failure path, reconciliation and access model are tested—not merely when the happy path connects.

15. AI Strategy

15.1 Strategic purpose

AI is designed to:

• Reduce administrative work
• Help Designers operate professionally
• Help Providers respond and execute efficiently
• Improve match quality
• Support a lean Registry operations team
• Turn unstructured Project information into structured records

AI is not a separate personality layered over the product. It is a permission-aware capability that appears at moments where it can remove administrative effort, recover context or make complexity understandable. Its tone follows the active Workspace's approved brand voice and the Registry's standards: calm, specific, concise and honest about uncertainty.

15.2 AI for Designers

• Lead summaries and scoring
• Follow-up drafting
• Project brief generation
• Meeting summaries
• Task recommendations
• Product extraction from URLs
• PO and quote extraction
• Spreadsheet mapping
• Shopping-list creation
• Budget categorization
• Provider recommendations
• Proposal/scope drafting
• Schedule and risk warnings
• Client update drafting
• Invoice follow-up assistance

15.3 AI for Providers

• Offer/Work Package summaries
• Proposal drafting
• Manifest extraction
• Receiving document processing
• Damage/exception assistance
• Route planning suggestions
• Work Order task generation
• Invoice preparation
• Missing-evidence detection
• Capacity and pipeline insight

15.4 AI for clients

• Guided intake
• Preference discovery
• Plain-language summaries
• Decision reminders
• Project update explanations

15.5 AI for Registry operations

• Lead qualification/routing
• Match recommendations
• Application screening
• Document/insurance extraction
• Readiness monitoring
• Supply/demand analysis
• Support triage
• Transaction reconciliation assistance
• Quality and fraud signals
• Studio performance reporting
• Market expansion analysis

15.6 AI operating manager

Long-term monitoring:

Leads → Match quality → Project health → Provider capacity
→ Tasks/schedules → Commercial exceptions → Payments
→ Client experience → Marketplace quality

The operating manager should work as an exception and preparation system rather than an autonomous executive. It can assemble a morning brief, identify stale decisions, warn that procurement dates threaten installation, detect a missing receiving photograph, draft a Client update or prepare a Provider comparison. It must link each conclusion to the relevant Project records and distinguish facts, calculations, predictions and recommendations.

15.7 Registry intelligence

Registry intelligence is the long-term advantage created by structured, permissioned Project history. It can help answer:

• Which specification was ultimately installed, and what did it replace?
• Which Items require care, service or warranty action?
• Which Provider is a strong operational fit for this exact scope and geography?
• Which decisions are delaying the Project?
• Which Purchase Orders threaten a target installation window?
• What information is missing before the Project can become a complete Registry?
• What should a future Designer know before renovating this home again?

Intelligence must be scoped to authorization and purpose. Network-level learning should use governed signals and protected data; it must not expose one business's confidential prices, Clients, conversations or competitive information to another.

15.8 Governance

AI must not silently:

• Award work
• Approve invoices or payments
• Change binding commercial terms
• Send sensitive communications without configured approval
• Suspend a Provider solely on model output
• Expose one Workspace’s information to another

Required controls:

• Source links
• Confidence/uncertainty
• Human approval
• Access-aware context
• Audit history
• Prompt/model versioning for consequential workflows
• Data retention and privacy controls
• Evaluation for bias and match quality

Additional brand-aligned AI rules:

• AI never claims authorship of professional design work.
• Generated narrative credits the Designer and approved contributors appropriately.
• AI-generated Project pages, summaries and specifications remain drafts until reviewed.
• Recommendations explain their source and do not create false certainty.
• Residential addresses, access instructions, security details and Client information receive elevated handling.
• The interface distinguishes extracted, calculated, inferred and human-approved data.
• Corrections improve the record without erasing the original source or approval history.

16. Current Product Foundation

The authenticated platform currently represents a meaningful product foundation, although several modules remain incomplete or illustrative.

16.1 Released or materially represented today

• Admin Overview
• Project Opportunity pipeline
• Designer Application pipeline
• Matchmaking
• Projects directory
• Designer Studio directory and detailed profiles
• Clients
• Assignments
• Tasks/templates
• Teammates
• Teams
• Custom Role Labels
• Project Builder
• Pipeline Builder
• Notifications Builder
• Data Reconciliation
• Global search and attention patterns
• Reusable Notes, Files, Tasks, Communication, Activity and History concepts
• Authenticated Workspace dashboard and profile foundations
• Provider application and approval foundation

16.2 Important existing architecture

• Pipeline outcomes create durable entities or Projects.
• Studio profiles already include matching, capacity and credentials.
• Settings already separate Teammates, Teams and Role Labels.
• Shared record tabs provide a reusable portal foundation.
• Project Builder recognizes seven canonical phases.

16.3 Incomplete, expanding or planned

• Complete brand and terminology synchronization across every legacy surface
• Complete category-specific Provider application pipelines and provisioning depth
• Provider directory and category profiles
• Provider portals
• Offers and commercial workflows
• Complete Proposals
• Work Orders and evidence
• Invoicing/payments
• Live Project item/budget/procurement operations
• Messaging/calling
• Reports
• Studio-location administration
• Website plugin
• AI operating layer

The current product should be represented through explicit maturity labels:

• Released: available and supported for its stated use.
• Released foundation: working shared architecture that requires broader coverage or refinement.
• In build: actively being implemented against an approved specification.
• Specified: approved future behaviour not yet represented as working functionality.
• Exploratory: strategic concept requiring validation before commitment.

No marketing, sales or investor material should infer that a specified or illustrative workflow is production-ready.

The business plan must not present incomplete functions as production-ready.

17. Competitive Landscape

17.1 Programa

Programa offers design-specific specification, procurement, Product Library, purchase orders, invoicing, client dashboards and QuickBooks/Xero connectivity. Programa states it supports more than 50,000 Projects across 6,000+ studios in 80+ countries. Programa software guide

Its procurement product tracks purchase orders, payments, shipping and multiple procurement dates at the line-item and studio level. Programa procurement

Design Registry differentiation:

• Free core adoption model
• Vetted multi-category Provider network
• Provider operating portals
• Cross-company Project record
• Lead and Provider matchmaking
• Physical studio locations
• Connected receiving, tracking and installation evidence

17.2 Houzz Pro

Houzz Pro offers broad CRM, estimation, proposals, invoices, payments, client dashboards, sourcing, procurement and QuickBooks connectivity. Houzz Pro features

Design Registry should avoid competing on undifferentiated checklist breadth. Its advantage must be curation, Designer trust, network operations and a more refined vertical experience.

17.3 DesignFiles

DesignFiles markets product clipping, design tools, client portal/approvals, purchase orders, RFQs, calendar, quotes, invoicing, payments and QuickBooks sync. DesignFiles features

17.4 Design Manager

Design Manager emphasizes integrated accounting, purchasing, procurement, specifications, client portal and Project profitability for residential design firms. Design Manager

17.5 Competitive moat

The moat is not a single feature. It is the combination of:

• Structured Project data
• Free Designer and Provider utility
• Verified local network density
• Category-specific Provider operations
• Matchmaking outcomes
• Studio locations
• Transaction and performance history
• AI trained/evaluated on permissioned workflow context
• High switching value from accumulated Project and network records

18. Revenue Model

The Design Registry uses a free-core, value-event revenue model. Designers and Providers can operate real Projects without a mandatory base subscription. Revenue is created when the Registry originates qualified demand, enables a commercial transaction, supports procurement or payments, provides an optional high-value capability, or operates a physical/network service.

This model is deliberately different from using free software as a thin trial. The free product must be complete enough to create activation, recurring operational value and network participation. Monetization should follow an outcome the participant can identify—not the artificial removal of an essential feature.

The commercial architecture has six layers:

The company should launch these streams in sequence. Registry-generated opportunity fees and selected transaction or managed-service revenue are the earliest hypotheses. Payment, premium and studio revenue expand only when the underlying service, legal structure and cost-to-serve are proven.

18.1 Registry-generated design fees

The Registry may generate qualified Client opportunities through its website, referrals, studio activity, partnerships, content and future campaigns. When a Registry-originated opportunity becomes a signed and collected Designer engagement, the working assumption is that The Design Registry earns 20% of the collected Designer service fee.

The fee does not apply to the total Project budget, Provider Work Orders or product spend unless a separate disclosed arrangement governs those transactions. Designer-originated leads do not incur the opportunity fee merely because the Designer manages the Project in the platform.

The revenue record must preserve:

• source and original attribution;
• qualification and matching history;
• Designer acceptance;
• executed Client and Designer agreement;
• applicable rate and fee basis;
• collection milestones and refunds;
• Registry Invoice or allocation;
• dispute and adjustment history; and
• recognized revenue after collectability requirements are met.

The fee is earned for demand creation, qualification and matching—not for assuming the Designer's professional responsibility. Commercial agreements must define whether the Registry collects the fee directly, receives an allocation through platform payments or invoices the Designer after collection.

18.2 Provider marketplace economics

Provider economics must reflect the actual service performed by the Registry. One universal percentage is unlikely to fit product supply, photography, storage, delivery, millwork and construction work equally.

Possible models include:

• Referral fee
• Transaction fee
• Negotiated volume rebate
• Platform service fee
• Payment processing margin
• Managed-service markup

Rates must be category-specific, contractually clear and compliant with applicable disclosure, tax, competition and professional obligations.

The commercial policy for each Provider category must answer:

1. Who pays the Registry and why?
2. Is the fee fixed, percentage-based, tiered, subscription-based or negotiated?
3. What event makes the fee earned?
4. Does the Registry touch the underlying funds?
5. Who bears processing, refund, claim and non-payment costs?
6. What is disclosed to each contracting participant?
7. Which work can occur outside platform payments without violating the agreement?
8. How are cancellations, scope reductions and Change Orders treated?

The goal is not to make off-platform work impossible through contractual friction. The goal is to make the in-platform workflow—scope, acceptance, evidence, Invoicing, payment visibility and history—valuable enough that participants prefer to keep the transaction connected.

Provider revenue is recognized on the Registry's actual fee or commission, not on pass-through Work Order value. Gross Work Order value is an operating metric; it is not company revenue unless accounting policy determines the Registry is the principal in that transaction.

18.3 Procurement and products

Product and procurement economics can arise through several structures:

• a Vendor commission or referral payment where the Vendor is seller of record;
• a trade-to-client spread where an authorized business buys and resells the product;
• a disclosed procurement or purchasing service fee;
• negotiated volume economics from approved Vendors;
• catalogue, data or integration arrangements; and
• managed receiving, claims, delivery or installation services linked to the order.

A prior working assumption was approximately 15% net contribution on participating furniture sales, but the new company should validate this by Vendor, Designer agreement and actual fulfilment cost.

The 15% goal is a net contribution target, not an automatic markup applied to every product. The order model must account for discounts shared with the Client or Designer, payment cost, freight, duty, receiving, storage, damage, returns, warranty support, procurement labour, tax and credit risk.

Product revenue must be separated by commercial structure:

The platform must maintain Item-level economics so management can identify apparent margin that disappears through labour or exceptions.

18.4 Payments and financial operations

Payments can strengthen the commercial record and reduce leakage, but they introduce material cost, compliance and service obligations. The intended model supports Stripe-enabled payment where appropriate, bank-based payment for large amounts, and recorded manual payments when funds move outside the platform.

Potential revenue may include an approved platform payment fee, payment-processing margin where lawful and commercially viable, instant or managed payout services, or bundled financial administration. Payment revenue must never be presented without the associated processing cost, reserve, refund, chargeback, KYC and support burden.

The Registry should not subsidize card processing on large transactions unless the price explicitly covers it. The system can preserve payment status and reconciliation value even when the most economical funds flow occurs by bank payment.

18.5 Premium software

Premium software is optional and follows proven adoption. It should monetize advanced control, scale, usage or business complexity rather than basic collaboration.

• Custom domain
• Advanced branding
• Multiple business entities/brands
• Advanced reporting
• Expanded automation/AI usage
• Premium integrations
• Data/API services
• Additional storage or communication volume

Potential pricing dimensions include Workspace, location, teammate band, usage, connected account, transaction volume and implementation complexity. The company should not publish broad packages until it understands infrastructure cost, support cost, willingness to pay and the free/premium boundary.

Core Project records, essential Client participation and basic Provider collaboration should not become artificially unusable in the free tier. Appropriate premium candidates are capabilities with real incremental cost or enterprise value, such as high-volume communications, advanced AI, multi-location operations, specialized integrations, managed migration and API access.

18.6 Managed services

Managed services convert internal expertise or direct labour into revenue when the scope can be standardized and measured. Possible offers include:

• Project and spreadsheet migration;
• managed procurement;
• product-data normalization;
• Provider sourcing or coordination;
• presentation and Registry preparation;
• data cleanup and close-out; and
• specialized onboarding or integration implementation.

Every managed service requires a defined deliverable, exclusions, service level, direct time tracking and target gross margin. The company should not hide unlimited human service inside free software or mistake founder onboarding work for scalable revenue.

18.7 Studio services

• Events and education
• Optional membership/services
• Vendor presentations/programs
• Sample-management programs
• Lead generation and Project service contribution

Each location must have its own operating statement distinguishing direct revenue, transaction contribution, acquisition value and community benefit. A location is not economically successful because it feels aligned with the brand; it must either cover its direct cost or produce measurable, approved acquisition and retention value.

18.8 Revenue sequencing

The recommended sequence is:

1. Prove free Designer activation and Provider workflow participation.
2. Validate Registry-generated opportunity fees on a small number of collected Projects.
3. Launch one or two category-specific Provider transaction models with clear unit economics.
4. Validate product/procurement contribution using real orders and full landed cost.
5. Add payment services only after funds flow, compliance and reconciliation are designed.
6. Introduce premium software where repeated demand and cost justify it.
7. Expand managed services and studio programs only with explicit capacity and margin controls.

No revenue stream should be scaled until management can calculate recognized revenue, direct cost, support labour, refunds/claims, contribution margin and participant retention for the relevant cohort.

18.9 Revenue principles

Core software should remain valuable without mandatory marketplace use. Monetization should align with successful work and optional advanced value.

Additional principles:

• Revenue follows a visible value event.
• The payer and fee basis are explicit.
• Commercial confidentiality is never used as a reason to mislead the party bearing the fee.
• Pass-through funds and gross merchandise value remain separate from recognized revenue.
• Pricing reflects category risk and service intensity.
• AI and automation improve contribution margin but do not excuse poor service controls.
• Retention comes from operating value, not data captivity or punitive leakage clauses.
• Every stream has an owner, accounting policy, agreement, reconciliation process and stop rule.

19. Illustrative Unit Economics

All figures below are planning assumptions, not forecasts.

19.1 Registry lead example

Average Project budget: $45,000
Average design fee assumption: 15% = $6,750
Registry share: 20% = $1,350
Designer share: $5,400 before their costs/taxes

19.2 Provider transaction example

Provider Work Order: $8,000
Illustrative marketplace contribution: 5% = $400

Actual marketplace rates may be fixed, tiered or negotiated.

19.3 Furniture transaction example

Furniture/product volume: $25,000
Illustrative Registry net contribution: 10% = $2,500

Contribution must account for discounts, payment cost, returns, support, claims and tax treatment.

19.4 Customer acquisition logic

Free software and the website plugin reduce the need to recover a traditional SaaS customer-acquisition cost solely through monthly subscriptions. The economic objective is to acquire a participating studio and earn contribution across multiple downstream Projects over time.

20. Five-Year Illustrative Scenario

This model is intentionally conservative and should be replaced with a spreadsheet financial model after pilot pricing and conversion data exist.

Illustrative revenue drivers:

• Registry-generated design-fee share
• Provider transaction contribution
• Product/procurement contribution
• Premium software/services
• Studio and Vendor programs

The plan should be managed against contribution margin and cash needs, not vanity transaction volume.

21. Go-to-Market Strategy

21.1 Designer-first acquisition

The initial acquisition model is deliberately near-zero-cost and relationship-led. The Registry does not buy broad awareness before it proves that Designers will activate, invite Providers and keep a live Project current.

Acquisition should translate the brand belief into the Designer's immediate reality:

• Cultural truth: exceptional design work is scattered and too easily forgotten.
• Designer tension: the professional who creates the vision becomes the manual integration layer for every decision, spreadsheet and external party.
• Product resolution: one active Project can be organized into a shared operating record without surrendering the Designer's brand or relationships.
• Enduring reward: the work becomes a beautiful Registry worthy of the home and everyone who contributed.

This sequence allows emotional differentiation and practical value to reinforce each other. Outreach should not open with a long platform tour. It should recognize the Designer's work, identify one real coordination burden and offer to make one active Project easier.

Channel order:

1. Personalized founder-led LinkedIn outreach to independent and emerging Designer Studios.
2. Thoughtful Instagram engagement and direct outreach grounded in the Designer's actual work.
3. Warm introductions from Designers, Providers, advisors and industry contacts.
4. Designer-to-Designer referrals created after a successful onboarding or workflow milestone.
5. Design-school alumni, local professional communities and small working sessions.
6. Educational content created from real operational problems observed during onboarding.

The call to action is not “book a software demo.” It is an invitation to show the Registry how the Designer currently runs one active Project and, when there is fit, receive free hands-on help organizing that Project in the platform.

The activation offer is:

• free Workspace access;
• free migration of one live spreadsheet or Project;
• a guided Project setup session;
• preservation of the Designer's brand, clients, fees and Provider relationships; and
• direct support until the first useful external workflow is complete.

21.2 Value proposition

Bring the Project you are managing today. Keep your clients and fees. We will help organize the work around you.

21.3 Provider acquisition

Provider acquisition follows active Project demand. Designers are the primary distribution channel because they already know the Vendors, fabricators, trades, photographers, warehouses, delivery teams and installers involved in their work.

1. The Designer imports or creates a live Project.
2. The platform identifies the Provider Categories and named businesses already involved.
3. The Designer sends a Project-scoped invitation with a clear operational reason to join.
4. The Provider enters through the relevant Offer, quote request, receiving list, delivery manifest or other real work—not a generic marketplace profile.
5. The Registry verifies the Provider in proportion to the risk and category.
6. The Provider receives category-specific tools plus free CRM, Project, Proposal, Work Order and invoicing capability.
7. After completing useful work, the Provider may invite its own teammates, refer other Providers and introduce additional Designers.

Founder-led Provider recruitment is reserved for categories where active Projects lack coverage, capacity or quality. The Registry does not build a large inactive directory.

21.4 Client lead acquisition

• Website intake
• Studio locations
• Local partnerships
• Referral programs
• Designer and Provider cross-referrals
• Educational content/events
• Carefully measured local paid search/social after funnel validation

21.5 Market launch sequence

1. Build a named list of high-fit independent Designers.
2. Start personalized LinkedIn and Instagram conversations.
3. Recruit a five-to-ten-Designer founding cohort.
4. Import one active Project for each participating Designer.
5. Ask each Designer to invite one Provider already involved in that Project.
6. Complete the first useful cross-business workflow.
7. Ask for a Designer or Provider referral only after value is demonstrated.
8. Recruit missing Provider coverage around real Project demand.
9. Publish operational proof, case studies and educational content with permission.
10. Add Registry-generated client leads and paid experiments only after activation, retention and referral behaviour are proven.
11. Expand categories or markets only when local Project and Provider density supports reliable service.

22. Network Quality and Governance

22.1 Provider standards

• Identity and business validation
• References
• Insurance/licences as applicable
• Portfolio/capabilities
• Service area
• Capacity
• Documentation quality
• Professional conduct
• Performance history

22.2 Designer standards

• Professional identity
• Portfolio/service fit
• Client conduct
• Capacity
• Appropriate agreements
• Responsiveness to matched leads
• Project performance and platform conduct

22.3 No paid placement principle

Providers should not buy hidden ranking priority. Sponsored visibility, if ever introduced, must be clearly labeled and should not override qualification or fit.

22.4 Complaints and appeals

• Evidence-based review
• Notice and response opportunity
• Proportionate restrictions
• Appeal path
• Audit record

23. Legal, Financial and Trust Considerations

23.1 Agreements

Required agreement families:

• Platform Terms
• Workspace agreement
• Designer membership/network agreement
• Provider agreement
• Registry-generated lead agreement
• Client consent and Project agreements
• Payment terms
• Data-processing/privacy terms
• Studio-location terms

23.2 Fee disclosure

Marketplace fees, commissions, referral arrangements and markups must be reviewed by counsel and disclosed to relevant parties where legally or contractually required. The business should not depend on misleading participants about financial interests.

23.3 Payments

Stripe architecture must consider:

• Merchant of record versus platform role
• Funds flow
• Tax
• Chargebacks
• Refunds
• Provider onboarding/KYC
• Payout timing
• Reserves
• Disputes
• Canadian payments regulation

23.4 Liability

The platform must clearly separate:

• Designer professional responsibility
• Provider work responsibility
• Registry matchmaking/platform role
• Studio-location premises responsibility
• Payment administration

23.5 Insurance

Evaluate:

• Commercial general liability
• Technology E&O
• Cyber insurance
• Directors and officers
• Studio premises
• Professional liability exposure

24. Operating Model

The Design Registry is designed to operate as a software-led, AI-assisted network company. The company should not reproduce the administrative overhead it is trying to remove for Designers. Internal operations are therefore built into the same platform architecture used by Designer and Provider Workspaces.

The Admin experience is the control plane for the network. It uses the same shared Profiles, Pipelines, Forms, Tasks, Calendars, Communications, Commercial Records, Notifications, Data Grids, Automations, Files, Notes, Activity and Reporting modules as external Workspaces. Admin receives additional governance, cross-network, market, quality, finance and exception capabilities. When the company improves a shared module for internal operations, Designers and Providers should benefit from the same underlying behaviour where permissions and context permit.

The operating objective is:

Automate preparation and routine progression; centralize exceptions; preserve human authority for relationships, judgment, money, quality and risk.

24.1 Lean central team

The early company keeps full-time hiring minimal by combining clear process ownership, reusable software, AI preparation, specialist contractors and explicit escalation rules.

Required functions remain:

• Founder/CEO
• Product/engineering
• Designer success and onboarding
• Provider/network operations
• Studio/community operations
• Finance/reconciliation
• Legal/compliance support

One person may hold several functions, but every function must still have a named accountable owner. “Handled by AI” is not an ownership model. AI performs defined tasks; a person owns the outcome, service level, escalation and correction process.

Hiring should occur only when one of four conditions is demonstrated:

1. Judgment capacity: consequential decisions exceed the accountable person's safe capacity.
2. Relationship capacity: Designers, Providers or Clients cannot receive the required human service level.
3. Exception capacity: repeated exceptions remain unresolved after workflow and automation improvements.
4. Specialist requirement: legal, finance, security, technical or category expertise cannot responsibly be automated or handled fractionally.

Before hiring for repetitive administration, the company must first document the work, remove unnecessary steps, configure the Admin workflow, add instrumentation and evaluate safe automation.

24.2 Market operations

Each market needs accountable ownership for:

• Designer recruitment
• Provider density
• Lead quality
• Studio activity
• Match outcomes
• Service issues
• Local partnerships

The market operator works from a market-specific Admin dashboard showing supply coverage, activated Designers, active Projects, applications, lead response, match readiness, Offers, Work Orders, operational exceptions, complaints, transaction status and retention. The dashboard should answer where human attention is required rather than reproduce every underlying record.

Ottawa is the first market operating cell. Toronto or another market should not launch until the Ottawa routines, dashboards, service levels and escalation paths can be operated by someone other than the founders for two consecutive quarters.

24.3 AI leverage

AI handles preparation, extraction, classification, summarization, drafting, monitoring and prioritization. Human staff focus on relationships, judgment, exceptions, quality, approvals and accountability.

The internal AI operating manager monitors the full network:

Applications → onboarding → Project activation → Client decisions
→ Provider coverage → matching → Offers → Proposals → Work Orders
→ Items and shipments → receiving → storage → delivery → installation
→ Invoices and payments → complaints → retention → Registry completion

It may identify missing information, assemble a case summary, recommend a next action, prepare a message, detect an expired credential, flag an unmatched payment or predict a schedule risk. It does not independently approve a Provider, award work, change binding terms, release money, suspend an account, resolve a serious complaint or send a consequential external communication without the configured human authority.

Every AI-supported operation must expose its source records, confidence or uncertainty, suggested action, responsible human owner and resulting audit event. Correction rates and false-positive rates are operating metrics.

24.4 Admin control plane

The Admin application should be organized around operational queues rather than departmental silos. Core queues include:

Each queue uses consistent priority, owner, service-level clock, status, reason, linked records and resolution code. AI can rank and summarize; a human owns the queue policy.

24.5 Reusable Admin architecture

Admin capabilities are extensions of shared product modules:

• The Admin application Pipeline uses the same versioned Pipeline Builder that Designers and Providers use for CRM Pipelines.
• Admin intake and evidence requests use the same Form and Field system used for public applications and Project records.
• Admin review pages use the same Profile, Notes, Files, Tasks, Communication, Activity and History modules used throughout the platform.
• Admin operating queues use the same enterprise Data Grid and saved-view architecture available to external Workspaces.
• Admin Notifications use the same editable Notification Builder and channel delivery infrastructure.
• Admin commercial review uses the same Offer, Proposal, Work Order, Invoice and Payment records participants see through scoped views.
• Admin reporting uses the same governed metric definitions with broader network visibility.

This architecture reduces engineering duplication, improves consistency and creates a direct product-development loop. Internal users discover workflow gaps first; improvements can then be released safely to Designer or Provider Workspaces through configuration and permissions.

Admin-only capabilities remain limited to genuine governance needs, including cross-Workspace search, market-wide supply/demand, application decisions, match governance, fee/revenue oversight, complaints, eligibility, access audits, integration health and platform-wide reporting.

24.6 Automation model

Automation is configured as visible trigger-condition-action recipes. Examples include:

• Application submitted → create review Task, run completeness check and send acknowledgement.
• Required credential expiring → notify Provider, create follow-up and restrict new matching only after policy conditions are met.
• Qualified lead waiting beyond service level → escalate to market operator.
• Provider shortage for an active scope → create recruitment queue item by category and market.
• Proposal accepted → create Work Order draft, update budget commitment and schedule required kickoff work.
• Purchase Order expected date missed → request status and flag procurement risk.
• Item received damaged → create exception, notify authorized parties and start claim evidence checklist.
• Delivery scheduled without readiness → block confirmation and explain missing prerequisites.
• Invoice paid → allocate payment, update commercial status and prepare accounting sync.
• Project completing → run Registry readiness check and create missing close-out Tasks.

Every automated action is logged. Reversible changes can be undone; irreversible actions require stronger approval. Failed automation enters an error queue with a visible participant impact and manual fallback.

24.7 Service levels and escalation

The company should define service levels before volume makes them informal. Initial policies should cover:

• application acknowledgement and review;
• qualified lead response and Designer matching;
• urgent Project or Client communication;
• payment and reconciliation exceptions;
• receiving damage and delivery-day issues;
• Provider complaints and appeals;
• security, privacy and residential-access incidents; and
• failed integrations or notifications.

Service levels are measured from durable events, not spreadsheets maintained after the fact. Breaches appear in Admin queues and reporting. AI may predict a likely breach, but it cannot close the record merely because a message was sent.

24.8 Exception-first staffing model

The company should measure human workload by exception type and resolution time. A rising queue can mean additional staffing is needed, but it can also reveal poor product design, incomplete participant incentives or an automation failure.

The operating review asks in order:

1. Should this work exist?
2. Can the participant complete it at the source?
3. Can a shared workflow eliminate duplication?
4. Can automation prepare or complete it safely?
5. Can AI reduce the reading, extraction or drafting burden?
6. Does the remaining judgment or relationship work require more human capacity?

This sequence protects the lean model without allowing automation to degrade service.

24.9 Operating data and management cadence

Admin events produce a common operating dataset across acquisition, activation, Project health, Provider performance, commercial activity, service levels, integration quality and Registry completion.

Daily: critical Client/Project exceptions, payment issues, damage, delivery-day events, security incidents and failed integrations.

Weekly: Designer activation, Provider coverage, matching, Work Order exceptions, support themes, automation failures and product friction.

Monthly: cohort retention, contribution margin, service-level performance, AI quality, complaint patterns, market health and capacity.

Quarterly: pricing, free/premium boundary, hiring gates, market expansion, risk register, data governance and roadmap sequencing.

Management reporting must distinguish operational volume from outcomes: applications from approved and activated Providers; accounts from active Projects; transaction value from recognized revenue; AI actions from accepted and correct outcomes.

24.10 Human trust remains visible

A lean operating model must not feel absent. Designers and Providers should know who owns their relationship, how to reach a person and when an issue has been escalated. The brand promise depends on calm confidence; opaque automation, circular bot responses or unexplained decisions would undermine it.

AI makes the team more prepared. Automation makes routine work reliable. Neither replaces professional accountability.

25. Product Roadmap

The roadmap is sequenced around risk reduction rather than feature volume. Each Phase must prove a behaviour needed by the business model before the company invests in the next layer. Shared components are completed early because Admin, Designer, Client and Provider experiences all depend on them.

Phase 1 — Foundation and rebrand

• Design Registry identity
• Authentication
• Users/Teams
• Workspace profiles and branding
• Existing pipeline stabilization
• Supabase production foundation

Business outcome: A Designer or Provider enters the correct branded Workspace with a durable identity, understandable profile and safe access. Internal Admin can operate applications and records without legacy terminology or local-only data assumptions.

Exit evidence: Authentication, Workspace membership, shared profiles, standardized fields and core navigation work across representative user types; production data architecture and audit requirements are approved.

Phase 2 — Provider network

• Canonical Provider categories
• Applications
• Approval/provisioning
• Provider directory/profiles
• Matchmaking profiles
• Provider dashboards

Business outcome: Qualified Providers can apply, be reviewed, become searchable Entities and receive tailored Workspaces. Admin can understand local category coverage and Designers can identify relevant, eligible Providers.

Exit evidence: At least ten approved Providers across priority categories complete onboarding and maintain accurate profiles without repeated manual intervention.

Phase 3 — Commercial loop

• Work Packages
• Offers
• Proposals
• Commitments
• Work Orders
• Notifications

Business outcome: A Project need can become a confidential Offer, versioned Proposal and accepted Work Order without re-entering scope. Every participant sees the correct commercial state and related notifications.

Exit evidence: Real Work Orders complete with accepted scope, evidence and a reliable history; commercial exceptions can be resolved from Admin queues.

Phase 4 — Provider operations

• Warehouse receiving/condition/storage
• White-glove dispatch/tracking/proof
• Installation/deficiencies
• Vendor product/order workflows
• Additional category operations

Business outcome: External businesses keep the physical Project record current because the portal improves their own work. The Designer spends less time chasing receiving, condition, shipment, delivery and installation status.

Exit evidence: Priority categories complete real mobile workflows, most required updates occur without Admin chasing, and repeat Provider participation is observed.

Phase 5 — Invoicing and payments

• Invoices
• Stripe
• Provider payouts
• QuickBooks
• Reconciliation

Business outcome: Accepted work becomes an Invoice and accurate payment state without breaking the connection to Project scope, budget or accounting. Large and small payment methods are supported appropriately.

Exit evidence: Finance reconciles representative transaction types, payment exceptions have fallbacks, and recognized revenue can be separated from pass-through value and fees.

Phase 6 — Growth systems

• Website plugin
• Registry lead funnel
• Studio-location operations
• Advanced AI
• Reporting and market expansion tooling

Business outcome: The company can acquire, activate and support a second cohort or market without proportional founder labour. Designers can capture their own leads, and Admin can monitor network and revenue performance through governed reporting.

Exit evidence: Ottawa meets activation, retention, service-level and contribution gates for two quarters; a non-founder operator can run the documented weekly cadence.

Phase 7 — Permanent Registry and aftercare

• Registry readiness and close-out
• Permanent home chapters
• Final installed specifications
• Warranty, manual and care library
• Contributor attribution
• Client ownership and long-term access
• Future Project and service linkage

Business outcome: The product fulfils the central promise. A completed Project becomes a coherent, permissioned and useful Registry for the professionally designed home.

Exit evidence: Completed Registries remain understandable without the active delivery team, Clients can find approved home information, and future authorized work can begin from the preserved record.

26. Key Performance Indicators

Metrics must follow stable definitions and drill down to the records producing them. The company should distinguish acquisition, approval, activation, recurring use, network participation, monetization and retention. An account is not active merely because a User signed in, and gross transaction value is not revenue.

The proposed company-level north star is Monthly Network-Activated Projects: active Projects in which a Designer and at least one Client or Provider complete a meaningful workflow during the month. This should be paired with Monthly Coordinated Project Value, Registry readiness and Project contribution margin so engagement is not optimized without quality or economics.

26.1 Designer adoption

• Applied/approved/activated Designers
• First Project imported
• Weekly/monthly active studios
• Active Projects per studio
• Feature adoption
• Retention
• Provider invitations

The primary activation milestones are Workspace completed, first real Project created/imported, first recurring Project action, first Client action and first Provider workflow. Cohorts are tracked at 7, 14, 30, 60 and 90 days. Management should separate product inactivity from Projects that have legitimately completed or paused.

26.2 Lead funnel

• Qualified leads
• Match time
• Designer response
• Consultation booked
• Proposal sent
• Project won
• Design fees collected
• Registry contribution

Lead reporting must preserve source and match cohort from first inquiry through collected fee, refund and completion. Speed alone is not success: qualification, Designer fit, Client satisfaction and contribution after labour must accompany conversion.

26.3 Provider marketplace

• Qualified Providers by category/market
• Match-to-Offer rate
• Offer response time
• Proposal/award conversion
• Work Order value
• On-time performance
• Exceptions/claims
• Invoice/payment cycle
• Repeat selection

Provider activation requires a real operating action. Category reporting should distinguish invited, applied, approved, first action, accepted work, completed work and retained Provider. The most important behavioural metric is the percentage of required updates completed without manual Designer or Admin chasing.

26.4 Client experience

• Approval time
• Missed decisions
• Delivery exceptions
• Satisfaction
• Referrals

Client reporting is intentionally limited to meaningful service outcomes. Portal engagement is useful only when it improves decisions, understanding or confidence. The company should monitor complaint resolution, approval-version integrity, financial clarity and the completeness of the final Registry.

26.5 Studio locations

• Designer utilization
• Client appointments
• Events/attendance
• Leads generated
• Match conversion
• Product/Provider activity
• Contribution relative to occupancy cost

Location performance must distinguish direct revenue, attributable acquisition, assisted retention and unpriced community activity. A studio should not receive an indefinite strategic-value exemption from an operating statement.

26.6 AI

• Suggested actions accepted
• Time saved
• Extraction accuracy
• Match-quality measures
• Human override rate
• Harm/privacy incidents

AI metrics are defined per use case. A high acceptance rate can still hide factual error, automation bias or unnecessary output. Quality review includes grounded-source coverage, correction rate, false-positive exceptions, latency, cost, participant impact and the severity of any mistake.

26.7 Admin and operating leverage

• Active Projects per internal full-time-equivalent
• Applications reviewed per human hour
• Percentage of routine transitions completed automatically
• Exceptions created, resolved and reopened by type
• Median exception age and service-level breach rate
• Human touches per activated Designer and Provider
• Founder hours per activation and per market
• AI-prepared cases accepted without material correction
• Notifications and integrations succeeding without intervention
• Support contacts per active Project
• Cost to support one active Studio, Provider and Project

These measures govern the lean-hiring strategy. The objective is not to maximize automation volume; it is to increase reliable Project and network capacity per internal team member while maintaining satisfaction, safety and resolution quality.

26.8 Financial quality

• Recognized revenue by stream
• Gross transaction and product value shown separately
• Direct cost and contribution margin by stream/category
• Support and managed-service labour per transaction
• Payment processing, refund, claim and bad-debt cost
• Effective fee/take rate
• Days to collect and reconcile
• Revenue leakage and off-platform completion
• Cohort payback and twelve-month contribution retention

Management should review contribution after direct human effort. AI or automation savings become financially meaningful only when they reduce cost-to-serve or allow the existing team to support greater quality-adjusted volume.

26.9 Metric governance

Each executive metric requires a name, definition, owner, source tables, calculation, refresh frequency, audience, privacy classification and change history. If a definition changes, historical reports disclose the break or are recomputed consistently. Dashboards should never allow different departments to use the same label for different calculations.

27. Risks and Mitigations

27.1 Marketplace cold start

Risk: insufficient Designers or Providers in a market.

Mitigation: launch one market, prioritize essential categories, let Designers bring existing Providers and operate a curated network.

27.2 Free software cost

Risk: support and infrastructure grow faster than transaction contribution.

Mitigation: disciplined feature scope, AI-assisted onboarding, usage limits, premium tiers and contribution monitoring.

27.3 Workflow complexity

Risk: building nine Provider portals becomes unmanageable.

Mitigation: shared modules plus category configurations; build warehouse/delivery first where network value is clearest.

27.4 Designer trust

Risk: Designers fear client or brand disintermediation.

Mitigation: Designer Promise, optional marketplace use, data export, branding and contractual clarity.

27.5 Provider adoption

Risk: Providers resist another portal.

Mitigation: free business tools, fewer incomplete quote requests, operational utility, payment visibility and integrations.

27.6 Payments and regulatory exposure

Risk: funds flow creates compliance, dispute and cash risks.

Mitigation: specialist counsel, Stripe Connect architecture, staged rollout and clear merchant responsibilities.

27.7 AI risk

Risk: incorrect extraction, poor matches, data leakage or over-automation.

Mitigation: human approvals, access-aware retrieval, evaluation, audit and limited authority.

27.8 Studio fixed costs

Risk: physical locations consume cash before network density exists.

Mitigation: pilot, flexible leases/partnership models, measurable acquisition role and expansion gates.

27.9 Competitive response

Risk: established software adds marketplace features.

Mitigation: local network density, Provider operating depth, studio infrastructure, data and trusted relationships.

28. Funding and Capital Priorities

Primary uses of capital:

• Product and engineering
• Security and production infrastructure
• Designer/Provider onboarding
• Marketplace operations
• Studio pilot
• Legal/payment architecture
• Integration development
• Controlled go-to-market testing

Avoid excessive early spend on broad advertising before proving:

• Designer activation
• Project retention
• Lead qualification
• Match conversion
• Provider operational adoption
• Transaction contribution

29. First 18-Month Execution Plan

Months 0–3

• Finalize brand/legal structure
• Rebrand platform
• Complete identity and Workspace foundation
• Recruit founding Designers
• Import live Projects
• Formalize canonical Provider categories
• Recruit founding warehouse, delivery and Vendor partners

Months 4–6

• Provider applications/profiles
• Matchmaking foundation
• Offers and Proposal prototype
• Website plugin alpha
• AI extraction/import assistant
• Studio pilot planning

Months 7–9

• Work Orders
• Warehouse receiving/condition workflow
• Delivery tracking pilot
• Client portal refinement
• Registry lead pilot
• Stripe/QuickBooks design

Months 10–12

• Invoicing/payment pilot
• Installation workflow
• Provider business CRM
• Studio activation/events
• Unit economics review

Months 13–18

• Improve retention and workflows
• Expand Provider categories
• Validate lead fee model
• Assess Toronto/second-market readiness
• Prepare institutional funding or disciplined expansion plan if metrics support it

30. Strategic Milestones

The business should not expand merely because the software is visually complete.

Pilot success requires evidence that:

1. Designers import and actively manage real Projects.
2. Providers update operational records without repeated chasing.
3. Clients use approvals and payments.
4. Match recommendations lead to suitable accepted work.
5. Registry-generated leads convert at sustainable economics.
6. The studio creates qualified activity.
7. Marketplace contribution covers variable operating costs.
8. The product architecture can support another market.

31. Final Strategic Position

The Design Registry should not describe itself as another project-management application.

It is:

• The operating system for the Designer’s business
• The shared operational layer for the physical Project
• The private network through which trusted Providers are discovered and engaged
• The client experience through which decisions and payments remain clear
• The local studio infrastructure that creates trust and market density
• The AI-supported operations team that helps independent studios behave like larger, better-resourced firms

The strongest defensible idea is simple:

Existing tools help a Designer manage a Project. The Design Registry connects the people and businesses required to complete it.

If executed with discipline, The Design Registry can give independent Designers the operating leverage of a larger firm while preserving the independence, creativity and client relationships that make their studios valuable.

32. Detailed Strategic Thesis

32.1 What the company is building

The Design Registry is building a vertical operating network, not a conventional subscription application and not an open lead marketplace. A vertical operating network combines four assets that are usually separate:

1. System of record. The Project, Client, Item, Provider, Work Order, Invoice and payment records required to coordinate work.
2. System of action. Tasks, approvals, offers, receiving, delivery, installation and exception workflows that cause participants to update the record as work occurs.
3. Trusted network. Verified Designers and Providers with structured profiles, performance history, capacity and category-specific operating data.
4. Commercial layer. Lead origination, Provider awards, product transactions, invoicing, payments and optional services through which the Registry can participate economically.

The business becomes more valuable when these assets reinforce one another. Better software creates more complete Project data. Better data improves coordination and matchmaking. Better matchmaking produces more successful work. More successful work attracts higher-quality Designers and Providers. Greater network density creates more transactions that can fund better software and service.

32.2 The wedge

The initial wedge is not “replace every tool used by every Designer.” It is:

Import the active Project, organize the items and Providers around it, and make the next external handoff measurably easier.

The first moment of value should occur within the first onboarding session. A Designer should be able to upload or paste a spreadsheet, create or import a Project, invite one Provider and leave with a clearer next action than they had before. Requiring a complete system migration before value appears would materially increase adoption risk.

32.3 Why free core software can be rational

Free core software is a distribution strategy, not an absence of a business model. It is rational only if the following conditions hold:

• Active Designers create Projects that can generate future commercial opportunities.
• Providers receive enough operating value to accept work and maintain status within the platform.
• The Registry can monetize a minority of Projects without degrading the free experience.
• Variable support and infrastructure costs remain bounded.
• Premium or managed services exist for users who create disproportionate operational cost.
• Data and network benefits are earned through actual participation, not by claiming ownership over user relationships.

Management should review the free boundary quarterly. Features essential to running a real Project should remain accessible. High-cost automation, advanced analytics, extensive storage, custom integrations, white-labeling, managed procurement and priority support may become premium.

32.4 Defensibility

The Registry's moat will not be a single feature. Feature parity can be copied. Defensibility is expected to come from the combination of:

• Structured operating history across multi-business Projects
• Category-specific Provider workflows and evidence
• Local supply density and trusted working relationships
• Match outcomes and performance feedback
• Embedded website lead capture
• Transaction and payment history
• Designer and Provider switching costs created by accumulated Project records
• Brand trust built through selective participation rather than open-listing volume
• Operating playbooks for launching and governing a new market

No individual data point should be treated as proprietary leverage against a participant. The defensible asset is the network's normalized operating model and the quality of execution around it.

33. Customer Personas and Jobs to Be Done

33.1 Emerging Designer owner

Profile: Solo principal or two-to-three-person residential studio. Strong taste and client relationships. Annual revenue may be below the industry top quartile. Administrative processes are personally maintained.

Primary jobs:

• Win appropriate clients without spending heavily on marketing
• Present a polished and trustworthy client experience
• Translate design intent into specifications, budgets and orders
• Coordinate Providers without becoming a full-time dispatcher
• Know what is late, damaged, over budget or waiting for approval
• Get paid on time
• Grow without immediately hiring a large operations team

Current alternatives: Spreadsheets, email, shared drives, accounting software, text messages and point solutions.

Adoption barriers: Fear of migration effort, fear that a platform will own the client, concern about exposing pricing, resistance from Providers and limited time to learn new software.

Required proof: A live Project becomes easier within one week; the Designer remains visibly in control; imported data is not trapped.

33.2 Established boutique studio

Profile: Principal-led studio with Designers, project managers or procurement support. Existing processes are more mature, but information is still fragmented across tools and team members.

Primary jobs:

• Standardize execution without flattening the studio's creative process
• Manage capacity and ownership across Projects
• Reduce errors in procurement, receiving and installation
• Maintain branded client communication
• Compare Project performance
• Extend operational capacity through trusted external Providers

Adoption barriers: Existing software contracts, custom spreadsheets, team-change risk, permissions and data-security requirements.

Required proof: Controlled migration, configurable workflows, reliable roles, integrations and reporting that justify organizational change.

33.3 Provider owner

Profile: Independent business serving design and residential projects. May be a Vendor, fabricator, trade, photographer, drafter, receiver, warehouse, delivery company or installer.

Primary jobs:

• Receive complete opportunities instead of incomplete email requests
• Quote quickly using reusable templates
• Convert accepted proposals into operational work
• See the exact items, locations, dates and evidence required
• Coordinate staff and schedule capacity
• Invoice and collect payment
• Build a trusted track record that leads to more appropriate work
• Operate the rest of the business through the same CRM and invoicing tools where useful

Adoption barriers: Concern about platform fees, duplicated administration, unfamiliar systems, payment timing and loss of the direct customer relationship.

Required proof: The portal eliminates work the Provider currently performs manually; accepted work is clearer; payment visibility improves; participation does not require abandoning their own business identity.

33.4 Client

Profile: Residential client undertaking decorating, renovation or a design engagement. Often unfamiliar with professional Project processes and sensitive to uncertainty.

Primary jobs:

• Understand what happens next
• Review information without searching long email threads
• Approve selections, proposals and changes confidently
• Know what has been paid and what remains outstanding
• See relevant progress without being exposed to operational noise
• Trust that the Designer is coordinating the Project

Adoption barriers: Another login, unclear responsibility, inconsistent communication or a portal that feels like administrative software.

Required proof: A simple, branded and mobile-friendly experience that reduces rather than adds communication.

33.5 Registry market operator

Profile: Internal team member responsible for Designer and Provider quality, applications, lead routing, exceptions and local network health.

Primary jobs:

• Know which applications require review
• Maintain category coverage without over-supplying the market
• Route leads and work fairly
• Identify stalled Projects and service failures
• Resolve complaints with complete evidence
• Monitor fee obligations and payment exceptions
• Improve network quality without becoming the Project manager for every engagement

Required proof: Exception-based operating dashboards, consistent policies, auditable decisions and AI-supported summaries.

34. End-to-End Participant Journeys

34.1 Designer acquisition and activation

The target journey is:

1. Designer receives a founder introduction, referral or targeted LinkedIn message.
2. Designer visits a role-specific landing page and sees the free operating-system promise.
3. Designer creates an account or submits a light qualification form.
4. Registry verifies identity and studio fit without creating an unnecessarily exclusive or slow process.
5. Designer creates the workspace, applies branding and invites teammates.
6. Guided onboarding asks for one active Project rather than a complete business migration.
7. Designer imports a spreadsheet, selects a Project template and confirms normalized categories.
8. Designer invites an existing Provider or asks the Registry to suggest one.
9. The first live workflow—offer, proposal, receiving record or task—is completed.
10. The Registry measures time to first Project, first collaborator and first completed external workflow.

Activation is achieved only when a real Project contains meaningful data and at least one recurring action. Account creation alone is not activation.

34.2 Provider application and activation

1. Provider is recruited by the Registry, invited by a Designer or discovers the application from the website.
2. Provider selects the correct category and sees the operational value available to that category.
3. The application form captures common business data and category-specific qualification information.
4. The application enters a fixed but configurable review pipeline.
5. Internal reviewers verify insurance, service area, capabilities, references and category-specific evidence.
6. Approved Provider workspace is provisioned with a pending onboarding checklist.
7. Provider configures profile, team, calendar, service area, rates or quoting preferences and payment details as appropriate.
8. Provider receives a training example and then a real offer or Designer invitation.
9. Provider accepts, declines or requests clarification without leaving the system.
10. A Proposal becomes a Work Order, operational evidence is recorded and the Invoice is issued.

Provider activation requires more than approval. The operational target is the first accepted Work Order or the first independently created CRM opportunity within a defined period.

34.3 Registry-generated client journey

1. Client completes a branded intake with budget, location, scope, timeline, style and service needs.
2. Automated validation checks completeness, budget range, geography, spam and obvious incompatibilities.
3. A Registry operator reviews the summarized lead.
4. Matchmaking creates a ranked shortlist with reasons, conflicts and availability indicators.
5. Authorized staff select the Designers who may receive the opportunity.
6. Designers review a privacy-controlled opportunity summary and indicate interest.
7. Client receives a curated introduction or consultation path.
8. Once a Designer is selected, the lead becomes a Client, Project and commercial agreement record without duplicate entry.
9. The Designer owns the ongoing design relationship; the Registry remains visible as the operating platform and originating network.
10. Fee obligations, consent and attribution remain attached to the Project.

The experience should feel curated, not like the client has been sold to a list of bidders.

34.4 Project-to-Provider journey

1. Designer identifies a package of work inside the Project.
2. System validates required scope, items, site information, target dates and attachments.
3. Designer chooses an existing Provider or requests a matched shortlist.
4. Provider receives an Offer containing only authorized Project information.
5. Provider accepts the invitation to quote, declines with a reason or asks a structured question.
6. Proposal is created from the package snapshot.
7. Designer or authorized client reviews, requests revision and accepts.
8. Accepted Proposal becomes a Work Order with preserved commercial terms.
9. Provider completes category-specific operations and uploads required evidence.
10. Changes occur through Change Orders rather than silent scope edits.
11. Provider invoices against milestones or completion.
12. Payment and accounting status synchronize while the full history remains attached to the Project.

34.5 Service recovery journey

Every marketplace creates exceptions. The recovery workflow must be designed before scale:

1. Participant flags an issue against the specific Project, item, Work Order, milestone or payment.
2. System preserves evidence, timestamps and responsible parties.
3. Urgency and client impact are classified.
4. The operational owner receives a time-bound task and notification.
5. Participants communicate in a governed thread.
6. Resolution may produce a replacement, reschedule, credit, claim, Change Order or formal dispute.
7. The Registry documents the outcome and whether performance data should be affected.
8. Sensitive performance consequences remain reviewable and appealable.

35. Provider Category Operating Blueprints

35.1 Common Provider operating model

Every Provider receives a shared commercial foundation:

• Workspace, users and business profile
• CRM contacts and opportunities for Registry and non-Registry work
• Offers and request-for-proposal inbox
• Proposal templates
• Work Orders and changes
• Tasks, calendar and messages
• Files and evidence
• Invoices and payment visibility
• Notifications
• Reporting
• Project-scoped access grants

The Provider's navigation and dashboard then emphasize the operational objects relevant to its category. Category specialization should not create nine separate products. It should configure one shared platform with category modules, terminology, statuses, evidence requirements and dashboards.

35.2 Vendors and product suppliers

Core records: Products, price lists, variants, samples, quotes, purchase orders, acknowledgements, expected ship dates, backorders, returns and credits.

Critical workflow: Designer adds a product or pastes a product URL; AI suggests structured fields with source and confidence; Designer verifies; Vendor confirms price and availability; approved item moves into purchasing; order acknowledgements and shipment updates return to the Project.

Provider value: Fewer incomplete quote requests, clearer specifications, reusable catalogue information, consolidated Designer relationships and better visibility into upcoming demand.

Required controls: Trade-price visibility, minimum order rules, territory restrictions, discontinuation flags, data freshness, return conditions and client-facing price separation.

35.3 Millwork and custom fabrication

Core records: Scope package, site measure, drawing set, finish schedule, revision, approval, deposit, fabrication milestone, delivery and deficiency.

Critical workflow: Provider receives rooms, dimensions, reference images and requirements; submits scope assumptions and pricing; approved Work Order creates measurement and shop-drawing milestones; no fabrication begins until the approved drawing revision and deposit conditions are recorded.

Provider value: Reduced ambiguity, controlled revisions, clearer approvals and consolidated site information.

Required evidence: Measurement sign-off, drawing revision history, material approvals, progress photos, completion photos and deficiency closure.

35.4 Contractors and specialty trades

Core records: Scope, room/location, material responsibility, exclusions, schedule window, site prerequisites, daily update, inspection, deficiency and completion.

Critical workflow: Designer sends a discrete scope rather than the entire Project; Provider quotes labour, materials, allowances and exclusions; accepted Work Order creates scheduled tasks and site-readiness requirements; changes are documented before additional work proceeds except in a safety emergency.

Provider value: Better scopes, fewer coordination gaps, clear documentation and faster invoicing.

Required controls: Licensing where applicable, insurance expiry, health and safety documents, site access, permit responsibility and proof of completion.

35.5 Photography

Core records: Creative brief, property, shot list, styling requirements, schedule, access, usage rights, deliverables, selections and licensing.

Critical workflow: Designer provides the Project vision, rooms and required assets; Photographer confirms scope and availability; shoot schedule coordinates Designer, client and property access; deliverables are uploaded with rights metadata and approval status.

Provider value: Complete briefs, fewer scheduling messages and reusable rights records.

Required controls: Releases, licensing scope, publication embargoes, credit requirements and storage policy.

35.6 Measurement and drafting

Core records: Measurement scope, property access, floor levels, output standard, source files, revision, field condition and approval.

Critical workflow: Designer selects required outputs; Provider schedules the site visit; uploads field notes and draft set; Designer comments against a revision; approved files become authoritative Project references.

Provider value: Standard requests, fewer missing dimensions and a traceable revision process.

Required controls: Accuracy tolerances, exclusions, professional responsibility, file formats and reliance disclaimers.

35.7 Receiving, warehouse and storage

Core records: Shipment notice, purchase order, item, package, receiving appointment, condition, location, storage period, release authorization and outbound manifest.

Critical workflow: Expected items are visible before arrival; warehouse receives against the expected item; scans or searches the record; photographs packaging and condition; records quantity, damage and storage location; immediately notifies authorized participants when an exception occurs.

Provider value: Faster receiving, fewer unidentified packages, documented condition, digital release authorization and more accurate storage billing.

Required controls: Chain of custody, damage classifications, photo retention, location history, release permissions, insurance limits and item-level billing rules.

35.8 White-glove delivery

Core records: Delivery request, manifest, pickup, vehicle/team, route, access constraints, appointment window, live status, proof of delivery, damage and client sign-off.

Critical workflow: Approved items are released from storage; Provider confirms manifest and site constraints; Designer sees scheduled and day-of statuses; location tracking is shared only during the relevant operational window; delivery evidence and exceptions attach to each item.

Provider value: Better manifests, fewer site surprises, simpler dispatch communication and immediate proof of service.

Required controls: Consent for live tracking, limited retention, privacy-safe client visibility, signature rules, unsuccessful delivery terms and claims workflow.

35.9 Installation services

Core records: Install plan, room placement, item readiness, assembly requirement, hardware, team, checklist, punch item and final sign-off.

Critical workflow: Install readiness is computed from item, delivery, site and task dependencies; Provider sees room-by-room instructions; incomplete or damaged items create punch items rather than being silently marked complete.

Provider value: Clear plans, reduced downtime and better evidence for completion and additional work.

Required controls: Site safety, client-property protection, disposal responsibility, punch ownership and completion acceptance.

35.10 General service Providers

The general category must be configurable but not unstructured. Administrators select reusable modules such as scheduling, item access, milestones, evidence, location, inspection, client sign-off and invoicing. If a general category becomes frequent and commercially material, it should graduate into a canonical category with its own qualification and workflow template.

36. Product Packaging and Service Levels

36.1 Free Designer workspace

The free Designer workspace should include enough value to manage genuine work:

• Client and lead CRM
• Core Projects and seven-Phase workflow
• Item, material and budget records
• Spreadsheet import and export
• Tasks, files, notes and calendar
• Client portal
• Provider invitations
• Offers, Proposals and Work Orders
• Basic invoicing
• Standard workspace branding
• Core notifications
• Reasonable storage and usage limits

36.2 Free Provider workspace

• Provider CRM
• Category dashboard
• Registry offers
• Proposals and Work Orders
• Category operating workflow
• Tasks and calendar
• Files and evidence
• Invoices
• Basic client and Designer communication
• Standard profile and branding

36.3 Potential premium modules

Premium packaging should be tested only after the free product demonstrates retention. Candidates include:

• Advanced workspace branding and custom domain
• Additional automation capacity
• AI usage above a fair-use allocation
• Advanced business analytics
• Multiple locations or legal entities
• High-volume catalogue and API synchronization
• Custom accounting mappings
• Priority migration and onboarding
• Managed procurement
• Dedicated support
• Extended storage and document retention
• Advanced team controls once the permissions specification is implemented

36.4 Managed services

The Registry may deliver services that software alone cannot initially automate:

• Spreadsheet migration and cleanup
• Product data entry and normalization
• Provider sourcing
• Procurement administration
• Project documentation preparation
• Lead qualification
• Payment follow-up
• Studio event and sample coordination

Every managed service requires a defined scope, service level, price, owner and gross-margin target. Services should produce reusable operating knowledge and product requirements rather than becoming unlimited bespoke labour.

37. Commercial Architecture

37.1 Revenue principles

The Registry's commercial model should satisfy six tests:

1. Alignment: Revenue increases when a participant receives measurable value.
2. Clarity: The paying party can understand the fee before committing.
3. Compliance: Referral, marketplace, payment and product economics are reviewed by counsel and properly disclosed where required.
4. Portability: Designers can bring and export their own relationships and data.
5. Margin discipline: Revenue is measured net of refunds, payment cost, support, claims and delivery obligations.
6. Optionality: The company does not depend on one fee type before that type is validated.

37.2 Registry-generated design opportunity fee

The working model is a 20% share of the collected design service fee on a Project originated by the Registry. The fee does not apply to a Designer's existing clients or self-generated opportunities unless a separate service is purchased.

The agreement must define:

• What constitutes Registry origination
• Attribution period
• Treatment of repeat phases and repeat client Projects
• Which design-service amounts are included or excluded
• Collection timing
• Refunds and cancellations
• Taxes
• Non-circumvention
• Client and Designer disclosure
• Audit and dispute rights

The fee should be collected automatically when practical, but the initial pilot may use invoicing and reconciliation while the legal and Stripe architecture is validated.

37.3 Provider marketplace economics

Provider economics may vary by category because gross margins, ticket sizes, payment timing and operational value differ. The Registry should avoid imposing a uniform percentage before category testing.

Potential structures include:

• Percentage of successfully paid Work Order
• Fixed platform fee per awarded Work Order
• Provider subscription for advanced tools with lower transaction fees
• Buyer-side managed-service fee
• Negotiated volume rebate
• Product commission or wholesale margin
• Payment-processing markup where lawful and commercially acceptable

The participant who bears the fee must know it. Commercial confidentiality between businesses is different from hiding a fee from the party paying it.

37.4 Product and procurement economics

Product contribution may come from trade discounts, affiliate or referral arrangements, Vendor commission, wholesale-retail spread or a disclosed procurement service fee. Each model has different implications for title, warranty, sales tax, returns, chargebacks and customer support.

The Registry should track:

• Gross merchandise value
• Gross product revenue where the Registry is seller of record
• Net commission where the Vendor is seller of record
• Designer/client discount passed through
• Payment cost
• Freight and delivery revenue or expense
• Returns and damage allowances
• Procurement labour
• Net contribution per order and per Project

The target is not maximum visible markup. It is repeatable contribution without creating distrust or unbounded service liability.

37.5 Premium software and services

Premium revenue should begin with high-value, high-cost or business-critical extensions rather than restricting everyday collaboration. Pricing may include workspace subscription, usage, implementation, location or managed-service components.

Early premium hypotheses:

37.6 Studio-location revenue

Physical locations may generate revenue through membership, meeting rooms, events, samples, Vendor presentations, sponsorships, product sales or Project-service support. The location must have a separate operating statement. Network value does not justify an indefinitely loss-making lease.

38. Detailed Unit Economics

38.1 Core unit definitions

Financial management should use consistent units:

• Activated Designer: A verified Designer workspace with a real Project and qualifying activity in the last 30 days.
• Activated Provider: A verified Provider with an accepted Work Order or meaningful CRM activity in the last 90 days.
• Monetized Project: A Project generating at least one recognized revenue stream.
• Project contribution: Recognized revenue less direct payment cost, refunds, category support, claims, direct service labour and transaction-specific incentives.
• Designer acquisition cost: Direct sales and onboarding cost divided by newly activated Designers, not accounts created.
• Provider acquisition cost: Direct recruitment, verification and onboarding cost divided by newly activated Providers.
• Network payback: Acquisition and activation cost divided by contribution produced by the participant cohort.

38.2 Registry lead unit example

Illustrative Project economics:

This example excludes any Provider or product contribution. The Registry must track the lead-source cohort through qualification, matching, signed agreement, first payment, completion and refund. A signed Project with no collected fee is not revenue.

38.3 Provider Work Order unit example

This example demonstrates why funds flow matters. If the Registry absorbs card cost on a low marketplace rate, apparent revenue can disappear. Large Work Orders may require bank payment, ACH-equivalent methods or direct Provider collection with separate Registry invoicing.

38.4 Product order unit example

The business should maintain separate contribution models for stocked goods, drop-ship goods, trade purchases, affiliate orders and direct Vendor transactions.

38.5 Cohort economics

One Designer cohort should be evaluated across twelve and twenty-four months:

• Onboarding cost
• Imported Projects
• Active months
• Registry-generated leads accepted
• Provider Work Orders created
• Product volume
• Managed services purchased
• Support hours
• Gross and net contribution
• Retention
• Referrals

The strategic unit is the active studio relationship, not a single subscription month. However, the absence of subscription revenue does not excuse poor cohort payback.

38.6 Contribution-margin thresholds

Suggested management gates:

• Do not scale a lead channel until a cohort shows positive expected contribution after qualification and support.
• Do not subsidize card fees on large transactions without explicit margin.
• Do not launch a managed service without time tracking and a target gross margin.
• Do not open a second physical location until the first has a credible path to covering its direct cost or can demonstrate measurable, board-approved acquisition value.
• Do not count pass-through Provider funds as Registry revenue.

39. Financial Planning Model

39.1 Purpose and limitations

The following model is an operating scenario, not a forecast or valuation. It translates the strategy into assumptions that can be tested. A linked monthly spreadsheet should replace these annual planning tables before fundraising, material hiring or lease commitments.

39.2 Base-case activity assumptions

39.3 Base-case revenue assumptions

Illustrative recognized revenue assumptions:

• Average Registry lead contribution revenue: $1,350 per Project
• Average Provider marketplace revenue: $300 per monetized Work Order
• Average product/procurement revenue: $2,000 per participating Project
• Average premium/managed-service revenue: $3,000 per annual customer
• Studio and Vendor program revenue begins after the pilot

39.4 Illustrative revenue scenario

These figures are intentionally mechanical. They should be recalculated from observed conversion, ticket size and fee data every quarter.

39.5 Cost architecture

Variable costs may include:

• Payment processing
• Messaging and email
• File storage and AI usage
• Provider verification
• Lead qualification
• Project support
• Claims and service recovery
• Managed-service labour
• Sales commissions or incentives

Fixed and semi-fixed costs may include:

• Product and engineering
• Network operations
• Customer success
• Legal, finance and insurance
• Studio rent and occupancy
• Sales and partnerships
• Brand and content
• Core infrastructure and security

39.6 Illustrative operating expense ranges

The resulting Year 1 funding need depends materially on founder compensation, engineering approach and studio commitment. Management should prepare a monthly cash plan with a minimum twelve-month downside runway before fixed-cost expansion.

39.7 Scenario analysis

The financial model should include at least three cases:

• Downside: Slower Designer activation, lower transaction adoption, no studio lease and delayed hiring.
• Base: Activity assumptions in this plan with measured market expansion.
• Upside: Strong Provider retention, higher Project density and product contribution without proportional support growth.

The most sensitive variables are expected to be Designer activation, Work Orders per active Project, net take rate after payment cost, support labour per transaction and time required to achieve local Provider density.

40. Go-to-Market Operating System

The first go-to-market system is an organic network loop, not a media plan. Cash spending should remain negligible until the company can prove that outreach creates activated Designers, activated Designers invite Providers and shared workflows create enough value for both parties to remain and refer others.

Personalized Designer outreach
        ↓
Workflow conversation
        ↓
One live Project imported free
        ↓
Designer experiences operational relief
        ↓
Designer invites an existing Provider
        ↓
Provider completes useful work in the portal
        ↓
Project becomes the shared operating record
        ↓
Designer and Provider referrals
        ↺

40.1 Positioning

Primary Designer message:

Keep your studio, clients and creative identity. The Design Registry organizes the operational network around your Projects so you can spend more time designing.

Primary Provider message:

Receive clearer opportunities, run category-specific work and get paid with less duplicated administration.

Primary client message:

A calm, guided design experience led by your Designer, with decisions, approvals and progress in one place.

40.2 Designer acquisition channels

The initial plan excludes scaled paid media. Channel priority:

1. Founder and advisor relationships
2. Personalized LinkedIn outreach
3. Personalized Instagram engagement and direct outreach
4. Designer-to-Designer referrals
5. Provider introductions to Designers
6. Design-school alumni and professional communities
7. Small virtual or local Project-working sessions
8. Educational content based on real operational problems
9. Website lead plugin distribution after activation

Broad paid social, sponsorships, large events and general awareness campaigns remain gated until the company has a repeatable activated-studio funnel and can measure retention from the resulting cohort.

40.3 Outreach cadence

A respectful founder-led sequence may include:

1. Follow or connect only when the Designer fits the target profile.
2. Personal message referencing the Designer's actual work, studio stage or visible operational context.
3. Short explanation of the Designer-first thesis: less administration, more time designing.
4. Invitation to a 20-minute workflow conversation, not a generic software demonstration.
5. Follow-up with one relevant artifact, such as a Project import, Item list or Provider handoff example.
6. Offer to migrate one live spreadsheet and set up one Project at no cost.
7. One concise final follow-up that leaves the relationship intact.
8. Close the sequence politely if there is no response; do not automate persistent unsolicited messaging.

Every outreach should be logged with source, persona, message, response and activation outcome so the team learns which value propositions work.

Instagram is used as a relationship and proof channel, not a mass-direct-message channel. Meaningful engagement should precede outreach where possible. LinkedIn remains the primary professional discovery and conversation surface.

40.4 Founding Designer cohort

The first cohort should be deliberately small—approximately five to ten Designers—so the company can observe workflows and deliver high-touch onboarding. Selection should create variation in business maturity, Project type and operational style without making the product support every edge case at once.

Founding cohort commitments may include:

• Import at least one active Project
• Attend onboarding and feedback sessions
• Invite at least one Provider
• Permit anonymized workflow learning
• Report weekly friction for the first eight weeks
• Avoid public endorsement requirements until the product earns them

Registry commitments may include:

• Free migration
• Direct product support
• Influence over roadmap priorities
• Stable core access
• Early visibility into Provider recruitment

The cohort is not considered activated at account creation. A founding Designer becomes activated when one real Project contains useful data and at least one recurring action. Network activation occurs when the Designer invites a Provider and the two businesses complete a meaningful shared workflow.

40.5 Provider density playbook

Supply should be recruited around actual Project demand, not as a large inactive directory. For each local category:

1. Estimate demand from active Projects.
2. Recruit two to five high-fit Providers where practical.
3. Verify service area, capacity, commercial fit and evidence.
4. Run one real workflow.
5. Review response time, clarity and operational participation.
6. Add supply only when response time, capacity or quality requires it.

The Registry should avoid winner-take-all dependence on one Provider while also avoiding a crowded pool that receives too few opportunities to remain engaged.

Designer-led Provider recruitment is the default. The invitation should originate from a real Project and explain the immediate job to be done: review an Offer, quote a Work Package, acknowledge a Purchase Order, receive Items, update a delivery or submit evidence. Generic “join our marketplace” invitations should not be the primary acquisition experience.

The Provider referral loop begins only after a Provider receives operational value. Appropriate prompts include inviting teammates, referring a complementary Provider Category or introducing a Designer who would benefit from the workflow. Referral requests must never interrupt unresolved work, payment or service recovery.

40.6 Client lead program launch

The Registry-generated lead program should launch after enough Designers are activated to serve opportunities well. Initial lead sources should emphasize partnerships, referrals, studio activity and high-intent organic capture before scaled paid advertising.

Lead-channel scorecard:

• Qualified lead rate
• Cost per qualified lead
• Match-ready rate
• Designer interest rate
• Consultation rate
• Signed Project rate
• Collected design-fee revenue
• Time to match
• Client satisfaction
• Refund or complaint rate

40.7 Conversion funnel targets for validation

Early targets are learning thresholds, not promises:

Failure to meet a threshold should trigger diagnosis of segment, message, onboarding or workflow—not simply more outreach.

40.8 Near-zero-cost operating rules

1. Do not pay to acquire signups that have not been shown to activate.
2. Do not count accounts, followers, impressions or Provider listings as growth outcomes.
3. Spend founder time where it produces workflow learning and reusable onboarding assets.
4. Use the product itself to manage the outreach Pipeline, referrals, onboarding and activation Tasks.
5. Create content by documenting solved operational problems; avoid a high-cost editorial machine.
6. Ask for referrals only after a measurable moment of value.
7. Attribute every invited Provider to the Designer, Project and invitation context that created the relationship.
8. Review organic funnel performance weekly and message quality monthly.
9. Introduce paid channel tests only after two consecutive cohorts meet activation and early retention thresholds.
10. Keep the free promise clear: core business operations are genuinely useful without forcing marketplace transactions.

40.9 Weekly growth cadence

The early growth system should be manageable by a founder and one operational collaborator:

• Monday: select and research the week's high-fit Designer list; review referral opportunities and last week's funnel.
• Tuesday–Wednesday: personalized LinkedIn outreach, thoughtful Instagram engagement and workflow conversations.
• Thursday: live Project imports, onboarding and Provider-invitation support.
• Friday: follow-ups, learning review, message changes, case-study capture and referral requests earned that week.

The team should review new conversations, qualified conversations, onboarding commitments, imported Projects, activated Designers, Provider invitations, accepted Provider Work Orders, referrals and four-week retention. Each metric must be traceable to the source person and cohort.

41. Network Quality, Trust and Marketplace Governance

41.1 Admission philosophy

The Registry should be selective enough to protect trust but not use exclusivity as empty branding. Admission criteria must be relevant to the actual service, consistently applied and explainable.

Common Provider review may include:

• Legal identity and contact verification
• Service area
• Insurance
• References
• Portfolio or representative work
• Category capabilities
• Commercial terms
• Availability and capacity
• Agreement to conduct and evidence standards

Designer review may include identity, business profile, portfolio, service category, market, client fit and agreement to professional conduct. Credential requirements must not falsely imply regulated status where none exists.

41.2 Performance framework

Performance signals should include objective operating measures and reviewed qualitative feedback:

• Response time
• Quote completeness
• Acceptance reliability
• Schedule reliability
• Evidence completion
• Change-order compliance
• Damage and claim frequency
• Invoice accuracy
• Client/Designer feedback
• Dispute outcomes

No single score should automatically determine access to work. The system should show context, sample size and recency.

41.3 Fair matching

Matching must avoid hidden pay-to-play ranking. Commercial relationships may affect eligibility only when explicitly relevant and governed. Ranking factors should be documented internally, and authorized operators should see explanations and potential conflicts.

41.4 Suspension and removal

Grounds may include fraud, expired mandatory insurance, repeated safety issues, serious misconduct, abuse, material misrepresentation, persistent non-performance or failure to resolve payment obligations.

Process should include:

1. Immediate protective action when safety, fraud or privacy requires it.
2. Written reason and evidence summary.
3. Opportunity to respond where appropriate.
4. Documented decision by authorized staff.
5. Appeal route for material decisions.
6. Preservation of existing Project records and lawful access.

41.5 Marketplace neutrality and conflicts

The Registry may earn revenue from transactions, but it must not present commercial preference as objective quality. Staff and system recommendations should disclose material conflicts to authorized decision-makers. Sponsored placement, if ever introduced, must be visibly separated from matching.

42. AI-Native Operating Plan

42.1 AI role

AI is an operating leverage layer, not the product identity. The customer should experience a calmer and more capable service, not a constant stream of novelty features. AI should be used where it reduces repetitive work, reveals exceptions, improves completeness or makes structured information easier to create.

42.2 AI use-case portfolio

42.3 AI ingestion architecture

Every extraction workflow should preserve the original source file or URL, extraction timestamp, proposed field value, confidence, source location where possible, user correction, final approved value and model/version metadata appropriate to the risk. This creates provenance and enables quality measurement. AI-generated commercial values must never silently overwrite approved data.

42.4 Registry operating manager

The internal AI operating manager should create an exception queue across the business. Examples include Provider applications missing evidence, leads waiting beyond service level, match shortlists lacking local capacity, unopened Offers, overdue Proposals, late Work Order milestones, expected shipments not received, damaged items, deliveries scheduled without readiness, overdue Invoices, insurance approaching expiry and failed integrations.

The operating manager recommends actions and drafts summaries. It does not approve Providers, award work, send legal notices, move money or suspend accounts without authorized human action.

42.5 AI quality program

For each production use case, maintain a defined input and output, acceptable error threshold, evaluation dataset, source-grounding requirement, human-review rule, escalation rule, cost and latency target, privacy classification and rollback mechanism.

Quality metrics should include field accuracy, user correction rate, false-positive exception rate, time saved, acceptance rate and harmful-error incidents.

42.6 Privacy and data use

Project and client information must not be used casually to train public or shared models. Vendor agreements, system configuration, retention and access should reflect the sensitivity of addresses, budgets, floor plans, invoices and personal communications. Users should understand when AI is processing their content and what control they retain.

43. Technology and Integration Operating Model

43.1 Core architecture principle

Build once and reuse everywhere. Shared modules—Tasks, Notes, Files, Communication, Activity, Forms, Data Grids, Offers, Proposals, Work Orders, Invoices and Notifications—should operate against different record types through configuration and access control rather than copied implementations.

43.2 Supabase foundation

The intended production foundation is Supabase for PostgreSQL data, authentication, storage and Realtime. The architecture should support multi-workspace tenancy, users with membership in more than one workspace, Project-scoped external access, row-level security, audit history, durable identifiers, environment separation, backups, restoration testing, storage policies and event-driven automation.

The shell and frontend should not become the de facto data model. Production migration requires an explicit schema, authorization model and reconciliation plan.

43.3 Integration responsibilities

43.4 Integration failure design

Every integration must have connection status, last successful synchronization, idempotency and duplicate protection, retry policy, error queue, user-visible impact, manual fallback, audit event and credential revocation handling.

An integration is not complete when the happy path works. It is complete when failure does not corrupt the Project or leave users unaware.

43.5 Notification builder

Every new workflow event that may require a user or workspace notification must register an editable template. Templates support channel, audience, trigger, timing, variables, conditions, sender identity, fallback and test preview. Critical operational notifications require protected meaning even if administrators can edit wording.

44. Organization and Operating Responsibilities

44.1 Early team design

The first team should be organized around learning and service reliability rather than departmental appearance.

44.2 Operating cadences

Daily: Critical exceptions, payments, damage, failed integrations, client-impacting delays and urgent applications.

Weekly: Designer activation, Provider capacity, lead pipeline, Work Order exceptions, product reliability and support themes.

Monthly: Cohort activity, contribution margin, category health, AI quality, complaints, cash and roadmap decisions.

Quarterly: Pricing, free/premium boundary, market expansion readiness, risk register, data governance and capital plan.

44.3 Market operator scorecard

Each market operator is accountable for activated Designers, healthy Provider coverage, lead response service level, match acceptance and quality, Work Order completion, participant retention, net contribution, complaint resolution and accurate operating data. The role is not compensated solely on transaction value; quality and retention must be included.

44.4 Decision rights

The company should maintain a lightweight authority matrix covering Provider and Designer approval, suspension, match shortlist approval, commercial exceptions, refunds, payment release, incident communication, production access, AI rollout, market expansion, leases and hiring.

45. Implementation and Phase Gates

45.1 Phase 0 — Foundation and rebrand

Objective: Establish The Design Registry identity and production foundations.

Current position: Released foundation, with ongoing terminology and shared-component cleanup.

Required outcomes: Legacy language removed; canonical Provider categories adopted; Supabase production architecture confirmed; authentication and workspace model stable; website reflects Designer and Provider value; core event and notification taxonomy established; common fields, profiles and responsive behaviour conform to the Product Style Guide.

Exit gate: A Designer and Provider can access the correct workspace without legacy-brand confusion or unsafe access.

45.2 Phase 1 — Designer activation

Objective: Make one real Designer Project easier to run.

Current position: Workspace dashboard, profile and Project-operation foundations are released; the integrated Project operating depth remains the next major build.

Required outcomes: Project creation; seven-Phase model; spreadsheet and Google Sheets import; Clients, spaces, construction and decorating Items, integrated Budgets, Tasks, Files, Calendar, resources and time; Designer and Client views; Project webpage and PDF publication; Registry readiness model; Workspace profiles; configurable notifications.

Exit gate: At least five founding Designers manage real active Projects for eight consecutive weeks with acceptable support burden.

45.3 Phase 2 — Provider network

Objective: Prove external businesses will participate in a shared workflow.

Current position: Provider applications, approval and provisioning are substantially represented; category-specific operating depth remains incomplete.

Required outcomes: Applications, approval, provisioning, Provider directory, category profiles and dashboards, Offers, Project-scoped access and operational evidence for storage, delivery and one other category.

Exit gate: At least ten Providers complete a real workflow, and at least 60% update status without manual Registry intervention after onboarding.

45.4 Phase 3 — Commercial loop

Objective: Connect Project scope to Proposal, Work Order, Invoice and payment state.

Required outcomes: Work-package snapshots, Proposals, acceptance, Work Orders, changes, Invoices, Stripe pilot and QuickBooks synchronization design.

Exit gate: At least twenty Work Orders complete with accurate commercial history and reconciliation.

Commercial documents must share the accepted scope snapshot, maintain exact version history and feed the Project budget without exposing private cost or margin information to unauthorized participants.

45.5 Phase 4 — Matchmaking and lead program

Objective: Generate and route qualified opportunities.

Required outcomes: Match profiles, explainable shortlist, conflict and availability handling, website lead integration, attribution, fee tracking and human governance.

Exit gate: A qualified-lead pilot produces consultations, signed Projects and collected revenue with acceptable satisfaction and acquisition economics.

45.6 Phase 5 — Provider operational depth

Objective: Make Provider portals indispensable during physical execution.

Required outcomes: Receiving and condition, storage locations and release, delivery manifest and day-of status, installation readiness, millwork revisions and Vendor order updates.

Exit gate: Providers rely on the platform as the current operating record, and Designers report less status-chasing.

Provider depth is released category by category against a common workflow contract. Each category must prove that the Provider receives enough direct operating value to maintain status and evidence without persistent manual chasing.

45.7 Phase 6 — Scale and second market

Objective: Replicate the operating network without founder dependence.

Required outcomes: Market playbook, operator dashboards, category-coverage model, cohort economics, security maturity, support system and portable studio model.

Exit gate: Ottawa meets the expansion scorecard for two quarters and a non-founder operator can run core weekly processes.

45.8 Phase 7 — Permanent Registry and aftercare

Objective: Complete the promise that the Project ends while the Registry remains.

Required outcomes: Registry readiness scoring; curated completion workflow; permanent home chapters; final specification and installed-item truth; contributor attribution; warranty and manual library; care reminders; controlled Client ownership and access; future Project linkage; long-term export and retention policy.

Exit gate: Completed Projects can become coherent, permissioned Registries that Clients and authorized professionals can still understand and use after the active delivery team has disengaged.

46. Measurement System

46.1 North-star measure

The proposed north-star measure is Monthly Coordinated Project Value: active Project value for which at least two participant types completed a meaningful platform workflow during the month. It should be paired with contribution margin so pass-through volume is not mistaken for health.

46.2 Activation and engagement

• Time to workspace completion, first Project, first imported list, first client invitation, first Provider invitation and first accepted Work Order
• Percentage activating within 7, 14 and 30 days
• Weekly active Designers by cohort
• Active Projects per Designer
• Participant types per Project
• External workflows completed
• Provider updates completed without reminders

46.3 Commercial and quality

• Gross Project value, monetized Project count and recognized revenue by stream
• Net contribution, effective take rate, payment cost, refunds and days to collect
• Lead and Offer response time
• Proposal turnaround and on-time milestone rate
• Damage, claims, change compliance and Invoice errors
• Client, Designer and Provider satisfaction
• Complaint-resolution time

46.4 Retention and data quality

• Designer logo and active-Project retention
• Provider activation retention
• Cohort contribution retention
• Project repeat and Provider reuse
• Duplicate entities, missing required fields and unmatched imports
• Integration and notification failures
• AI correction rate and stale statuses

47. Validation and Research Plan

47.1 Highest-risk assumptions

1. Designers will import a real Project into free software.
2. Designers will invite Providers into the shared record.
3. Providers will update status because the portal saves work.
4. Designers will accept Registry-generated opportunities under the proposed fee model.
5. Clients will use the portal for approvals and payments.
6. Marketplace fees can be charged without driving work off-platform.
7. Product contribution remains attractive after labour, returns and claims.
8. A studio location improves acquisition or retention enough to justify cost.
9. AI extraction reduces setup time at acceptable accuracy.
10. Ottawa operating density can be repeated in Toronto.

47.2 First 90-day research program

• Interview 20 Designers across solo, emerging and established segments.
• Observe at least 10 live spreadsheet or purchasing workflows.
• Interview 3–5 Providers in each priority category.
• Test Project import with five real spreadsheets.
• Prototype storage receiving and white-glove delivery with actual items.
• Conduct five client usability sessions.
• Test the lead-fee concept in commercial interviews before contracting.

47.3 Evidence standard

An assumption is supported only when observed behaviour or paid commitment confirms it. The evidence hierarchy is: paid completed transaction; fulfilled signed agreement; repeated live use; one-time live use; prototype completion; stated intent; general enthusiasm.

Every four weeks management should publish what was assumed, tested, observed, changed and what decision is required next.

48. Legal, Compliance and Trust Workplan

This section is a planning checklist, not legal advice.

48.1 Contract families

• Platform terms and privacy policy
• Designer and Provider workspace agreements
• Registry-generated lead agreement
• Marketplace or referral addendum
• Payment and settlement terms
• Client portal terms
• Studio-location agreement
• Vendor/API data agreement
• Managed-service statement of work

48.2 Payments and marketplace structure

Counsel and payment specialists must determine whether the Registry acts as marketplace platform, agent, reseller, merchant of record, service provider or some combination by transaction. The structure determines funds flow, tax, refunds, chargebacks, KYC, reporting and liability.

Large Project transactions may be unsuitable for card payment. The product should support card and bank-based flows where available, plus recorded manual payment when necessary, without implying that all funds must pass through the Registry before the architecture is ready.

48.3 Privacy and residential security

The platform may hold addresses, floor plans, schedules, access instructions, photos, family information and live delivery locations. Access must be limited by workspace, Project and purpose. Sensitive data requires explicit retention, download and sharing controls.

48.4 Insurance, claims, tax and accounting

The Registry should define required coverage by category, verification frequency and expiry consequences. Finance must distinguish Registry revenue, Provider pass-through funds, product sales, commissions, refunds, taxes, payouts, processing fees and reserves. QuickBooks synchronization follows the accounting model; it does not define it.

49. Risk Register with Early-Warning Indicators

50. Twelve-Month Operating Plan

Quarter 1 — Prove activation

Finalize rebrand and taxonomy; implement production workspace foundation; recruit five founding Designers; import five active Projects; recruit Providers around those Projects; instrument activation and support.

Decision: Do Designers repeatedly use imported Projects and invite external participants?

Quarter 2 — Prove external workflow

Launch Provider applications, category dashboards and Offers; pilot receiving, storage and delivery; establish notification templates and service levels; test the client portal; prepare commercial agreements.

Decision: Do Providers maintain the record when real work is underway?

Quarter 3 — Prove commercial loop

Launch Proposals, Work Orders, changes and Invoices; pilot Stripe and QuickBooks; launch controlled matchmaking; test the lead plugin; begin a limited lead pilot; measure contribution and leakage.

Decision: Can the Registry generate recognized revenue while improving participant experience?

Quarter 4 — Prove repeatability

Improve onboarding; expand only validated categories; document the Ottawa playbook; automate exception monitoring; review studio economics; assess Toronto readiness; build the Year 2 budget from cohort data.

Decision: Can a non-founder operator reproduce the core cadence with acceptable economics and quality?

Appendix A — Planning Assumptions Requiring Validation

• 20% Registry share of design fees on Registry-generated leads
• Initial Registry lead budgets of $10,000–$80,000
• 10%–15% potential product/procurement contribution depending on structure
• Provider category transaction economics
• Ottawa as first studio/market and Toronto as second
• Free core scope and future premium limits
• Studio lease/partnership model
• Stripe funds-flow architecture
• Designer and Provider agreement structure

Appendix B — Canonical Provider Categories

1. Vendors & Product Suppliers
2. Millwork & Custom Fabrication
3. Contractors & Specialty Trades
4. Photography
5. Measurement & Drafting
6. Receiving, Warehouse & Storage
7. White-Glove Delivery
8. Installation Services
9. General Service Providers

<!-- PAGE BREAK -->

Appendix C — Core Technology Direction

• Supabase: production database, authentication, storage and Realtime foundation
• Stripe: payments and marketplace settlement
• QuickBooks Online: accounting synchronization
• Resend: transactional email
• Twilio: SMS and calling
• Google Calendar: scheduling synchronization
• Google Sheets: migration, import/export and controlled reporting
• Approved Vendor APIs: product, price, availability and order status
• AI services: extraction, summarization, recommendations and operational monitoring with human governance