Official Brand

Consumer Tech Documentation

Real-world experiments, case studies, and documented findings across repair, service, software, and hardware

v6.3.3 Update: Bench Notes Visual Language & Security Hardening
WDIII Independent Hardware & Software Research Archive

Fodder Archive

Side experiments and informal notes that don't fit the main documentation. Overhauled in v6 with streamlined evaluation records. Open any entry to read it here.

Fodder Archive v6.3.3 Update — Bench Notes styling and streamlined records
🚧 More entries coming as experiments are completed. This archive grows alongside the main documentation.
📖

About TechStack Archive

Who we are, what we document, and why

TechStack Archive is a centralized documentation hub for organizing, accessing, and tracking complex consumer technology specifications and historical product archives. It collects real-world experiments, case studies, and documented findings across repair, customer service, software, hardware, security, and ecosystem research — turning scattered, one-off personal experiences into a structured, searchable reference that anyone can consult before buying, repairing, or switching devices.

The archive is built for consumers who want more than marketing claims and spec sheets: people deciding between an official Apple repair and a third-party shop, weighing a Pixel upgrade against an iPhone, auditing how exposed their AirDrop settings really are, or trying to hold a manufacturer accountable after a support failure. Each experiment documents what actually happened in one specific case — the costs, timelines, metrics, and friction — so readers can calibrate their own expectations rather than rely on universal rules that don't hold up.

TechStack Archive is independently built and maintained by WDIII as a single-source documentation project. Every finding is recorded with its scope and limitations noted up front, and queued research is tracked openly so visitors can see what has been tested, what is paused, and what is still to come. The goal is simple: give consumers a clear, honest idea of what to expect — and some reassurance that they are not alone when a device, a carrier, or a support process lets them down.

Read the Methodology Browse Experiments
✉️

Contact

Questions, corrections, or experiment contributions

Spotted an error in a finding, have a device you'd like to see tested, or want to contribute data to a queued experiment? Reach out — every message is read, and verifiable corrections are credited in the relevant experiment.

Email

williamdebe06@icloud.com

When you send this form, your message and the email address you give (if any) are emailed to the site owner through Resend, an email service. This site does not keep a copy. Your address is used as the reply-to for the email.

🔬

Testing Methodology

How every experiment is run, recorded, and scoped

Every entry in the TechStack Archive follows the same documentation discipline so that findings stay comparable across experiments and trustworthy over time. An experiment begins with a single, clearly stated question — for example, whether an official Apple screen repair is worth the premium over a third-party shop, or how much BLE identity data AirDrop leaks in a crowded transit hub — and a defined scope that records exactly which device, software build, location, and time window were tested. Scope is published up front because a result only means what its scope allows it to mean; an n=1 test rig in one location describes what happened there, not a universal guarantee.

Data is captured with the tools appropriate to the question: vendor repair invoices and timed shipping logs for service experiments, controlled battery drain runs under a consistent workload for endurance tests, and dedicated capture hardware such as a Nordic nRF52840 development kit running custom Wireshark and Kismet firmware for Bluetooth Low Energy advertisement analysis. Wherever a metric can be measured directly, it is; wherever it cannot, the source is cited and the limitation is named. Each experiment records its raw inputs, the metrics that were logged, and the exact conditions under which they were logged, so a reader can judge whether the setup matches their own.

Findings are separated from conclusions. Findings report what was observed — the costs, the timelines, the frames per minute, the unsolicited connection prompts — and conclusions interpret what those observations mean for a real user. Both are written plainly, and known gaps are called out explicitly rather than buried. When a question cannot be answered firsthand without crossing an ethical line, such as performing an actual SIM swap or running a phishing simulation, it is marked as not independently testable and left to documented research instead of guessed at. When a queued experiment's hypotheses are later superseded by hands-on testing, the original entry is updated to point to the new results rather than silently rewritten.

Finally, every experiment carries a status — Done, In Progress, Pending, or Paused — and queued research is tracked openly with its background sources and planned test steps published before any hands-on work begins. This keeps the archive honest: visitors can see what has been tested, what is still being tested, and what has been set aside, and they can weigh each finding against the scope and limits that produced it rather than treating any single result as a universal rule.

Browse Experiments About the Archive
👤

Contributor Profile

WDIII Community Identity & Role Credential

Loading profile information...
📱

Hardware Registry

Authoritative specifications, testing footprints, and empirical data for all devices in the WDIII archive

WDIII Empirical Hardware Database
WDIII Hardware Technical Specifications
WDIII Official Research Protocol Report
WDIII Hardware Specification & Benchmark Shootout