The build-versus-buy conversation for workforce analytics goes wrong in a predictable way. Someone sketches the dashboard, estimates two sprints, and is roughly right about the dashboard. The dashboard was never the hard part.
What follows is an honest account of where the effort actually sits, from a vendor — which you should discount accordingly, so I have tried to be specific enough that you can check it.
What you can genuinely build cheaply
Start here, because for a meaningful number of teams the answer is that you do not need a product at all.
Meeting load and calendar fragmentation. Both the Google Calendar and Microsoft Graph APIs give you this directly. Hours in meetings, number of distinct meetings, size of the largest uninterrupted gap per day, how much of the week is fragmented. A competent engineer gets a useful version of this in a week, and for a lot of organisations it answers the actual question — our cost of meetings piece is the analysis you would be reproducing.
Delivery metrics. Git, CI and your issue tracker already hold cycle time, deploy frequency, change failure rate, review latency and rework. DORA and SPACE are computed from systems you own, and no desktop agent can produce them — a vendor claiming to derive change failure rate from activity data is selling you something that does not work.
Tool spend versus tool usage. SSO logs plus your SaaS invoices gets you most of a shadow-IT and licence-waste picture without touching an endpoint. The SaaS sprawl piece covers what to look for.
If your questions live in that list, build it. You will get a better-fitting answer than any product gives you, joined to your own data, and you will not have put an agent on anyone's laptop.
Where the build actually fails
The gap between that list and a workforce analytics product is desktop activity — which application, for how long, in what pattern. That requires an endpoint agent, and the agent is the project.
Cross-platform collection is three implementations, not one. The active-window and idle-detection APIs are entirely different on Windows, macOS and Linux, and on Linux they differ again between X11 and Wayland. macOS additionally requires accessibility and screen-recording permissions that the user must grant and that reset on some updates. Teams routinely build the Windows version in a fortnight, conclude the project is on track, and then spend a quarter on macOS.
It never stops needing maintenance. OS releases change or deprecate the APIs you depend on. Endpoint security tools quarantine unsigned binaries, so you need code signing on every platform and a notarisation pipeline for macOS. Sleep, hibernate, VPN drops and clock changes all produce data that is wrong in ways that are not obvious until someone queries it. This is not a build cost, it is a standing cost, and it is the line most business cases omit.
The taxonomy is the unglamorous majority of the value. Raw data says chrome.exe and Code.exe. Useful data says which of the forty browser tabs was work. Classifying thousands of applications and domains into categories, keeping up as tools appear and get renamed, and handling the long tail of internal and regional software is continuous curation. Without it you have a dashboard where most time is unclassified, which is worse than no dashboard because it looks authoritative.
The case where building genuinely wins
One situation makes it the right call, and it is not cost.
If the data cannot leave your infrastructure — a regulated environment, a classified context, a client contract that forbids third-party processing of employee data, a jurisdiction with residency requirements you cannot satisfy commercially — then build is the only option that meets the constraint, and the maintenance cost is simply the price.
Be honest about whether that applies, though. "We would prefer the data stayed in-house" is a preference, and most vendors can address it with residency options and a DPA. "Our client's security schedule prohibits it" is a constraint. The two get conflated in business cases, usually by whoever wants to build.
The second decent case is narrower: you need one specific metric nobody sells, joined to internal data nobody else has. Then build that one thing rather than a platform.
The option most people should take
Buy the agent and taxonomy, build the analysis.
The parts that are expensive to maintain and undifferentiated — cross-platform collection, code signing, app classification, retention enforcement — are exactly the parts worth outsourcing. The parts that are specific to you — how capacity maps to your org structure, joining activity to your delivery data, the view your leadership actually reads — are better built by you against an export or API.
Which makes export quality a first-order evaluation criterion rather than a footnote. Ask whether you can get per-person daily records out in bulk, whether the API is documented and versioned, and whether there is a rate limit that makes a nightly sync impractical. A tool you cannot get data out of has made your build-versus-buy decision permanent.
The question that settles it
Before costing anything, write down the decision you intend to make with the data. Hire or not. Restructure meetings or not. Fix the deploy pipeline or not.
Then check which of the three sources above answers it. If calendar data or git answers it, build that this week. If it genuinely requires desktop activity, the agent is the project and you should price the agent, not the dashboard. Our guide to tracking productivity properly starts from the same place, because the question determines the tool rather than the other way round.
Where ProdView fits
We are the buy option for the agent-shaped part: one Rust agent running natively on Windows, macOS and Linux from a single core, a maintained app and domain taxonomy, activity metadata only with no screen content or keystrokes, configurable retention, and employees on the same dashboard as their managers. $4.99/user/month, three seats free.
When not to pick us: your data genuinely cannot leave your infrastructure, in which case build it and budget the ongoing agent maintenance honestly. Also not us if your questions are about meetings or delivery — those live in your calendar and your CI, and you should go and get them from there rather than buying anything.
Try before you commit
Three seats are free forever, which is enough to compare against whatever you would build. The ROI calculator is free and needs no signup if you want the business case before the comparison.