If you've ever built or used a conventional time tracking application to measure productivity—like Time Doctor, Hubstaff, or ActivTrak—you've likely noticed a fundamental flaw.
As an engineer who often stares at lines of code, I looked at activity logs and found a recurring, useless pattern of raw data without actionable truth:
10:00 - 16:45: Google Chrome
For nearly seven hours, the tracker simply reported a single application name. Was that 7 hours of deep work writing reports in Google Docs, solving bugs on GitHub, sketching interfaces in Figma, or... hours of watching irrelevant tutorials on YouTube?
Traditional monitoring tools fail because their underlying technology is outdated: they only read the OS Window Title. In the modern era where the browser has essentially evolved into a "mini operating system," that approach is obsolete.
That was the starting point for designing Foculing TimeTracker—a research prototype I built to answer a specific challenge: How do we pierce the "Browser Black Box" without compromising privacy or local machine capabilities?
The Problem: Why Electron and OS-APIs Aren't Enough
Initially, the most straightforward solution seemed to be building an Electron-based application that hooks into the operating system API (like Windows API GetLastInputInfo). However, this introduced two new problems:
- Electron is a Memory Hog. For an application that lives in the background 24/7, consuming hundreds of Megabytes of RAM just to log time is an architectural "sin."
- Context Blindness in Modern Browsers. Pure OS APIs cannot dive into browser tabs. Modern browsers, especially Microsoft Edge and newer builds of Chrome, intentionally hide active tab titles from the OS-level workspace for security and performance reasons. When the OS asks "What is the user looking at?", Edge simply replies with its own process name, rendering OS-only trackers completely blind.
I needed a radical approach. I needed a Hybrid architecture.
The Solution: The Hybrid Architecture
To achieve pixel-level precision matching how we work today, I designed Foculing around three distinct, communicating components:
The Core Engine: Golang-based Background Service
I chose Golang as the heart of the system (Foculing Core Service). The goal was clear: the footprint had to be as minimal as possible.
Golang handles all the heavy lifting asynchronously (headless):
- Capturing running process names at the OS level every 1 second.
- Managing Idle Detection without a UI.
- Handling Offline Buffering using aggressively encrypted SQLite with SQLCipher.
The result? This core engine consumes an average of just ~11 MB of RAM with CPU utilization under 1%. Incredibly lightweight.
The Browser Agent: Piercing the Limits of Chrome
To solve the stagnant "Google Chrome" issue, I injected a Browser Extension (Manifest V3) using JavaScript. This extension isn't just a logger; it's an active agent that knows exactly what URL is currently open.
This agent has built-in privacy filters (stripping query parameters, blocking sensitive sites like banking portals), and then whispers directly to the Golang Core Service via a localhost socket connection—no internet required.
The Desktop UI: Replacing Electron with Wails
Instead of using Electron to render the user dashboard, I pivoted to Wails (Go + Web Frontend). We get the beauty and flexibility of web-tech (React/HTML/Tailwind), but the main binary runs incredibly light as a native app without the Chromium rendering overhead characteristic of Electron.
Looking at the current build of the dashboard, you can see how this architecture translates into real, actionable UX for the user:
- The Productivity Donut: A clean visualization separating Active Time (e.g., 2h 16m) from Idle Time (1h 8m).
- Workforce Health Engine: Right beside it, there's a real-time monitor for Burnout Risk and Underutilization. If an employee is overworked, the system knows.
- Granular 'Top Applications': Because of the Hybrid Architecture, the "Top Applications" list doesn't just show
chrome.exe. It breaks it down:gemini.google.com(7 minutes),google.com, alongside native apps likeExplorer.EXEandWhatsApp.Root.exe. Each with an automated tag (PRODUCTIVE, NEUTRAL, DISTRACTION).
The Biggest Challenge: Synchronizing the Data (Real-time Orchestration)
The hardest part of this development wasn't building the applications themselves; it was Data Orchestration.
When a user switches from "VS Code" to a "Jira" tab in Chrome, the Golang Core logs chrome.exe, and at the exact same heartbeat, the Browser Agent sends a URL event for jira.atlassian.net. Foculing has to intelligently merge these two data streams with precise timestamps, store them in the local encrypted database, and eventually compress them into a Daily Summary Payload sent to the Server (requiring only ~12 KB bandwidth per day per user!).
Previously, our productivity metrics looked dull:
10:00 - 10:30: Google Chrome
With the Foculing architecture, that data pipeline transforms into a smart matrix structure:
10:00 - 10:05: VS Code (Productive)
10:05 - 10:10: YouTube - "React Tutorial" (Distraction)
10:10 - 10:15: Jira - Sprint Planning (Productive)
10:15 - 10:30: GitHub.com - Code Review (Productive)
What's Next?
The research and initial release of this hybrid architecture serve as a proof-of-concept that transparency and privacy can coexist if engineered with the right programming language and an Offline-First system.
Employee data is now 100% shielded by AES-256 encryption, productivity metrics are no longer easily manipulated by tab hijackers, and for me as a developer, seeing the Golang and Wails services run stably with minimal RAM is intensely satisfying technically.
Keep an eye on the Foculing project — because your time tracker should be an analytics tool, not just a blind OS stopwatch.
Top comments (0)