The Hardest Part of Building a Battery Health Tool Wasn't the Code — It Was Trust
I recently built Battery Health Lab, a free browser-based tool that helps Windows users understand the battery report generated by powercfg /batteryreport.
The parsing and health calculation were not the hardest parts.
The difficult question was: why should someone trust an unknown website with a file generated from their own laptop?
A Windows battery report looks personal. It can contain device and battery details, usage history, capacity data, and timestamps. Even if the tool only needs a few fields, users cannot be expected to trust a vague “upload your file” message.
That changed the product decisions.
- The report is processed locally with browser JavaScript.
- It is not sent to a server or stored by the tool.
- No account is required.
- Users can enter design capacity and full-charge capacity manually instead.
- Cycle count is treated as supporting context, not a universal pass/fail score.
I also added plain-language explanations because privacy alone does not create trust. A number such as “80% health” needs context: runtime, temperature, calibration, physical condition, and the trend over time still matter.
The result is Battery Health Lab.
The lesson for me was that trust is not a paragraph added to a privacy page after launch. It is part of the product architecture, interface copy, and the alternatives you give users.
For founders building tools that handle local files or diagnostic data: what has helped your users trust the product—local processing, open-source code, a demo mode, or something else?
Local processing only earns trust if the user can verify it without taking your word for it. The highest-leverage thing I've seen work is telling people, right in the UI next to the file picker, to open DevTools and watch the Network tab while they load the file, so they see for themselves that nothing leaves the machine. That turns a claim into a demonstration and costs you one line of copy.