Bricked Hardware and Missing Git Tags: Why Software Ownership Matters

The short answer

The risk of cloud-dependent hardware is simple: a company you do not control can switch off something you paid for, and there is nothing in your warranty that stops them. Two recent stories make this concrete. Cricut has a long history of remotely deactivating secondhand cutting machines, turning working hardware into e-waste.¹² And Google has started replacing routine Git tag pushes for Android source with a manual Google Forms and Google Drive process, breaking a workflow that outside developers depended on.³

Neither company did anything illegal. That is the point. When the vendor owns the control plane, they get to decide, and you get to find out.

The Cricut pattern: hardware you bought, control you never had

Cricut cutting machines are physical products. You buy one, it sits on your desk, it has a serial number etched into a board. But every machine phones home to Cricut Design Space before it will cut anything. In 2021 Cricut tried to cap free uploads at 20 designs a month and push everyone toward a $9.99 subscription, and internal communication suggested secondhand machines would simply be bricked.⁴ The backlash was loud enough that Cricut walked the plan back within days.⁴

That walkback did not end the underlying practice. Cricut still deactivates machines tied to warranty replacements, and the deactivation follows the serial number, not the owner.² A researcher who picked up a discarded Cricut Maker from an e-waste pile in mid-2026 found it fully functional mechanically but locked out of the cloud service that makes it work at all.¹ Getting it running again required intercepting USB traffic with a microcontroller and spoofing a different serial number, essentially reverse-engineering a way around a lock the manufacturer built specifically to prevent that.¹ Most owners do not have that skill set. Most owners just throw the machine away, which is exactly what happened before it landed in a bin.

This is not a one-off. Logitech announced it would permanently disable its $100 Pop smart home buttons on October 15, 2025, offering affected owners a 15% discount coupon as a consolation prize.⁵ The devices still work as physical switches. They just stop being useful the moment Logitech turns off the server that gives them meaning.⁵

The Google pattern: even developers who depend on you can get cut off

The Cricut story is a consumer story. The Google story is a developer story, and it matters more because it shows the same dynamic hits sophisticated technical users too.

GrapheneOS, the privacy-focused Android fork, depends on Google pushing signed Git tags for Pixel kernel and driver source so it can build and verify releases. Google quietly stopped doing that for some repositories, and started requiring GrapheneOS to request source through a Google Form and receive tarballs via Google Drive instead.³ GrapheneOS maintainers said Google also began squashing commit history before handing over code, and that requests which used to take a couple of hours now sometimes take weeks.³ They called it a violation of the GPLv2 obligations Google is bound by for that code.³

The technical substance did not change. The process did. And that process change alone was enough to push GrapheneOS toward hosting its own AOSP Git repositories going forward, rather than depending on Google's pipeline at all.³ That is the rational response to a control plane you cannot rely on: stop relying on it.

Why this keeps happening

None of these companies are acting irrationally from their own point of view. A subscription upsell, a support cost reduction, a workflow change buried in a backlog, these are all normal decisions inside a normal company. The problem is structural: when the thing that makes your product work lives on someone else's server, every decision that company makes about that server is now a decision about your product too, and you were never in the room.

I have made this mistake at the team level plenty of times, just with smaller stakes. You wire an internal tool to a vendor API because it is fast to ship. A year later the vendor changes rate limits, deprecates an endpoint, or gets acquired, and suddenly a tool your team depends on daily needs an emergency rewrite. The Cricut and Google stories are the same failure mode at a bigger scale: the dependency was invisible until the day it was not.

What owning the stack actually buys you

Owning software does not mean building everything from scratch. It means the thing you depend on daily does not have a kill switch someone else holds. A cutting machine that works over local USB or Bluetooth without a mandatory cloud check-in cannot be bricked by a pricing decision. A build pipeline that pulls from a repository you host cannot be broken by someone else's support backlog. This is the same argument behind treating internal tools as an asset you own, not rent, the philosophy laid out across Remy's take on software ownership at goremy.ai: the dependency you ignore today is the outage you inherit tomorrow.

That is not an argument against every SaaS product or every cloud dependency. Plenty of vendor relationships are fine, priced fairly, and stable for years. But before you build a workflow, a product, or a team habit around a vendor's server, ask what happens the day that vendor decides the arrangement no longer suits them. If the honest answer is "the thing stops working," you have taken on a risk you may not have priced in.

FAQ

What does it mean for hardware to be cloud dependent? It means the device needs an active connection to a manufacturer's servers to function, even for features that do not obviously require the internet, like cutting a shape from vinyl.

Can a company legally brick something I already bought? In most cases, yes. Terms of service and the difference between buying a device and licensing the software that runs it give manufacturers wide latitude, which is why Cricut's 2021 plan and Logitech's 2025 shutdown both proceeded largely unchallenged.⁴⁵

Why did Google's Git tag change matter if the source code was still shared? Because access without a reliable process is not real access. Manual requests through forms, multi-week delays, and squashed commit history all made the code functionally harder to use even though nothing was technically withheld.³

Is there a workaround for locked hardware like a bricked Cricut? Sometimes, if you have the technical skill. One hobbyist restored a locked Cricut Maker by intercepting USB traffic and spoofing its serial number, but this required hardware reverse engineering most owners cannot do.¹

How do I avoid this risk in my own team's tools? Ask, before adopting any vendor dependency, what breaks if that vendor changes pricing, support priorities, or shuts down a feature. If the answer is total failure with no fallback, that is a risk worth weighing against the convenience.