ActiSignal

The project in one paragraph

ActiSignal is our own product: a system for monitoring employee activity and the health of company Windows computers. It consists of an agent running as a Windows service, an ASP.NET Core API on PostgreSQL, an app for the customer's administrators, an internal console for operating the service, and a Next.js product website. All of it is designed around one premise: show a company what it needs to organise work and keep its computers running — and stop exactly where an employee's privacy begins.

The problem: visibility without surveillance

Employee monitoring software has a bad reputation, and not without reason. Many tools take a screenshot every few minutes, log keystrokes and store every full URL visited. That scope is hard to defend under the GDPR and labour law, and it breeds distrust inside a team.

Yet most questions a company owner or an IT department actually has are much simpler: has work started, how long was the computer in use, are the licences we pay for being used, which laptop has not reported for a week. None of them requires knowing what was on the screen.

So ActiSignal collects metadata, not content — and that is not a setting that can be toggled, it is a boundary written into the architecture. Code that could read a window title or typed text simply does not exist.

Architecture — four applications, one API

Windows agent (service + session process)  ──HTTPS──┐
Customer admin app (WPF)                   ──HTTPS──┤
Customer web panel (Next.js, BFF)          ──HTTPS──┼──>  API (ASP.NET Core)  ──>  PostgreSQL
Service operator console (WPF)             ──HTTPS──┘

The backend follows Clean Architecture: Domain (entities and rules, no dependencies), Application (every operation an explicit use case), Infrastructure (EF Core, PostgreSQL, security) and Api as the composition root. The agent follows the same discipline: logic and state machines live in a project that can be tested without Windows, while Win32, SQLite and HTTP calls sit in a separate infrastructure layer.

From day one we also kept two worlds apart: customer features (their organisation's computers, sessions and reports) and service-operator features (organisations, licences, agent releases). They are two separate apps and two separate API areas — a feature from one never leaks into the other.

The Windows agent — a system service and a per-session process

A Windows service runs in isolated session 0, so it cannot see the user's desktop on its own. For every signed-in session it starts a separate, lightweight worker process, watches it and restarts it if it stops — and a missing worker is reported to the panel as a problem.

The worker in the user's session is treated as untrusted: it never talks to the API, it only hands readings to the service over a local, permission-restricted channel where both ends verify each other. Only the service has network access and credentials.

Active time without capturing the keyboard

To measure active time it is enough to know that the computer is in use — not what was typed. Every few seconds the agent asks the system how long it has been since the last interaction, and installs no keyboard or mouse hooks. The computer's state has a simple precedence: locked > idle > active, with idle starting after 5 minutes by default.

Website domains come from a browser extension (Edge, Chrome, Firefox) that passes on the host name only. A site counts only while the browser is the foreground app, addresses are grouped into registrable domains using the Public Suffix List, and the feature is off by default — an organisation's administrator turns it on deliberately.

Remote work: no data lost while a laptop is offline

A remote employee's laptop can go hours without a network. The agent writes events to a local SQLite queue and uploads them in compressed batches, on separate channels for session events and for activity. The queue has hard size and age limits, and if it ever has to drop something, the number of dropped events goes to the panel in the heartbeat — data loss is never silent. The server accepts batches idempotently, so a retry after a dropped connection never creates duplicates.

Multi-tenancy that fails closed

All organisations share one database schema, and isolation is layered: a global EF Core query filter that fails closed when no organisation context is set, a guard on save, composite foreign keys, and a test that polices the short list of places allowed to bypass the filter. An id from another organisation simply returns 404.

Roles, audit and automatic data deletion

• Roles — Owner, Administrator, Analyst and Auditor, each with a fixed set of permissions.

• Audit log — domain events written in the same transaction as the change, into an append-only table. Even reading one person's activity is audited.

• Retention — the organisation chooses whether raw data is kept for 30, 90, 180 or 365 days. A background job deletes it automatically, leaving only aggregated daily summaries.

• Admin sign-in — a mandatory second factor (TOTP) and recovery codes.

Rollout and updates

The agent ships as an MSI installer (WiX) that IT can deploy silently through Intune, GPO or an RMM tool. Device enrolment uses a short-lived token: the device exchanges it for its own secret, stored with DPAPI, and that secret for a short-lived access token that is rotated regularly. Revoking a device takes effect within about a minute.

Updates move through stages — draft, pilot, published with a staged rollout window. The agent downloads a package only from its own API and verifies its checksum, and the updater installs only packages with a valid digital signature.

Quality as part of the product

• close to 60 recorded architecture decisions (ADRs) explaining why things work the way they do,

• more than 11,000 test methods, including integration tests against a real PostgreSQL in containers and architecture tests that police dependency direction,

• compiler warnings treated as errors, and an analyser that forbids reading the clock around the time abstraction — which keeps retention and session logic fully testable.

The product website

actisignal.pl is a statically exported Next.js 16 site in Polish and English, with an animated preview of the panel on sample data, pricing and an extensive FAQ. Analytics runs only after consent (Consent Mode), and the copy is written for the phrases companies actually use when looking for this kind of software.

What this project taught us

The most important decision in ActiSignal was not about technology, it was about the scope of data. Limiting the product to metadata made it easier to deploy lawfully, easier to explain to a team and easier to secure — data you never collect cannot leak. The same rule, "collect only what answers a concrete question", works for any system that processes data about people.