Monday, September 11, 2023. Around 7:40 in the morning. I was standing in our receiving bay watching a pallet jack drop off 40 cartons, each stamped with a Snapdragon logo. The plan was to replace our field techs' aging devices. The pricing was $89 lower per unit than the alternative I'd been considering, and the total saving of roughly $3,500 felt like a win on paper.
By that Friday, nine of those phones were back on my desk with the same sticky note: charging ridiculously slowly. By mid-October I'd burned about $2,300 worth of chargers and had to explain to our ops director why the field team was going offline mid-shift right before the holiday schedule.
The phones weren't the problem. Neither was the silicon inside them. The problem was me, and a habit I keep seeing in other people too: we validate the hardware, but not the ecosystem around the hardware.
Quick context on who's writing this
I coordinate device and accessory procurement for a field service contractor — roughly 140 devices spread across mobile technicians, dispatchers, and back office. I've been in this role since 2019. Over that time I've personally made four significant, documented mistakes worth somewhere around $28,000 in wasted budget. These days I maintain our team's pre-purchase checklist, mostly so nobody else repeats my errors.
This story is the most embarrassing of the four, and the one I bring up most often in new-hire training.
Why Qualcomm Snapdragon phones in the first place
The 40 devices were a like-for-like replacement. The old handsets were three and a half years old, batteries wouldn't survive a shift anymore, and our carrier was sunsetting 3G — yes, we dragged that one out longer than we should have.
The choice landed on Qualcomm Snapdragon phones for three fairly boring reasons: battery life held up well enough, the modem performance was stronger in the low-signal pockets our techs work in (basement car parks, rural cell sites), and the pricing fit the budget envelope.
What I didn't appreciate at the time was how broad Qualcomm Inc. actually is as a business. My mental model in 2023 was basically "the phone chip company." In reality the portfolio runs through modems, RF front-end, automotive platforms, IoT silicon, Wi-Fi and Bluetooth, and AI accelerators for data center and edge. That gap in my own understanding showed up later in a completely different procurement.
My first phone order went fine. My first charger order did not.
The handsets worked. What broke was the 240 third-party 65W chargers I tacked onto the same purchase order.
My reasoning at the time was roughly: fast charging is fast charging, watts are watts, and the third-party units were somewhere around 15 to 20 percent cheaper. That was the whole analysis. I remember feeling mildly clever about it.
That's the surface illusion in this whole mess — from the outside, 65W is 65W. The reality is that a phone negotiates charging speed with whatever charger it's plugged into, and it can only negotiate the protocols it actually supports. I had assumed that was a solved, universal thing. It isn't.
So — what is Quick Charge, actually?
I had to go look this up in October 2023, which tells you how shallow my original reasoning was.
Short version: Quick Charge is a proprietary fast-charging protocol developed by Qualcomm. USB Power Delivery (USB PD) is a separate, more open standard maintained by the USB Implementers Forum. Plenty of modern devices support both, but a charger that only speaks one of them will fall back to a slow trickle against a phone that expects the other.
I'm not going to pretend I'm the right person to quote wattage numbers on this. If I remember correctly, early USB PD capped around 100W and the 3.1 revision pushed that higher, but don't quote me on any of those figures — the point that actually cost me money is simpler. Fast charging is a protocol handshake, not a physical plug spec. Watts printed on a box tell you almost nothing about what a specific phone will actually do with that brick.
Roughly $2,300 of chargers went into the e-waste bin. Prices there are based on our September 2023 supplier quotes; verify current rates before you buy anything.
Mistake two: the Windows chip decision
January 2024. Our admin team needed new laptops — tight budget, battery life as the top priority. We ran a proper comparison and spent real time on machines built around Qualcomm Windows chip platforms, reading spec sheets and reviews going back a year.
Battery life looked genuinely good. Fanless design was popular with the people taking meeting notes all day. We ordered 12 units.
Then the issues started.
Two of our internal tools were x86-only: an inventory barcode labeling application and a legacy VPN client. On paper, emulation handles most of that. In practice, the labeling app ran but felt slow enough that people started avoiding it. The VPN client simply wouldn't launch — it relies on a kernel-level driver, and that's not something an emulation layer can paper over.
We ended up returning 3 of the 12 laptops and buying x86 replacements. Just under $3,900 in duplicate spend, plus about two weeks of workarounds and IT time.
I want to be fair to the hardware here. The chip did what it was supposed to do. The failure was in how I validated it — we tested in a clean lab environment, not in the messy daily reality of the admin team's workflow.
And honestly, the money was the smaller part. The third rejection in February stung more than the invoice did.
Gut versus spreadsheet, and I ignored the gut
During the laptop selection, our procurement model said go with the Qualcomm-based platform — roughly $210 saved per unit over a three-year horizon. Every cost analysis pointed the same direction.
My gut said buy three first and wait a month.
I didn't listen. Part of that was ego: after the charger situation, I needed a clean win I could write up in the weekly update with a number attached. Playing it safe with a three-unit pilot felt like admitting I didn't trust the analysis.
The projected per-unit saving turned out to be smaller than the cost of one avoidable buy-back. Put another way: the spreadsheet was right about the price and wrong about the workflow.
What changed: the checklist we run now
The real issue wasn't either individual decision. It was that our validation process was almost entirely paper-based. So we built a six-item check that any purchase over $5,000 or over 10 units has to clear.
- Test on real devices, in real conditions. Not spec sheets, not a lab bench — the actual hardware, actual peripherals, actual location.
- Test the ugliest part of the workflow first. Not the most common use case. The one nobody wants to maintain.
- Buy small first. Three units, three weeks. It's a fraction of the cost of a rollback.
- Ask what protocol the accessories speak. Chargers, docks, dongles. These are not a footnote in a deployment budget.
- Write down what we don't know. A "known gaps" field in the purchase doc is more useful than a page of assumptions.
- Get sign-off from whoever has to use the thing. Not their manager. The person holding it at 6pm on a Friday.
Here's the part that surprised me: the checklist didn't make us slower. Our average time from request to fully accepted order dropped from about 5 days down to 2, mostly because the back-and-forth clarification emails largely disappeared. That efficiency gain is real, but it comes from catching problems early, not from moving faster.
One caveat, and I don't have hard data on this — I can't tell you a clean number on how much the checklist reduced our rework rate. Anecdotally, we've flagged maybe a dozen potential problems in the last year or so, mostly accessory compatibility, a few software ones. That's a small sample and I'm not going to dress it up as proof.
The one thing I'd pass on
The hardware itself is rarely the problem. The problem lives in the ring around it — the accessories, the drivers, the protocols, the workflows you assumed were universal and never were.
Both the Snapdragon phones and the Windows-on-Qualcomm laptops are still in our fleet today, and the people using them are generally happy. That part worked out. What I'd fix, if I could, is the two weeks I spent assuming instead of checking.
Breaking things is not a bragging right. Documenting what broke, so the next person skips that step, actually is worth something.
