HourTab

Blog · July 10, 2026 · ~10 min read

Notion vs. HourTab for retainer client hours: what a shared Notion page can and can’t show clients

If you run your freelance practice in Notion, it is natural to wonder whether Notion can also handle retainer client visibility. The internal tracking works well. Sharing that data with clients in a format they can check in 10 seconds is where Notion runs into a structural problem that is not solvable with more formulas.

What Notion does well for retainer tracking

Notion’s database system is genuinely well-suited for internal retainer management. You can build a database of retainer clients with properties for monthly cap, hours logged this cycle, cycle start date, and a formula property that computes hours remaining. Rollup fields let you pull in time entries from a linked database. Filtered views let you see just the current cycle. The flexibility of Notion databases means you can design exactly the properties your practice needs without being constrained by a tool’s built-in categories.

Many freelancers maintain a Notion retainer tracker that works very well for their own reference. They know where to look, they understand the structure they built, and the database gives them a running picture of every client’s cycle status. For the freelancer’s internal use, this is a reasonable solution.

The question changes when you consider the client’s experience.

What sharing a Notion page gives the client

Notion allows you to share any page publicly. A shared Notion page is accessible to anyone with the link, without requiring the viewer to have a Notion account. On the surface, this sounds like a solution: share your retainer tracker page with your client, and they can see their hours.

The practical experience for the client is more complicated. When a client opens a shared Notion database page, they see a Notion interface: column headers, row entries, property values. If you have built a formula that computes “hours remaining,” that value appears as a number in a cell. To interpret it, the client needs to find the right row (their client record), read the right column (hours remaining), and understand the structure you built.

This is not impossible — a tech-savvy client who uses Notion themselves will navigate it without difficulty. But it introduces several friction points that make it a poor default client-facing interface:

Notion loads slowly for external viewers. Shared Notion pages require Notion’s JavaScript to render before any content is visible. On a slow mobile connection, this takes several seconds. A client checking their hours from their phone while in a meeting is not served well by a tool that requires waiting for a full page render.

The interface requires interpretation. A database row is not a status dashboard. There is no visual progress bar. There is no immediate “12 of 20 hours used, 8 remain” summary that the client can read in one pass. The client sees property labels and values and has to synthesize those into a retainer-status picture themselves. The cognitive load is low for you, because you built the structure. For the client, who encounters it without context, it is higher.

Clients can see the full database structure. Unless you build a filtered view specifically for sharing, a shared Notion database reveals all your data: other clients’ rows, internal notes, billing rates, any property you have in the database. Building a clean per-client filtered view requires additional setup and maintenance as your database evolves.

No cycle-aware reset. Notion does not have a concept of a billing cycle. If you track hours in a database, the cycle reset is a manual operation: you either archive old rows, reset a formula starting date, or create a new database per cycle. This is manageable internally, but it means the client-facing view requires ongoing manual maintenance to reflect the current cycle accurately.

The progress bar problem

The detail that matters most for client communication is the one Notion cannot provide: a visual progress bar showing hours used as a fraction of cap.

Clients parse a progress bar in a fraction of a second. “The bar is two-thirds full” communicates “I’ve used two-thirds of my hours this month” instantly, without reading a number or doing any math. This is why the progress bar format is the standard for retainer status displays — it maps to the intuitive sense of “how much is left” that humans form for any finite resource.

A Notion formula can output a percentage: “60% used.” It can output a number: “8 of 20 hours used.” It cannot output a progress bar. Notion does not support progress bar properties in its database system. There are third-party Notion widgets that can display bar charts, but embedding them in a shared public page adds significant complexity and still doesn’t create the clean one-glance status view a client needs.

This matters because the quality of client communication around retainer hours is directly related to how easily clients can access the answer. A client who has to interpret a database row to understand their retainer status is a client who will still email you to ask — because interpreting the database is harder than typing “hey, how many hours do I have left this month?”

What HourTab does (specifically)

HourTab generates a permanent public URL for each retainer client. The URL shows:

The client bookmarks this URL at the start of the retainer. They check it whenever they wonder where they stand. No login. No navigation. No interpretation required. The URL answers the question they have before they finish forming it.

The data comes from a CSV export of your time tracker — Clockify, Toggl, Harvest, or any tool that exports time entries. If you track time in Notion itself (using manual entry properties rather than a dedicated time tracker), Notion databases can be exported to CSV. You export the relevant rows for the current cycle, upload the CSV to HourTab, and the client URL updates.

Direct comparison: Notion shared page vs. HourTab URL

Progress bar: Notion shared page — no. HourTab URL — yes.

Hours remaining displayed prominently: Notion shared page — only if you build and maintain a specific formula property, displayed as a number in a cell. HourTab URL — yes, first thing visible.

Cycle reset date visible: Notion shared page — only if you add a date property and the client knows to look for it. HourTab URL — yes, shown alongside the progress bar.

Client login required: Notion shared page — no (public share works). HourTab URL — no.

Loads on mobile in under 2 seconds: Notion shared page — usually not. HourTab URL — yes, static HTML.

Update mechanism: Notion shared page — you update the database (manual entry or paste time data). HourTab URL — you upload a CSV from your time tracker.

Other client data visible to this client: Notion shared page — potentially yes, unless you build per-client filtered views. HourTab URL — no, each URL shows only that client’s data.

Works without Notion account for the client: Notion shared page — yes. HourTab URL — yes.

When Notion alone is sufficient

One retainer client who is a Notion user themselves. A client who lives in Notion and is comfortable navigating a shared database will find a shared Notion page adequate. They understand the interface, they can read the formula results, and the cognitive overhead of interpretation is minimal for them. The mobile loading time may still be a friction point, but they will navigate around it.

Clients who never ask about hours mid-cycle. If your retainer client is satisfied receiving a summary at invoice time and never reaches out between cycles with hours questions, the visibility problem doesn’t actively hurt you. Some long-tenured retainer relationships operate on implicit trust and client indifference to mid-cycle status. For these clients, any solution including Notion shared pages is sufficient.

Flat-fee retainers. If the retainer is a fixed monthly fee for a defined deliverable rather than an hours pool, there is no “hours remaining” question to answer. Notion as a project tracker makes sense; client visibility of hours is irrelevant.

When you need HourTab alongside Notion

Clients ask about hours between invoices. The first indication that a Notion shared page isn’t solving the visibility problem is a mid-cycle email asking how many hours remain. If you receive this email, the client found the Notion page insufficient — either they couldn’t navigate it, or they found interpreting the database too much friction relative to just asking. HourTab’s URL eliminates that email.

Multiple retainer clients on Notion. Building and maintaining clean per-client filtered views in Notion for three or four retainer clients is manageable but adds setup overhead. Each filtered view requires its own share link, its own maintenance as the database schema evolves, and its own cycle reset procedure. With HourTab, each client gets a URL that persists indefinitely, with updates coming from a CSV upload rather than database maintenance.

Non-technical clients. A client who is not comfortable with Notion’s interface — designers, executives, business owners who don’t use productivity tools in their daily work — will find a shared database confusing. HourTab’s URL requires no prior knowledge of any tool. The progress bar is self-explanatory. “Bookmark this link for your hours” is a one-sentence onboarding instruction that works for any client.

You want a professional presentation. A shared Notion page carries Notion’s interface branding, fonts, and layout regardless of your subscription tier. A HourTab URL presents as a clean, minimal hours dashboard without platform branding. For a Solo plan user ($9/month), the URL includes an “HourTab” footer credit. For Studio plan users, the URL can carry your own subdomain and custom header per client. Both are more professional as a client-facing artifact than a shared Notion database.

Using Notion for internal tracking with HourTab for client visibility

Many Notion-native freelancers use both tools. Notion handles their internal workspace: project notes, client context, deliverable tracking, task management, and internal time logs. HourTab handles the single job of client-facing retainer hours visibility.

The connection between them is a CSV export. If you log time in a Notion database, you can export that database to CSV (Notion supports CSV export from any database view). You then filter that export to the relevant client and current cycle, and upload it to HourTab. The client URL updates to reflect the exported hours.

This is a more manual workflow than exporting from a dedicated time tracker with clean date filtering and client attribution. If you log time in Clockify, Toggl, or Harvest, the export is a one-step filter-and-export. If you log time in a Notion database, the export requires cleaning up the CSV to match HourTab’s expected format. Many Notion users find this acceptable as a weekly task; others prefer to use a lightweight time tracker alongside Notion for the billing-accuracy layer.

The result, either way, is a client URL that is clean, fast, and self-service — which is what client communication around retainer hours requires to stop generating mid-cycle emails.

The core distinction

Notion is a workspace tool. It is designed for you to organize your work, your notes, and your data in ways that make sense for your internal processes. When you share a Notion page with a client, you are sharing your workspace tool with someone who did not build it and is encountering it cold.

HourTab is a client communication tool. The URL it generates is designed for the client from the ground up: what does the client need to know when they check their retainer status, and what is the fastest possible interface for delivering that answer. The progress bar, the hours remaining, the cycle reset date — these exist because they are the three things a retainer client is looking for when they open the link.

The tools are not competitors in the way that two time trackers are competitors. Notion is excellent at what it was built for. HourTab is excellent at a specific job that Notion was not built for. Many freelancers use both, and the combination takes about 15 minutes to set up per client: build your internal Notion tracker as you normally would, export when you want to update client visibility, and let HourTab’s URL handle the client-facing communication. See retainer billing best practices for how this fits into the broader billing cycle workflow.

HourTab turns your retainer hours data into a live client-facing URL with a progress bar and cycle reset date. Start free →