# PRODUCT STRATEGY **Working product name:** Freelance Client Command Centre **Target customer:** Solo brand and web designers managing approximately 3–12 active clients who currently coordinate briefs, approvals, deliverables, tasks, and follow-ups across multiple tools. The intended user has intermediate Notion skill and primarily works on desktop, with a simplified mobile task workflow. **Job to be done:** Give a solo designer one operational place to see each active client commitment, what is due, what is waiting on the client, and what action comes next. **Supported transformation:** Scattered project-delivery information across email, folders, and task apps → a structured Notion system connecting Clients, Projects, Tasks, and Deliverables. **Core promise:** Keep client-project commitments, deliverables, approvals, and next actions visible in one focused workspace without turning project delivery into a full business-management system. **Scope boundary:** Includes a client dashboard; Clients, Projects, Tasks, and Deliverables databases; project and client portal templates; onboarding guidance; demo data; decision-focused views; and a simplified mobile task view. It does not provide invoicing, accounting, contracts, legal compliance, time tracking, CRM prospecting, or external automations. Target paid price: $24–$39. Delivery is intended to become a buyer-tested Notion duplicate link only after the blueprint has been implemented and tested. **Human review:** Required before sale—formula syntax, buttons, permissions/sharing behavior, mobile behavior, and the final duplication experience must be verified in the current Notion version. No live workspace, tested duplicate link, marketplace publication, or completed implementation is claimed here. # DESIGN ASSUMPTIONS TO VALIDATE * **Project phases:** Design Assumption — projects use manually entered phase names because no universal phase framework was supplied. Validate: should the commercial product ship with a suggested design-project phase set, or leave phases entirely creator-defined? * **Task generation:** Design Assumption — “generate phases/tasks” is implemented through database templates containing starter task instructions rather than claiming automatic task creation. Validate whether current Notion buttons/templates can reliably create related task sets; **VERIFY IN NOTION**. * **Task ownership:** Design Assumption — because the customer is a solo designer, Owner is retained as supplied but is optional and may default to the workspace user where supported. **VERIFY IN NOTION**. * **Client portal:** Design Assumption — the portal is a structured internal/shareable project page containing appropriate linked project and deliverable views; it is not assumed to provide secure client authentication. Sharing and permissions are **VERIFY IN NOTION**. * **Late approval:** Design Assumption — a deliverable is considered “late approval” when its due date has passed while status remains Client Review or Revisions. Validate whether users interpret Due Date as the expected approval/delivery milestone. * **Recurring tasks:** None supplied. * **Formal performance metrics:** None supplied beyond operational counts/dates derivable from records. * **Accessibility needs:** None specifically supplied. The design therefore uses readable labels, text statuses rather than color alone, restrained decoration, and simplified mobile surfaces. # USER JOURNEY | Stage | User goal | Action | System response | Success signal | Friction prevention | | ------------- | ---------------------------------------------- | ---------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------- | | Setup | Understand the system | Read Quick Start and review DEMO records | Explains four databases and core workflow | User can identify where clients, projects, tasks, and deliverables belong | Progressive disclosure; no unnecessary setup | | Client entry | Establish client record | Add Client | Creates one source of truth for client identity and related work | Client is available for project relation | Minimal required properties | | Project start | Turn an approved brief into active work | Create Project and relate Client | Project becomes visible on dashboard | Active project has client, status, and next-action context | Project template supplies prompts | | Planning | Establish work to do | Add phases/tasks | Tasks relate to Project | Actionable work appears in decision views | Avoid duplicate project/client fields | | Production | Track output | Add Deliverables and versions | Deliverables move through workflow statuses | Current deliverable state is visible | Explicit version property | | Review | See external dependency | Set Client Review/Revisions | Item appears in Waiting on Client where appropriate | Designer can identify stalled client-dependent work | Decision view separates waiting work | | Approval | Record completion evidence | Enter Approval Date | Approval is visible on record | Approved item has approval date | QA flags inconsistent records | | Delivery | Finish handoff | Add delivery Link and set Delivered | Item appears Ready to Deliver before delivery, then leaves active queue | Delivered item has link | Formula/view checks missing links | | Close | Remove completed project from active workspace | Set project Closed/Archived | Project leaves active views but remains stored | Dashboard contains current work only | Manual deletion preserves archive | | Mobile check | See immediate tasks | Open simplified mobile task view | Shows concise actionable task list | Next task can be identified quickly | Reduced properties and views | # WORKSPACE ARCHITECTURE Freelance Client Command Centre ├── **Command Centre — Dashboard** — Main operational dashboard using linked database views. │ ├── Overdue — Linked Tasks view. │ ├── Waiting on Client — Linked Deliverables view. │ ├── Due This Week — Linked Tasks view. │ ├── Ready to Deliver — Linked Deliverables view. │ ├── Active Projects — Linked Projects view. │ └── Mobile Tasks — Simplified linked Tasks view. ├── **Clients** — FULL-PAGE DATABASE; source of truth for client records. │ └── Client Portal — DATABASE TEMPLATE; structured client/project overview page. ├── **Projects** — FULL-PAGE DATABASE; source of truth for client projects. │ └── Project Workspace — DATABASE TEMPLATE; project execution page. ├── **Tasks** — FULL-PAGE DATABASE; source of truth for actionable work. ├── **Deliverables** — FULL-PAGE DATABASE; source of truth for outputs, versions, approvals, and delivery links. ├── **Archive** — DASHBOARD/LINKED VIEW; closed Projects retained until manual deletion. ├── **Start Here** — GUIDE; customer onboarding and workflow explanation. │ ├── 10-Minute Quick Start │ ├── Workflow Reference │ └── Property/Status Reference └── **DEMO Area** — GUIDE/CALLOUT; explains that included fictional records are examples and may be deleted after onboarding. The architecture deliberately uses only four core databases because every database must serve the specified workflow rather than acting as an ornamental collection. # DATABASE SPECIFICATIONS ## CLIENTS **Purpose:** Maintain the client record that projects relate to. **Source of truth for:** Client identity and client-level project relationships. | Property | Type | Required? | Allowed values or format | Purpose | Example | | --------------- | ------------------- | --------: | ---------------------------- | --------------------------- | ------------------------ | | Client | Title | Yes | Plain text | Client identifier | DEMO — Northstar Studio | | Status | Select | Yes | Active; Paused; Archived | Client-level visibility | Active | | Projects | Relation → Projects | No | Related records | Connect client work | DEMO — Northstar Website | | Active Projects | Rollup | No | Related project status/count | Surface current work | 1 | | Notes | Text | No | Minimal operational notes | Store non-sensitive context | Primary website project | | Portal Ready? | Formula candidate | No | Boolean/text | QA indicator | Ready | **Relations and rollups:** * Clients → Projects → related project records → establishes one client-to-many-project relationship. * Projects relation → Status rollup/count → provides client-level visibility of related work. Exact filtered-rollup behavior **VERIFY IN NOTION**. **Candidate formulas:** 1. **Portal Ready?** * Candidate formula: `if(empty(prop("Client")), "Needs client name", "Ready")` * Inputs: Client * Expected output: Readiness label. * Blank/error behaviour: Blank title produces “Needs client name.” * Verification: Named client → Ready; blank test record → Needs client name. **VERIFY IN NOTION**. ## PROJECTS **Purpose:** Track each approved client project from active work through archive. **Source of truth for:** Project-level status, client relationship, phase context, and closure state. | Property | Type | Required? | Allowed values or format | Purpose | Example | | --------------- | ----------------------- | --------: | ---------------------------------------------- | ----------------------------- | ------------------------ | | Project | Title | Yes | Plain text | Project identifier | DEMO — Northstar Website | | Client | Relation → Clients | Yes | One client preferred | Connect project to client | DEMO — Northstar Studio | | Status | Select | Yes | Active; Paused; Closed | Lifecycle control | Active | | Phase | Select/Text | No | Creator-defined | Current project phase | Design | | Tasks | Relation → Tasks | No | Related records | Connect actions | Homepage wireframe | | Deliverables | Relation → Deliverables | No | Related records | Connect outputs | Homepage concept v2 | | Next Due | Rollup | No | Earliest related task due date where supported | Surface timing | Sep 11, 2026 | | Open Task Count | Rollup | No | Count related tasks | Operational visibility | 3 | | Brief Reference | URL/Text | No | Link or reference | Point to approved brief | None supplied | | Archive Date | Date | No | Date | Record closure/archive timing | None | | Project Health | Formula candidate | No | Text label | Surface paused/closed state | Active | **Relations and rollups:** * Projects → Clients → Client → establishes project ownership. * Projects → Tasks → Due Date → surfaces task timing. * Projects → Deliverables → Status → exposes project output state. * Filtered counts/earliest-date rollups: **VERIFY IN NOTION**. **Candidate formulas:** 1. **Project Health** * Candidate formula: `ifs(prop("Status") == "Paused", "Paused", prop("Status") == "Closed", "Closed", "Active")` * Inputs: Status * Expected output: Plain-language project state. * Blank/error behaviour: If Status is blank, candidate may return default/blank depending on final syntax. * Verification: Test Active, Paused, Closed, and blank. **VERIFY IN NOTION**. ## TASKS **Purpose:** Store individual actions required to move projects forward. **Source of truth for:** Task status, due date, priority, owner, and project association. | Property | Type | Required? | Allowed values or format | Purpose | Example | | --------- | ------------------- | --------: | --------------------------------------- | ---------------- | -------------------------------- | | Task | Title | Yes | Plain text | Action | DEMO — Refine homepage wireframe | | Project | Relation → Projects | Yes | Related project | Context | DEMO — Northstar Website | | Owner | Person | No | Workspace person | Responsibility | Creator | | Status | Select | Yes | Not Started; In Progress; Waiting; Done | Task state | In Progress | | Due Date | Date | No | Date | Timing | Sep 11, 2026 | | Priority | Select | Yes | High; Medium; Low | Triage | High | | Due State | Formula candidate | No | Text | Decision support | Due this week | **Relations and rollups:** * Tasks → Projects → Project → ties each action to its project. * Project → Client may be surfaced through a rollup if useful and supported; **VERIFY IN NOTION**. **Candidate formulas:** 1. **Due State** * Candidate formula/pseudocode: `IF Status = Done → "Done"` `ELSE IF Due Date blank → "No due date"` `ELSE IF Due Date < today → "Overdue"` `ELSE IF Due Date falls within current week → "Due this week"` `ELSE → "Upcoming"` * Inputs: Status, Due Date * Expected output: One triage label. * Blank/error behaviour: Missing date returns “No due date” rather than an error. * Verification: Test yesterday/not done; today; later this week; next week; no date; Done with past date. Date/week functions are **VERIFY IN NOTION**. ## DELIVERABLES **Purpose:** Track client-facing outputs from draft through delivery, including versions, approvals, and delivery links. **Source of truth for:** Deliverable type, version, workflow status, dates, and final link. | Property | Type | Required? | Allowed values or format | Purpose | Example | | -------------- | ------------------- | --------: | ---------------------------------------------------- | --------------------------------------- | ------------------------ | | Deliverable | Title | Yes | Plain text | Output identifier | DEMO — Homepage concept | | Project | Relation → Projects | Yes | Related project | Context | DEMO — Northstar Website | | Type | Select/Text | Yes | User-defined deliverable type | Categorization | Web design | | Version | Text/Number | Yes | v1, v2, v3… | Preserve multiple versions | v2 | | Status | Select | Yes | Draft; Client Review; Revisions; Approved; Delivered | Workflow | Client Review | | Due Date | Date | No | Date | Expected milestone | Sep 8, 2026 | | Approval Date | Date | No | Date | Record approval | Blank | | Link | URL | No | Valid URL | Delivery/reference link | Blank | | Waiting State | Formula candidate | No | Text | Identify client dependency | Waiting on client | | Delivery State | Formula candidate | No | Text | Identify approved items needing handoff | Not ready | **Relations and rollups:** * Deliverables → Projects → Project → associates each output/version with project. * Project → Client may be exposed via rollup for filtering where supported. **VERIFY IN NOTION**. **Candidate formulas:** 1. **Waiting State** * Candidate formula: `if(or(prop("Status") == "Client Review", prop("Status") == "Revisions"), "Waiting on client", "")` * Inputs: Status * Expected output: Waiting label for client-dependent states. * Blank/error behaviour: Other/blank statuses return blank. * Verification: Draft → blank; Client Review → Waiting on client; Revisions → Waiting on client; Approved → blank. **VERIFY IN NOTION**. 2. **Delivery State** * Candidate formula: `if(and(prop("Status") == "Approved", not empty(prop("Approval Date")), not empty(prop("Link"))), "Ready to deliver", "")` * Inputs: Status, Approval Date, Link * Expected output: Ready label only when approval evidence and link are present. * Blank/error behaviour: Missing date/link returns blank. * Verification: Approved + date + link → Ready; Approved + missing link → blank; Delivered → blank. **VERIFY IN NOTION**. 3. **Late Approval Flag** * Candidate pseudocode: `IF Due Date exists AND Due Date < today AND Status is Client Review or Revisions → "Approval past due date" ELSE blank` * Inputs: Due Date, Status * Expected output: Flags supplied late-client-approval edge case without attributing fault. * Blank/error behaviour: No due date returns blank. * Verification: Past due/Client Review; future/Client Review; past due/Approved; blank due date. **VERIFY IN NOTION**. # VIEWS AND DECISION SURFACES | View | Source database | Layout | Filter | Sort/group | User question answered | | ----------------- | --------------- | ----------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------- | | Overdue | Tasks | Table/List | Due State = Overdue; Status ≠ Done | Due Date ascending; Priority descending | What already needs attention? | | Waiting on Client | Deliverables | Table | Status = Client Review OR Revisions | Due Date ascending; group by Project if useful | Which outputs currently depend on client review/revision input? | | Due This Week | Tasks | List/Table | Due State = Due this week; Status ≠ Done | Due Date ascending, Priority descending | What needs action this week? | | Ready to Deliver | Deliverables | Table | Delivery State = Ready to deliver | Approval Date ascending | What is approved and prepared for handoff? | | Active Projects | Projects | Board/Table | Status = Active | Group by Phase or sort Next Due ascending | Which projects are currently moving? | | Mobile Tasks | Tasks | List | Status ≠ Done; optionally exclude paused-project tasks where relation filtering supports it | Due Date ascending, Priority descending | What should I act on from my phone? | The four specifically requested decision views—Overdue, Waiting on Client, Due This Week, and Ready to Deliver—are preserved, with Active Projects and Mobile Tasks completing the requested six decision surfaces. # PAGE AND RECORD TEMPLATES ## PROJECT WORKSPACE **Trigger/use:** Create when an approved brief becomes an active project. **Prefilled properties:** Status = Active. Client must be selected manually. Phase left unset unless a validated phase system is adopted. **Page-body sections:** 1. Project Snapshot 2. Approved Brief / Brief Reference 3. Current Phase 4. Next Decisions 5. Linked Tasks — filtered to this Project 6. Linked Deliverables — filtered to this Project 7. Client Review Notes 8. Completion / Archive Checklist **Prompts/instructions:** * Link the correct Client. * Add or reference the approved brief. * Add project tasks. * Add each deliverable/version as a separate Deliverables record where version history matters. * Update project phase/status as work changes. * Do not store contracts, payment details, or unnecessary sensitive client information. **Completion checklist:** * [ ] Client relation set * [ ] Approved brief referenced * [ ] Initial tasks entered * [ ] Deliverables entered * [ ] Approval dates captured where applicable * [ ] Delivery links captured * [ ] Open tasks resolved * [ ] Project status set Closed * [ ] Archive Date recorded ## CLIENT PORTAL **Trigger/use:** Create from a Client record when a structured client-facing/project overview is useful. **Prefilled properties:** Client title from parent record; Status as appropriate. **Page-body sections:** 1. Welcome / Project Context 2. Active Projects linked view 3. Deliverables linked view 4. Items in Client Review 5. Approved/Delivered Items 6. Notes / Next Step 7. Sharing notice **Prompts/instructions:** * Show only information appropriate for the intended client. * Review linked-view filters before sharing. * Remove internal-only notes. * Confirm current Notion sharing/permission behavior before use. * Do not treat the page as a secure legal, contractual, billing, or identity-management portal. **Completion checklist:** * [ ] Correct client filter * [ ] Internal information removed * [ ] Deliverables accurate * [ ] Links tested * [ ] Sharing permissions reviewed * [ ] Client access tested with a non-owner account **VERIFY IN NOTION** # DASHBOARD BLUEPRINT 1. **Header:** “Freelance Client Command Centre” plus restrained one-line instruction: “See what needs attention, what is waiting, and what can be delivered.” 2. **Quick Navigation:** Clients | Projects | Tasks | Deliverables | Start Here | Archive. 3. **Quick Actions:** New Client; New Project; New Task; New Deliverable. Buttons, if used instead of database New controls, are **VERIFY IN NOTION**. 4. **Attention Row:** Overdue followed by Due This Week. 5. **Client Dependency Row:** Waiting on Client. 6. **Delivery Row:** Ready to Deliver. 7. **Project Overview:** Active Projects. 8. **Mobile Section:** Mobile Tasks with only Task, Due Date, Priority, Status, and Project visible. 9. **Archive Link:** Closed projects remain available but outside everyday operational views. 10. **Help Footer:** Workflow Reference + Quick Start. **Empty states:** * Overdue: “Nothing overdue.” * Waiting on Client: “Nothing currently marked Client Review or Revisions.” * Due This Week: “No dated open tasks due this week.” * Ready to Deliver: “No approved deliverables currently meet the ready-to-deliver criteria.” * Active Projects: “Create a project after you have an approved brief.” * Mobile Tasks: “No open tasks match this view.” **Visual direction:** Charcoal, warm white, and muted teal; calm, capable, minimal; limited decorative elements; consistent icons only where they aid scanning. The supplied brand direction and seven years of creator freelance-design experience may be used, but no testimonials, sales results, time-saving claims, or revenue claims should be introduced. **Mobile simplification:** Prioritize the Mobile Tasks list and navigation. Hide low-value properties from mobile views rather than reproducing the desktop dashboard. # SAMPLE DATA All records below are fictional and labelled **DEMO**. | Record | Database | Related record | Key data | Test purpose | | -------------------------------- | ------------ | ----------------- | --------------------------------------------------- | -------------------------------------- | | DEMO — Northstar Studio | Clients | Northstar Website | Active | Standard client relation | | DEMO — Northstar Website | Projects | Northstar Studio | Active; Phase: Design | Active-project and relation test | | DEMO — Refine homepage wireframe | Tasks | Northstar Website | In Progress; High; Due Sep 11, 2026 | Due This Week test | | DEMO — Homepage concept v2 | Deliverables | Northstar Website | Client Review; Due Sep 8, 2026; approval/link blank | Waiting on Client + late-approval test | Additional edge states should be created temporarily during QA rather than shipped as permanent demo records: a task with no due date, a paused project, an Approved deliverable with approval date/link, and a Delivered deliverable. This preserves the requested four DEMO records while still testing supplied edge cases. # BUILD GUIDE 1. Create a new parent page named **Freelance Client Command Centre**. 2. Create four full-page databases: Clients, Projects, Tasks, Deliverables. 3. Build Clients properties exactly as specified. 4. Build Projects properties without adding relations initially. 5. Build Tasks and Deliverables properties. 6. Create Clients ↔ Projects relation. 7. Create Projects ↔ Tasks relation. 8. Create Projects ↔ Deliverables relation. 9. Add required rollups only after relations work. 10. Enter the four DEMO records and confirm relations connect correctly. 11. Add candidate formulas one at a time. 12. Test every formula against positive, negative, and blank cases before relying on it. Formula syntax is **VERIFY IN NOTION**. 13. Build Overdue. 14. Build Waiting on Client. 15. Build Due This Week. 16. Build Ready to Deliver. 17. Build Active Projects. 18. Build Mobile Tasks. 19. Test the no-due-date edge case. 20. Test a paused project and confirm it does not create misleading active-work surfaces; relation-based filters are **VERIFY IN NOTION**. 21. Test multiple deliverable versions as separate related records. 22. Test late client approval using the supplied late-approval scenario. 23. Build the Project Workspace database template. 24. Build the Client Portal database template. 25. If implementing buttons to generate tasks or create related records, test current button behavior and relation prefill behavior; **VERIFY IN NOTION**. 26. Assemble the Command Centre dashboard in the specified section order. 27. Create Start Here, Workflow Reference, and 10-Minute Quick Start. 28. Create the Archive linked view filtered to Closed projects. 29. Confirm archived projects remain until manually deleted, as required. 30. Apply minimal charcoal/warm-white/muted-teal visual styling without relying on color as the only status indicator. 31. Review every client-facing page for unnecessary personal/internal data. 32. Test portal permissions/sharing with a non-owner account; **VERIFY IN NOTION**. 33. Test desktop use. 34. Test Mobile Tasks on current Notion mobile; **VERIFY IN NOTION**. 35. Duplicate the finished workspace into a clean test environment. 36. Confirm database relations, templates, filters, formulas, links, and views survive duplication; **VERIFY IN NOTION**. 37. Delete accidental test records and internal creator notes. 38. Retain clearly labelled DEMO records for customer onboarding. 39. Perform one buyer-style run from Client creation through Project closure. 40. Only after successful implementation and testing, create the intended buyer duplicate link. This specification does not claim that such a link currently exists. # CUSTOMER QUICK START 1. Open **Start Here** and spend approximately one minute reviewing the four-database workflow. 2. Open the DEMO records to see how Client → Project → Task/Deliverable relationships work. 3. Create your first Client. 4. Create one Project and connect it to that Client. 5. Add your next three real Tasks, including due dates where dates genuinely exist. 6. Add one Deliverable and set its current version/status. 7. Return to the dashboard. 8. Check **Due This Week**, **Waiting on Client**, and **Ready to Deliver**. 9. Use **Mobile Tasks** when you only need a concise action list. 10. Once comfortable, delete the DEMO records if desired. **Advanced-use path:** Add additional projects per client; track separate deliverable versions; use project phases; pause projects when necessary; record approval dates and delivery links; review late-approval flags; close projects and retain them in Archive until you deliberately delete them. # QA AND DUPLICATION TEST * Confirm exactly four core databases exist and each has a named workflow purpose. * Confirm every required property exists with the intended type. * Confirm Clients ↔ Projects relation works both ways as intended. * Confirm Projects ↔ Tasks and Projects ↔ Deliverables relations work. * Confirm rollups return expected values; **VERIFY IN NOTION**. * Test formula candidates with normal, blank, and boundary cases. * Test dates around today, week boundaries, and overdue states; **VERIFY IN NOTION**. * Confirm a Done task does not remain in Overdue. * Confirm a task without Due Date produces a safe blank/no-date state. * Confirm Client Review and Revisions appear in Waiting on Client. * Confirm Approved + Approval Date + Link produces Ready to Deliver if the final formula is adopted. * Confirm Delivered items leave Ready to Deliver. * Confirm multiple deliverable versions remain distinct. * Confirm paused projects are not misleadingly presented as active. * Confirm Closed projects leave Active Projects and remain in Archive. * Confirm archive records persist until manually deleted. * Confirm both database templates create correctly related working pages. * Confirm template linked views are filtered to the current record; **VERIFY IN NOTION**. * Confirm dashboard views answer their stated decision question. * Confirm all DEMO records are fictional and labelled DEMO. * Confirm no sensitive information is embedded in demo data. * Confirm all links used in final product are functional. * Confirm client-facing pages contain no internal-only notes before sharing. * Test sharing/permissions using a non-owner account; **VERIFY IN NOTION**. * Test duplication into a clean workspace and verify relations, formulas, views, templates, filters, and page links. * Test current desktop behavior. * Test current mobile behavior and ensure Mobile Tasks remains usable; **VERIFY IN NOTION**. * Check text contrast and ensure statuses are understandable without color. * Check empty states for all six decision views. * Check long project/client names for layout resilience. * Confirm no copy promises automation, revenue improvement, productivity gains, time savings, or unsupported compatibility. * Obtain buyer testing before representing the duplicate link as buyer-tested. # PRODUCT LISTING KIT **Title:** Freelance Client Command Centre — Notion Project Delivery System for Solo Designers **One-line promise:** Bring active client projects, tasks, deliverables, approvals, and next actions into one focused Notion system. **Short description:** Freelance Client Command Centre is a practical Notion template blueprint for solo brand and web designers managing multiple active clients. It connects Clients, Projects, Tasks, and Deliverables so you can see upcoming work, client-review items, approvals, and delivery status without adding invoicing, prospecting, accounting, or other business-management layers you may not need. **Long description:** Client delivery gets harder to scan when briefs live in one place, tasks in another, files somewhere else, and approval follow-ups inside email. Freelance Client Command Centre is designed around the delivery workflow of solo brand and web designers managing roughly 3–12 active clients. The system connects four focused databases—Clients, Projects, Tasks, and Deliverables—with a central dashboard built around practical decisions: What is overdue? What is due this week? What is waiting on the client? What is approved and ready to deliver? Deliverables can move through Draft, Client Review, Revisions, Approved, and Delivered, while version, due date, approval date, and delivery link remain attached to the relevant record. Closed projects can move out of the active workspace without being automatically deleted. The template is desktop-first and includes a simplified mobile task view. It intentionally does not attempt to become an invoicing platform, prospecting CRM, contract manager, time tracker, accounting system, or automation hub. Created from seven years of freelance design experience. No time-saving, revenue, or productivity outcome is promised. **What's included:** * Command Centre dashboard * Clients database * Projects database * Tasks database * Deliverables database * Six decision-focused views * Project Workspace template * Client Portal template * Start Here onboarding guide * 10-minute quick start * Fictional DEMO records * Archive workflow * Simplified mobile task view **Best for:** * Solo brand designers * Solo web designers * Freelancers managing several simultaneous client projects * Intermediate Notion users who want a focused delivery system * Designers who prefer to keep accounting and prospecting outside their project workspace **Not designed for:** * Invoicing or accounting * Contracts or legal compliance * Time tracking * Lead-generation or prospecting CRM * External automations * Sensitive client-data management **Feature-to-benefit bullets:** * Four related databases → keep each core data object in one source of truth. * Overdue view → isolate dated open tasks that have passed their due date. * Due This Week → focus the immediate workload. * Waiting on Client → separate client-review/revision items from internal tasks. * Ready to Deliver → surface approved items that meet defined delivery-readiness criteria. * Version field → distinguish multiple iterations of the same deliverable. * Approval Date + Link → keep approval and handoff references with the deliverable. * Project archive → remove closed work from active views without automatic deletion. * Mobile Tasks → provide a reduced action surface away from desktop. **FAQ:** **1. Is this a full freelance-business operating system?** No. It is intentionally focused on client project delivery. Invoicing, accounting, prospecting, contracts, time tracking, and external automations are outside its scope. **2. Who is it designed for?** Solo brand and web designers, particularly those handling approximately 3–12 active clients and already comfortable with basic Notion use. **3. Can I track revisions and approvals?** Yes. The specified Deliverables workflow includes Draft, Client Review, Revisions, Approved, and Delivered, plus version and approval-date properties. **4. Does it work on mobile?** The specification includes a simplified mobile task view. Final behavior should be verified against the current Notion mobile experience before publication. **5. Does it automatically create my entire project plan?** No automatic behavior should be promised without implementation and verification. Project templates can provide structure, and any task-generation buttons or similar features must be tested in the current Notion version. **Disclaimer:** This product is a Notion-based project-delivery template and is not accounting, legal, contract-management, compliance, or time-tracking software. Notion functionality, formulas, buttons, sharing, permissions, plan availability, and device behavior may change. Verify version-sensitive features against the current Notion product before publication or sale. # LAUNCH ASSETS **Product thumbnail brief:** Minimal desktop-dashboard composition using charcoal, warm white, and muted teal. Show a clean representation of the Command Centre with three or four decision surfaces rather than a collage of decorative pages. Large text limit: “CLIENT COMMAND CENTRE.” Secondary text, if legible: “For Solo Designers.” Avoid numerical performance claims, ratings, “#1,” “ultimate,” or income/productivity promises. **Launch email:** **Subject:** A calmer way to see your active client work When you work solo, the difficult part is not always knowing how to do the design work. It is keeping track of what you promised, what needs attention next, which deliverable is with the client, and what has actually been approved and delivered. That is the problem behind Freelance Client Command Centre. It is a focused Notion system for solo brand and web designers, built around four connected areas: Clients, Projects, Tasks, and Deliverables. The dashboard is designed to answer practical questions such as: What is overdue? What is due this week? What is waiting on the client? What is ready to deliver? Deliverables move from Draft → Client Review → Revisions → Approved → Delivered, with version, due date, approval date, and delivery link kept with the record. I have spent seven years working in freelance design, and I wanted the structure to stay focused on project delivery rather than expanding into accounting, prospecting, contracts, and every other part of running a business. Freelance Client Command Centre is designed to keep that boundary. [View Freelance Client Command Centre] **Social post 1:** A freelance project dashboard does not need to contain your entire business. If the job is client delivery, the useful questions are often much simpler: What needs attention? What is due this week? What is waiting on the client? What has been approved? What is ready to deliver? That is the thinking behind Freelance Client Command Centre: four connected databases—Clients, Projects, Tasks, and Deliverables—organized around the decisions a solo designer needs to make during active projects. No accounting layer. No prospecting CRM. No time tracking. Just the delivery workflow. **Social post 2:** A client deliverable rarely goes directly from “working on it” to “done.” A more useful workflow is: Draft → Client Review → Revisions → Approved → Delivered. Freelance Client Command Centre gives each deliverable its own project, type, version, status, due date, approval date, and link. That means version 1 and version 2 do not have to become an ambiguous note buried inside a project page—and client-review work can have its own decision view. Built for solo brand and web designers managing several active client projects. **Social post 3:** Introducing Freelance Client Command Centre. A focused Notion project-delivery system for solo brand and web designers. Inside: Clients Projects Tasks Deliverables Overdue work Due This Week Waiting on Client Ready to Deliver Project and client-page templates Archive workflow Simplified mobile tasks It is intentionally not an invoicing system, prospecting CRM, contract manager, or time tracker. The goal is narrower: give active client commitments and next actions one clear operational home. **Demo script:** **0–6 sec — Dashboard** Voiceover: “This is Freelance Client Command Centre, a focused Notion system for solo brand and web designers.” **6–13 sec — Four databases** Show Clients, Projects, Tasks, Deliverables. Voiceover: “Four connected databases keep the core parts of client delivery organized without adding accounting or prospecting.” **13–22 sec — Project record** Open a DEMO project. Voiceover: “Start with a client, create the project from an approved brief, then connect the tasks and deliverables that belong to it.” **22–33 sec — Deliverables** Show statuses and versions. Voiceover: “Deliverables move through Draft, Client Review, Revisions, Approved, and Delivered, with version and approval information kept on the record.” **33–45 sec — Dashboard decision views** Show Overdue, Due This Week, Waiting on Client. Voiceover: “Back on the dashboard, decision views show what is overdue, what is due this week, and which deliverables are waiting on the client.” **45–53 sec — Ready to Deliver** Voiceover: “Approved items can surface in Ready to Deliver when the required approval and delivery information is present.” **53–60 sec — Mobile Tasks / dashboard close** Voiceover: “And when you only need your next actions, the simplified mobile task view keeps the working surface small.” # VALIDATION AND VERSION PLAN | Hypothesis | Lean test | Evidence to collect | Decision rule | | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Solo designers understand the four-database model | Give prototype to 3–5 representative users without live instruction | Where they hesitate; setup questions; misfiled records | Revise architecture/onboarding if the same confusion appears repeatedly | | Six decision views match real project-management questions | Ask testers to locate overdue, due-this-week, waiting, ready-to-deliver, active-project, and mobile-task information | Completion success and misunderstood labels | Rename/restructure any view that users repeatedly misinterpret | | Four databases are sufficient | Run several fictional projects end to end | Information users repeatedly have nowhere appropriate to store | Add a database only if a distinct recurring data object cannot be handled cleanly through existing records/properties | | Client portal is useful without exposing internal information | Share test portal with non-owner account | Visible fields/pages, permission problems, confusing content | Do not ship portal workflow until access behavior is predictable | | Candidate formulas survive realistic blanks/edge cases | Run formula test matrix | Expected vs actual outputs | Ship only formulas that pass all specified cases | | Mobile Tasks is sufficiently usable | Test on current Notion mobile | Scanability, taps required, hidden/visible properties | Reduce visible fields if mobile view feels overloaded | | $24–$39 is an acceptable price range | Present finished product at one or more points in supplied range | Buyer interest, objections, actual purchases if launched | Adjust within the supplied range based on evidence rather than assumed willingness to pay | | The focused positioning is differentiated enough | Show listing concept to target users | Which problem they believe product solves and whether exclusions are understood | Rewrite positioning if users interpret it as a full freelance-business OS | **Version 1 exclusions:** Invoicing, accounting, contracts, legal/compliance management, time tracking, CRM prospecting, lead generation, external automations, unsupported automatic task generation, complex reporting, revenue dashboards, and additional databases without demonstrated workflow need. **Evidence needed before stronger claims:** * Buyer-test results * Verified duplicate-link behavior * Actual customer feedback * Actual sales data * Any measured usability or performance outcomes * Permission/sharing test results * Current desktop/mobile compatibility testing * Evidence before making any time-saving, productivity, revenue, conversion, popularity, or superiority claim **Items to verify in Notion:** Candidate formula syntax; date/week calculations; filtered rollups; relation-prefilled database templates; database buttons and task-generation behavior; client portal sharing; page/database permissions; duplicate behavior; linked-view filters after duplication; mobile layout; plan-dependent functionality; current device behavior; and any feature whose behavior varies by current Notion version. All version-sensitive formulas, buttons, and permissions must be treated as **VERIFY IN NOTION** before the product is represented as implemented or buyer-tested.