Most freelance designers running their studio in Notion end up with the same problem: a workspace that started as one or two pages, accumulated databases over a year of casual additions, and now sits in a state of cheerful disrepair. There is a “Clients” database. There is a “Projects” page that is somehow not a database. There is an inbox of tasks that has no relation to any project. Invoices live in a different tool entirely.
This article walks through the schema and relationship structure that turns Notion into an actual operations system for a freelance design practice — one where editing a project once updates the dashboard, the client revenue rollup, and the rate calculation simultaneously. The structure is the same one used inside FoxWork OS, but every principle below works in any Notion workspace, and a designer with a free afternoon can build a basic version from scratch.
Why Notion for design project tracking
A short detour to acknowledge the alternatives. Asana, Trello, ClickUp, Monday, Airtable, Linear — all do project tracking. Asana has better task automation. Linear has better velocity tracking. Airtable has more flexible database views. None of those tools are wrong choices for project tracking specifically.
Notion’s advantage for a freelance designer is not project tracking in isolation. It is adjacency. The project record sits next to the SOW, the meeting notes from the kickoff call, the asset library entry for the client’s brand colors, the invoice schedule, and the year-end profitability report. None of those connections require switching tools. None of them require building integrations.
For a one-person practice running ten to forty projects a year, that adjacency is worth more than the marginal feature advantages of a dedicated project tool. The right test is whether a designer’s non-project work — proposal writing, expense tracking, asset management — also fits inside the same system. If it does, Notion is the right substrate.
The rest of this article assumes that test passes.
The minimum schema
Six databases will run a freelance design practice. Three more are useful. One more is optional. The minimum six:
- Clients — every company or individual the designer works with
- Projects — every engagement, past, present, and proposed
- Tasks — atomic units of work, scoped to a specific project
- Invoices — billable items issued to clients
- Proposals & SOWs — pre-engagement documents
- Expenses — business costs paid in service of running the studio
The three useful additions:
- Meeting Notes — kickoff calls, review sessions, status check-ins
- Deliverables & Handoff — final-file transfer log, by project
- Asset Library — fonts, references, brand kits, license records
The optional one:
- Rate Calculator — a single-row database that computes the designer’s reference hourly rate from their target income, billable hours, and overhead. Everything in section 4 of the rate calculation guide operationalized as a Notion formula set.
Most freelance designers build the first three databases, stop there, and end up needing the others within six months of the practice growing. Building all ten upfront — even sparingly populated — is faster than retrofitting later.
Properties that matter on each database
A non-exhaustive guide to the fields each database actually needs. Designers should add their own fields, but skipping any of these creates pain later.
Clients
| Property | Type | Why |
|---|---|---|
| Client (name) | Title | The name |
| Status | Select (Active, Past, Lead, Cold) | What stage the relationship is in |
| First contact date | Date | Useful for relationship tracking and renewal nudges |
| Last contact date | Date | Same |
| Payment terms | Select (Net 7, Net 14, Net 30, Due on receipt) | Determines what shows up on invoices |
| Brand colors | Files | Quick visual reference when starting projects for repeat clients |
| Total revenue | Rollup | Lifetime revenue from this client (sum of related project revenue) |
| Lifetime hours | Rollup | Sum of estimated hours across related projects |
The two rollups at the bottom are what make this database useful. Without them, “Clients” is a glorified contact list. With them, it surfaces patterns: which clients pay the most, which take the most time, which are profitable per hour.
Projects
The most schema-heavy database. The fields that matter:
| Property | Type | Why |
|---|---|---|
| Project name | Title | The label |
| Client | Relation → Clients | Wires the project to the client |
| Status | Select (Lead, Proposed, Active, On Hold, Wrapped, Cancelled) | Current state |
| Project type | Select (Identity, Web, Print, Packaging, Illustration, Other) | For filtering and pattern recognition |
| Kickoff date | Date | Start of the engagement |
| Due date | Date | Final delivery target |
| Fee structure | Select (Project fee, Hourly, Retainer, Hybrid) | How the work is being billed |
| Quoted price | Number ($) | What the client agreed to pay |
| Final price | Number ($) | What was actually billed (may differ from quoted) |
| Estimated hours | Number | The designer’s pre-project estimate |
| Hours logged | Rollup | Sum of hours across related tasks |
| Project revenue | Rollup | Sum of paid invoices related to this project |
| Effective hourly | Formula | Final price ÷ Estimated hours, or Project revenue ÷ Hours logged |
| Revision count | Number | How many revision rounds have been used |
| Revision limit | Number | How many were quoted in the SOW |
| Over-revisions | Formula | max(0, Revision count − Revision limit) |
| Days to deadline | Formula | dateBetween(Due date, now(), “days”) |
Two formulas worth highlighting.
Effective hourly is the post-mortem rate calculation. After a project wraps, this number tells the designer what they actually earned per hour on this engagement. Compare to the reference rate computed in the rate calculator. If effective hourly is consistently below the reference rate, the designer is under-quoting; if consistently above, the designer can quote bigger projects. This is the single most important number in a freelance design business and most designers never compute it.
Over-revisions is the early-warning indicator. When this number goes above zero, the project has gone past its scoped revision limit. The designer should already be in conversation with the client about either compressing remaining feedback into the next round or invoicing additional revisions as a change request.
Tasks
A simpler database. The fields that matter:
| Property | Type | Why |
|---|---|---|
| Task | Title | What needs doing |
| Project | Relation → Projects | Which project this belongs to |
| Status | Select (To do, In progress, Blocked, Done) | Current state |
| Due | Date | When it is due |
| Hours | Number | Time logged or estimated |
| Billable | Checkbox | Whether this hour goes on an invoice |
| Type | Select (Design, Admin, Client comms, Revision) | For categorizing where time goes |
The Billable checkbox is critical and routinely omitted. Not every hour spent on a project is billable. Discovery calls usually are. Internal QA usually is not. Marketing the engagement on social usually is not. Without this distinction, the Hours rollup on the Projects database becomes meaningless.
Invoices
| Property | Type | Why |
|---|---|---|
| Invoice # | Title | Unique identifier |
| Project | Relation → Projects | Which project this is billing |
| Status | Select (Draft, Sent, Paid, Overdue, Cancelled) | Where it is |
| Issue date | Date | When sent |
| Due date | Date | Per the project’s payment terms |
| Paid date | Date | When the money actually arrived (often different from due date) |
| Amount | Number ($) | The fee |
| Tax amount | Number ($) | Sales tax / VAT, if applicable |
| Total | Formula | Amount + Tax amount |
| Days to pay | Formula | dateBetween(Paid date, Issue date, “days”) |
| Overdue days | Formula | Conditional: if not paid, dateBetween(now(), Due date) |
The Days-to-pay metric over time tells the designer which clients are slow payers. Combine it with a Clients-database rollup (“Average days to pay”) and the designer has data they can use to justify a deposit increase or earlier payment terms for specific clients.
Proposals & SOWs
A document store more than a transactional database, but worth structuring.
| Property | Type |
|---|---|
| Proposal name | Title |
| Project | Relation → Projects (optional — proposal may pre-date the project record) |
| Status | Select (Draft, Sent, Accepted, Rejected, Expired) |
| Sent date | Date |
| Decision date | Date |
| Quoted total | Number ($) |
| Win or loss reason | Rich text |
The Win/loss reason field is the one most freelance designers skip and most regret skipping. Five entries in, the designer starts to see patterns: lost on price, lost on timeline, won because of the portfolio, won because of a referral. Those patterns inform pricing and positioning decisions far better than gut feel.
Expenses
| Property | Type |
|---|---|
| Expense | Title |
| Date | Date |
| Amount | Number ($) |
| Category | Select |
| Project | Relation → Projects (optional, for expenses passed through to a client) |
| Tax deductible | Checkbox |
| Receipt | Files |
Categories worth pre-populating: Software/subscriptions, Hardware/equipment, Stock assets, Fonts/licensing, Professional services, Marketing, Continuing education, Home office, Travel, Meals (at the deductible percentage), Internet/phone, Other.
The relations that wire everything together
Schemas without relations are spreadsheets. The relationships below are what turn ten databases into a single operating system.
The relation map for the freelance design practice:
Clients ←→ Projects ←→ Tasks
←→ Invoices
←→ Expenses (optional)
←→ Proposals & SOWs
←→ Meeting Notes
←→ Deliverables & HandoffSix relations total. Each one a “dual” relation in Notion’s terminology — meaning it shows up on both databases automatically.
Once these relations exist, the rollups become possible:
- Clients → Total revenue: Sum of related Project revenue
- Clients → Lifetime hours: Sum of related Estimated hours on Projects
- Projects → Hours logged: Sum of related Tasks’ Hours where Billable is checked
- Projects → Project revenue: Sum of related Invoices’ Amount where Status is Paid
The “where Status is Paid” filtering inside a rollup is where Notion’s slightly-finicky rollup configuration earns its keep. The designer wants to know what they have been paid, not what has been invoiced. Rolling up only the paid invoices keeps the dashboard honest about cash on hand versus cash committed.
The dashboard
After the schema is in place, a single page pulls the operationally relevant views into one screen. Six to ten linked views, each filtered to show only what is currently actionable.
A baseline dashboard layout:
- Today — Tasks where Due is today and Status is not Done. The list a designer reviews at 9am.
- This week — Tasks where Due is in the next 7 days and Status is not Done. The horizon view.
- Active projects — Projects where Status is Active. With Due date, Days to deadline, Hours logged, Effective hourly columns shown.
- Open proposals — Proposals where Status is Sent and Decision date is empty. The follow-up list.
- Unpaid invoices — Invoices where Status is Sent or Overdue. Sorted by Overdue days descending. The collections view.
- Recent leads — Clients where Status is Lead and First contact date is in the past 30 days. The pipeline view.
- Top revenue clients — Clients where Total revenue is greater than 0, sorted descending. The “who matters” view.
- At-risk projects — Projects where Over-revisions is greater than 0 OR Days to deadline is less than 5 and Status is Active. The early-warning view.
Each of those is a linked view of the underlying database. Editing a row inside the dashboard view edits the source row. The designer never has to navigate into the underlying database to update a status; everything happens on the dashboard.
For a freelance designer running 5 to 15 active projects at any time, this dashboard is the home screen of the practice. Open Notion in the morning, scan top-to-bottom, know what to do.
Year-end review
A separate page, run once a year, that sits underneath the dashboard. The same schema enables a series of year-summarizing views:
- Revenue this year — Invoices where Status is Paid and Paid date is in the past year, summed
- Expenses this year — Expenses where Date is in the past year, summed
- Billable hours this year — Tasks where Billable is checked and Due is in the past year, summed
- Top clients by revenue — Clients sorted by Total revenue descending, top 5
- Least profitable wrapped projects — Projects where Status is Wrapped, sorted by Effective hourly ascending
- Expense categories — Expenses grouped by Category, summed per group
The least-profitable-projects view is the highest-leverage one. Looking at the bottom five projects of the year, most freelance designers can identify a specific pricing or scoping mistake they made on each. That diagnosis becomes next year’s pricing model adjustment.
Building it
Two paths.
Path 1: build it from scratch. Every database, every property, every relation, every rollup, every formula, every linked view, every dashboard layout, by hand in the Notion UI. For a designer who knows Notion well, this takes 12 to 20 hours, plus another 4 to 6 hours to seed sample data and verify everything connects. The Notion API technically supports building it programmatically, but most designers do not have a reason to write that code.
Path 2: use a pre-built template. This is what FoxWork OS exists for. The template ships with all ten databases, all relations, all rollups, all formulas, the dashboard, and the year-end review pre-built and pre-tested. Setup time is around 30 minutes, most of which is filling in a target annual income on the rate calculator and replacing sample data with real client records. The decision is mostly about whether 12 to 20 hours of building the template is a reasonable use of a designer’s time relative to the cost of buying it.
For a designer billing $100 an hour, the build-it-yourself path costs $1,200 to $2,000 in opportunity cost. For a designer billing $150, that climbs to $1,800 to $3,000. The template costs less than one billable hour. Most designers should buy.
The principle that holds either way: the schema above, with the relations and rollups in place, is the difference between a Notion workspace that looks like an operations system and one that actually behaves like one. Build it once, run the studio from it forever.