Building Actual Hour: A Privacy-first Time Tracker with a Built-in Kanban Board

A few months ago we caught ourselves doing the same dance for the third time on the same client project: take a screenshot from one tool, paste it into another, mark a card “in review”, flip back to the first tool to pause the timer, then realise the estimate on the card had been wrong by half. The friction was small but constant, and most of it came from the fact that our time tracker and our task board didn’t really know about each other.

We’re Angry Shark Studio. We work on Unity AR/VR projects, Kotlin Multiplatform apps, and AI integrations for other teams. That means a lot of client work, a lot of context switching, and a lot of hours that need to land on the right project at the right rate. Time tracking is plumbing for us. It’s not the interesting part of the day, but if it doesn’t work, nothing else does.

This is the story of why we started building our own tool, the design decisions that came out of it, and what’s already shipped. The product is called Actual Hour.

The three things that pushed us to build something

Most time trackers do their job. We weren’t unhappy with any one of them in particular. What pushed us over the line was a small pile of mismatches that added up.

Our work product was sitting on someone else’s server

Time trackers that capture screenshots store those screenshots on the vendor’s infrastructure. That’s the standard pattern, and for a single freelancer it might not matter. For a studio that runs client projects under NDAs, it does matter a bit more.

Every screenshot the tracker grabs is potentially client code, client design files, internal messaging, or sensitive credentials caught mid-paste. None of those things are our property in any meaningful sense, and we kept thinking the same thing every time the dashboard auto-loaded a thumbnail: “this should not be living on a third-party bucket.”

We wanted a model where the workspace owner could keep screenshot files on storage they control rather than defaulting to a vendor-owned bucket.

Our cards and our timer didn’t talk to each other

We used a Kanban tool for tasks and a separate tracker for time. Two products, two browser tabs, two billing pages, and an awkward seam in the middle. You start a timer, switch tabs, find the card, paste the link into a note, then maybe forget to mark the card “done” when you stop.

What we actually wanted was simple: pick the card, hit start, and the time tracks against that card. Stop the timer, the time logs back to the card. No glue code, no extension, no copy-paste of card titles into a task description field on a tracker.

The other thing we wanted was an estimate field on every card. Not a Power-up, not a paid add-on, not a separate analytics product. Just the basics: “we said this would take three hours, here’s where we actually landed.” That number is the most useful one we have for client conversations, sprint reviews, and our own honesty about how long things take. The fact that it costs extra on most boards always felt strange to us.

Most tools were either too small or too big

Half of the time-tracker market is built for enterprise teams that want surveillance, payroll automation, GPS, attendance, and timezone management. The other half is built for solo freelancers and stops short of being useful in a real team.

We sit in the middle. Two to fifteen people, a mix of W2-ish team members and contract folks, a few clients to bill, projects with budgets and deadlines. None of the existing tools quite landed in that gap. They were either too heavy and surveillance-flavoured, or too light to be useful when more than one person was involved.

What we ended up building

Once we wrote out the friction, the design fell into place pretty quickly.

One product, not two. A desktop tracker that records time, screenshots, and activity, plus a web dashboard with a built-in Kanban board. The timer can be started from a card on the board, or independently. Time logs against a card automatically when one’s selected.

Estimate next to actual on every card. When you create a card you set an estimate in hours. As the timer accumulates against that card, the board shows the actual hours and the difference. Cycle time, lead time, and “in progress” counts are right there in the board header. No paid analytics tier required.

Google Drive storage is the planned launch model for screenshots. The owner will connect Drive once, and screenshot files are intended to land in an “Actual Hour” folder in that Drive. Team members won’t see a Drive auth prompt because uploads route through a Supabase Edge Function using the owner’s tokens. The development build currently uses local Supabase Storage while we finish that integration.

Privacy controls that work without a meeting. Workspace admins can flip screenshots off entirely for any individual team member from the Team page. Time tracking continues without them. Screenshots are blurred by default in the dashboard, so a quick glance during a screen-share doesn’t expose anything you didn’t mean to show. Admins can disable the blur if their compliance setup needs it.

A small native desktop app. The tracker is built on Tauri 2 with a Rust core. The current Windows setup installer is around 4.1 MB. It uses the OS keychain to store auth tokens. It keeps recording when the network drops and syncs when you’re back online.

A “Take a break” button on the tracker. Because being honest about breaks is better than fudging them into the timeline later.

A runaway-timer guard. If you forget to stop the timer overnight, a configurable daily auto-stop (defaulting to eight hours) catches it before the next morning.

The tech choices, briefly

We chose tools that let us ship fast, run locally with no cloud account required, and stay easy to inspect later.

• Desktop tracker: Tauri 2.0 (Rust core, React/TypeScript UI). Tauri builds are small and OS-native. The Rust core handles screenshot capture, idle detection, and the SQLite buffer. The React UI is what you actually see and click.
• Web dashboard: Next.js 16 with App Router. Tailwind 4 for styling. The dashboard speaks Supabase directly through their JS client.
• Backend: Supabase. Postgres for the data, Supabase Auth for sign-in, Realtime for the “who’s tracking this card right now” pills, and Supabase Storage for screenshots until the Google Drive integration takes over. Phase 1 runs the whole Supabase stack locally through Docker. Phase 3 will move the production instance to Supabase’s hosted cloud, with the same client code pointing at it via environment variables.
• Optional storage: Google Drive. Workspace-owner Drive is the default for Phase 2 onwards. Bring-your-own S3 is on the Business tier. A documented self-hosted Docker edition is on the post-launch roadmap for teams that want everything on their own boxes.

If any of this sounds suspiciously calm, that’s because we built it to be calm. We deliberately avoided picking technologies that would force a particular cloud provider on us or our users. The whole stack can run on a developer’s laptop today.

Where we are

We split the work into four phases. We’re partway through.

• Phase 1 (local everything): complete. Desktop tracker, Kanban board, multi-workspace, teams and invites, time tracking, screenshots, idle recovery, manual entries, reports. All running on a local Supabase instance.
• Phase 2 (Google Drive integration): in progress. The desktop captures screenshots to local Supabase Storage today; the Drive integration plugs into the same upload path next.
• Phase 3 (cloud deploy): queued after Phase 2. Same code, pointed at Supabase’s hosted cloud.
• Phase 4 (billing and launch): Stripe, polish, public beta. Target window is late 2026.

The desktop tracker is real, the Kanban is real, the dashboard is real. We use it ourselves on our own client work. If you’d like to see what it looks like today, the Actual Hour product page has real screenshots from the working development build.

Who Actual Hour is for

We’re being deliberate about this because it shapes every decision we make about the product.

• Indie developers and freelancers who bill hourly and want honest numbers without a heavy tool getting in the way.
• Small studios and dev agencies, two to fifteen people, who want a calm shared view of time and tasks, with reports the client can actually read.
• Remote teams that prefer trust over surveillance. Light-touch accountability, privacy-first storage, no monitoring features you’d rather not have.

If you’re shopping for enterprise payroll, shift scheduling, GPS, geofencing, or workforce analytics: Actual Hour isn’t the tool for that, and we don’t plan to make it one.

What’s next

Public beta is targeted for late 2026. Until then, we’re heads down on Phase 2 and the polish work that has to happen before we open the doors.

If you’d like to be the first to know when it’s live, the product page has an “Email us” button at the bottom. We aren’t running a formal launch list quite yet, so for now we add interested folks to a notes file by hand. One email when we’re live. No drip campaign.

If you have feedback on the design choices above (especially the Drive-ownership model and the estimate-vs-actual default), we genuinely want to hear it. Email goes to the same address. We read everything.

Thanks for reading this far. Building products in public is more fun with people watching, and we’re glad you’re one of them.