simone
5bf5dfce71
- Rename src/app/c/[token] → src/app/client/[token] - Update proxy.ts, ClientRow, admin client detail with /client/ path - Add output: "standalone" to next.config.ts for Docker build - Add Dockerfile (multi-stage, node:20-alpine) and .dockerignore - Push schema to Coolify Postgres via SSH tunnel (drizzle-kit push ✓) - Update CLAUDE.md constraint 4 to reflect /client/ route - Add Phase 4 planning artifacts (04-00, 04-RESEARCH, 04-PATTERNS) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
108 lines
6.1 KiB
Markdown
108 lines
6.1 KiB
Markdown
# FEATURES.md — ClientHub Freelancer Client Portal
|
|
|
|
**Domain:** Freelancer client portal — solo personal branding consultant
|
|
**Project:** ClientHub (welcomeclient.iamcavalli.net)
|
|
**Researched:** 2026-05-09
|
|
**Confidence:** HIGH
|
|
|
|
---
|
|
|
|
## Context
|
|
|
|
Two asymmetric roles. Admin (the freelancer) has full CRUD. Client (read + lightweight interaction) accesses via secret URL — no login, no account — and can view, comment, and approve. The product competes indirectly with Notion client portals, HoneyBook, Dubsado, and bespoke agency portals. The differentiator is zero-friction secret link access and personal brand positioning.
|
|
|
|
---
|
|
|
|
## Table Stakes
|
|
|
|
Features clients expect when opening any project portal. Missing these causes confusion, distrust, or support overhead.
|
|
|
|
| Feature | Why Expected | Complexity | Notes |
|
|
|---------|--------------|------------|-------|
|
|
| Project overview at a glance | Client needs to know "where we are" without reading walls of text | Low | Name, brand, brief, current phase |
|
|
| Phase + task status visibility | Primary client question is "what's done, what's next" | Low | Phases with nested tasks; status per task (todo / in progress / done) |
|
|
| Deliverable approval | Client must formally sign off on outputs | Medium | Per-deliverable approve action; state persists; admin sees approval timestamp |
|
|
| Inline commenting on tasks/deliverables | Feedback and questions without email | Medium | Flat comments sufficient for v1; threading is nice-to-have |
|
|
| Document / file links | Deliverables, briefs, contracts surface in the portal | Low | Links to Google Drive, PDF, external URL; no file hosting needed |
|
|
| Payment status visibility | Client needs to know what they owe | Low | Deposit 50% + balance 50%; three states each: pending / invoiced / paid |
|
|
| Total quoted amount (not itemized) | Client expects to see the agreed number | Low | Single total; line items are admin-only |
|
|
| Mobile-readable layout | Clients open links on phones | Low | Responsive web; no native app |
|
|
| Persistent secret link | Link must not expire or rotate without notice | Low | UUIDs in DB, never regenerated unless admin resets explicitly |
|
|
| Trustworthy, branded appearance | First impression determines confidence in the consultant | Low | Logo, brand colors, professional typography — not a generic SaaS look |
|
|
|
|
---
|
|
|
|
## Differentiators
|
|
|
|
Not expected, but meaningfully improve experience or workflow.
|
|
|
|
| Feature | Value Proposition | Complexity | Notes |
|
|
|---------|-------------------|------------|-------|
|
|
| Decision log / history | Running record of agreed decisions — eliminates "we never agreed on that" disputes | Low | Append-only note stream visible to client; admin writes entries |
|
|
| Phase progress indicator | Visual progress bar gives a sense of momentum | Low | Derived from task completion %; no extra data model needed |
|
|
| "Last updated" timestamp on dashboard | Shows the portal is live and maintained | Low | Trivially derived from DB updated_at |
|
|
| Admin overview: all clients at a glance | Freelancer scans all active projects and overdue payments in one view | Medium | List with status badges; payment alert if overdue |
|
|
| Payment status badge with clear labels | Color-coded states (red = unpaid, yellow = invoiced, green = paid) | Low | Client sees their own; admin sees all |
|
|
| Shareable link reset | Admin can invalidate and regenerate a client's link if it leaks | Low | DB field update + redirect; rarely used but reassuring |
|
|
| Service catalog | Admin builds quotes from a curated menu of services; reusable across clients | Medium | Lookup table; admin-only; used by Claude in v2 |
|
|
| Claude-assisted onboarding (v2) | Generates phases + quote draft from a brief — massively speeds up admin work | High | Explicitly v2 in PROJECT.md |
|
|
|
|
---
|
|
|
|
## Anti-Features
|
|
|
|
Deliberately NOT building these.
|
|
|
|
| Anti-Feature | Why Avoid | What to Do Instead |
|
|
|--------------|-----------|-------------------|
|
|
| Client login / account creation | Adds friction with no benefit for a small client list | Secret UUID link |
|
|
| In-app invoicing / PDF generation | Accounting is out of scope | Show payment status only |
|
|
| File upload / storage | Massive complexity | Link to Google Drive or Dropbox |
|
|
| Email / SMS notifications | Transactional email infrastructure is heavy | Manual communication fine for small client list |
|
|
| Multi-admin / team roles | Freelancer works alone | Single admin |
|
|
| Client-editable project structure | Clients editing phases corrupts admin's source of truth | Comment and approve only |
|
|
| Itemized pricing visible to client | Erodes commercial confidentiality | Single total; detail is admin-only |
|
|
| Kanban / drag-and-drop board | Phases are sequential, not a fluid backlog | Ordered phase list |
|
|
| Time tracking | Out of scope for project-based billing | Not relevant |
|
|
| Multi-language / i18n | Single consultant, single-market | Hardcode interface language |
|
|
|
|
---
|
|
|
|
## Feature Dependencies
|
|
|
|
```
|
|
Secret link (UUID) → Client dashboard
|
|
Client dashboard → Phase/task display
|
|
Phase/task display → Deliverable approval
|
|
Phase/task display → Inline commenting
|
|
Admin client management → Secret link generation
|
|
Admin client management → Payment tracking
|
|
Service catalog → Quote building (admin picks from catalog)
|
|
Quote building → Payment tracking (total = basis for deposit/balance)
|
|
Service catalog → Claude onboarding v2
|
|
```
|
|
|
|
**Key insight:** Admin must create data before the client dashboard shows anything meaningful. Admin-first, then client.
|
|
|
|
---
|
|
|
|
## MVP Build Order
|
|
|
|
1. Admin: create/edit client record with secret link generation
|
|
2. Admin: create/edit phases and tasks per client
|
|
3. Admin: set payment amounts and statuses
|
|
4. Client dashboard: read-only view (overview, phases, tasks, payment status, documents)
|
|
5. Client: deliverable approval
|
|
6. Client: inline comments
|
|
7. Admin: all-clients overview
|
|
8. Admin: service catalog
|
|
9. v2: Claude-assisted onboarding
|
|
|
|
---
|
|
|
|
## Open Questions
|
|
|
|
- What happens when a client accidentally shares their secret link? Is link reset sufficient, or should there be an access log?
|
|
- Does the decision log need to be visible to clients from day one, or deferred?
|
|
- Should approval actions be reversible (un-approve)?
|