Lectronz's post "How Europe is killing makers and micro-entrepreneurs" hit Hacker News in August 2026 with over 1,000 upvotes and 637 comments — a signal that this resonates far beyond the niche electronics maker community that Lectronz serves. The piece documents, with uncomfortable specificity, how stacking EU regulations have made it economically irrational for small makers to sell physical products in Europe. The sharpest thing to understand from the outset: the regulatory machinery described is not limited to hardware — the EU's Cyber Resilience Act, updated Product Liability Directive, and AI Act are explicitly extending the same compliance logic to software, firmware, and AI-powered products, just with a slightly longer runway. Reading this as someone else's problem is the most common mistake small teams are making right now.
What Is This Actually?
Lectronz is a niche marketplace — think Etsy, but specifically for electronics makers, open-source hardware creators, and hobbyists selling small runs of custom PCBs, sensor modules, microcontroller boards, and similar products. The community it serves builds and sells things like custom MIDI controllers, amateur radio modules, environmental sensors, and LED driver boards. Most sellers on Lectronz and its competitor Tindie operate at what you'd honestly call hobbyist scale — dozens to a few hundred units, thin margins, usually a side project or genuinely small business.
What the Lectronz piece documents is not one regulation. It's a compound effect. Several EU regulatory requirements have converged to make selling even a simple electronics product legally and financially untenable for micro-scale operators.
CE Marking and type examination. Any electronic product sold in the EU must carry a CE mark, certifying conformity with relevant EU directives covering electrical safety, electromagnetic compatibility, and hazardous substances. For products without radio components, self-declaration is sometimes possible. Add Bluetooth, WiFi, Zigbee, LoRa, or any other wireless interface, and the Radio Equipment Directive (RED) kicks in — requiring third-party certification from a notified body. Certification costs run from roughly €3,000 at the low end to €50,000 for more complex product categories. For a maker selling 50 units of a custom wireless sensor at €25 each, that math resolves clearly and badly.
The Cyber Resilience Act (CRA). Passed in late 2024, the CRA began phasing in requirements through 2025 and 2026, with full enforcement by December 2027. It requires manufacturers of any "product with digital elements" — including firmware, embedded software, and connected devices — to maintain documented security processes, publish a software bill of materials (SBOM), provide security updates throughout the product's expected lifetime, and in some cases submit to third-party conformity assessment. For commercial software companies with security teams, this is an operational burden. For a solo maker who sells 200 units of a custom IoT sensor over one year and then iterates to the next design, it's effectively an exit barrier.
Updated Product Liability Directive. The 2024 revision explicitly extended EU product liability to software and digital products. If your product causes harm to an EU consumer — or if someone claims it did — you face liability with the legal standing of a proper manufacturing company. Small makers typically operate without a legal entity, without product liability insurance, and without the legal budget to defend a claim. The new directive strips away the fiction that software occupies a different legal category from physical goods.
WEEE registration (Waste Electrical and Electronic Equipment). Selling electronics in the EU requires registration with national WEEE schemes wherever you sell. Each EU country operates its own registration system with annual fees and reporting requirements. Selling into five EU markets means navigating five separate bureaucratic processes. The burden is largely flat regardless of your sales volume — another cost structure that scales inversely with small business economics.
VAT compliance under the IOSS system. The EU's 2021 VAT reforms required sellers of goods under €150 to charge and remit local VAT at the point of sale. The Import One Stop Shop (IOSS) was designed to simplify this, but it still requires registration and monthly filings. For a maker doing ten EU sales per month across different countries, the accounting overhead is genuinely disproportionate to the transaction volume.
Each of these regulations has a legitimate rationale. CE marking prevents dangerous consumer electronics from reaching EU homes. CRA addresses real security risks in connected devices. Product liability protects consumers. The compounding problem is that every one of these was designed by, and essentially for, organizations that have compliance departments, legal teams, and revenue bases to absorb flat fees. For a solo maker or micro-entrepreneur, the cumulative effect is market exclusion rather than consumer protection.
Why This Matters Right Now
CE marking has existed for decades, and Tindie has operated as a maker marketplace since 2012. The hardware maker regulatory problem is not new in its components. What changed is the density of new requirements arriving simultaneously, the explicit extension of the compliance logic to software and digital products, and crucially, the enforcement timeline reaching its final stretch.
Twelve months ago, a SaaS founder or digital product seller could observe the hardware maker situation with sympathy and relative detachment. That's no longer a tenable position.
The CRA's definition of "product with digital elements" is broad enough to encompass connected apps, IoT-adjacent software, developer tools with network functionality, and potentially SaaS products delivered with client-side components. The EU has made concessions for open-source software — truly free, non-commercial open-source has a partial exemption — but commercial open-source and paid SaaS tools are not clearly exempt. Enforcement guidance from the Commission is still being published as of mid-2026. Legal interpretation is live, not settled.
The EU AI Act began applying its most consequential provisions in August 2025 and August 2026. Any product incorporating AI features and sold to EU customers now has a risk classification obligation, and "limited risk" systems require transparency disclosures at minimum. High-risk AI applications — tools affecting hiring decisions, credit decisions, legal document processing, safety functions — require conformity assessments structurally similar to the CE marking process.
The Product Liability Directive is being transposed into member state law through 2026. Its practical effect is that a defect in your SaaS or app that causes harm to an EU consumer can now generate a product liability claim, not just a breach of contract claim. That's a genuinely new legal risk category for digital product companies.
What's happening to hardware makers is the opening chapter of a longer regulatory story. The structural issue — compliance costs that operate as a flat tax rather than proportionally to revenue — is identical across physical and digital products. Small operators pay the same absolute compliance cost as large ones, which means they pay it as a much larger percentage of their economics.
Practical Implications for Small Teams
Scenario 1: A solo founder selling a developer tool or CLI app into Europe.
If the tool includes any network connectivity or runs on the customer's machine rather than entirely on your servers, you're potentially within CRA scope as a "product with digital elements." The legal boundary between SaaS (probably out of CRA scope, addressed by other frameworks like NIS2) and software-as-product (firmly in CRA scope) is real but not crisp for hybrid architectures. A desktop app with a backend API component sits in genuinely ambiguous territory. Until the Commission publishes clearer guidance, small operators selling software to EU customers need to at minimum track the guidance being published and understand their exposure — not assume they're exempt because they haven't heard otherwise.
Scenario 2: A three-person agency building IoT dashboards or hardware-adjacent tools.
This team is potentially in simultaneous scope for the CRA, the Product Liability Directive, and if their tools incorporate AI features, the AI Act. If they're building connected hardware prototypes that clients then sell commercially in the EU, they're operating in exactly the space Lectronz describes. The agency itself may not sell the end product — but if their work product ends up in a product placed on the EU market, understanding the compliance obligations is part of responsible client service. Getting this wrong could expose clients to liability that traces back to the agency's deliverables.
Scenario 3: A freelance maker selling on Tindie or Lectronz from outside the EU.
Non-EU sellers are not exempt from EU regulations when selling to EU customers. CE marking, WEEE, and VAT requirements apply based on where the customer is, not where the seller is located. A maker in Canada, Australia, or the US selling custom electronics to EU buyers via Tindie or Etsy faces the same compliance stack as a maker in Germany. Most simply stop shipping to EU addresses — which is exactly the market fragmentation Lectronz is documenting. EU customers lose access to small-maker products; the market defaults toward large manufacturers and non-compliant Asian imports that enforcement agencies don't effectively reach.
Scenario 4: A SaaS team using a Merchant of Record to handle EU VAT.
This is the right call for digital products, and teams that haven't done it should. But it's important to understand what a merchant of record actually solves and what it doesn't. Using Paddle or Lemon Squeezy transfers EU VAT collection, remittance, and related tax compliance to the MoR. That handles one regulatory layer. It does not address CRA conformity obligations, Product Liability Directive exposure, or AI Act requirements — those attach to the product itself, not the payment relationship. Teams that treat "VAT handled" as equivalent to "EU compliance handled" are carrying risk they haven't named.
Scenario 5: A small manufacturer considering EU market entry for a new connected product.
The honest analysis: unless you can absorb €10,000–€50,000 in compliance costs before your first sale, and have operational capacity for ongoing security update obligations, WEEE filings in each target market, and liability management, the EU market is not economically accessible at micro-scale. Lectronz makes this case with enough specificity to warrant taking it seriously. The path that sometimes works is finding a EU-based distributor or importer who takes on compliance obligations — but that party will take margin, often making small-run products unviable anyway.
How to Respond and Act on This
For digital product and SaaS teams selling to EU customers:
Start with a CRA audit. Map out whether your product includes any client-side software component, downloadable element, firmware, or network-connected functionality. Pure SaaS running entirely on your servers probably falls outside strict CRA scope (addressed by NIS2 and related frameworks instead), but anything with a client-side agent, browser extension, desktop app, or embedded component needs a closer look. For products within CRA scope, the default category requirements include: a documented software bill of materials (SBOM), a public vulnerability disclosure policy, and a committed security update timeline. None of these are prohibitively hard — an SBOM can be generated with existing tooling; a vulnerability disclosure policy is a page on your website — but they require deliberate implementation, not assumption.
Second, review your Product Liability Directive exposure. The directive passed in 2024 and is being implemented across member states through 2026. Your existing terms of service likely contain liability disclaimers written under the old legal regime, many of which are not enforceable against EU consumers under the new framework. Get legal eyes on your ToS if you're selling to EU consumers, particularly if your product touches any consequential decision-making.
Third, map your AI Act risk tier now. The EU has published risk classification guidance, and most business productivity tools fall into limited-risk or minimal-risk categories with lighter requirements — mainly transparency disclosures informing users they're interacting with an AI system. Tools that make or influence consequential decisions about people — credit, employment, medical, legal, education — are in high-risk territory with conformity assessment requirements. Know your classification before enforcement does it for you.
Fourth, if you haven't already, implement a Merchant of Record for EU VAT. Lemon Squeezy and Paddle both operate as full MoR, handling EU VAT, digital services tax, and local tax requirements across EU member states. This is table stakes for any digital product team selling to EU customers. The transaction fee is real cost, but so is the alternative: registering for VAT in each EU market you sell into, filing monthly, and managing currency and rate differences. The MoR model is the right trade.
For hardware makers and physical product teams:
Be honest about the math. If your annual unit volume doesn't generate revenue to cover certification, WEEE registration, ongoing security update obligations, and liability exposure — and for most micro-makers, it won't — the EU market may not be viable without a compliance partner. Following the Free Software Foundation Europe (FSFE), Open Forum Europe, and the Open Source Hardware Association's ongoing CRA advocacy is worthwhile; exemption wins are possible, as demonstrated by the partial open-source exemption already negotiated into the CRA.
Regulatory tracking as infrastructure. EU regulations shift constantly, and the guidance being published through late 2026 and 2027 on CRA implementation is genuinely consequential. Treating EU regulatory tracking as an optional research task is no longer appropriate if you're selling into Europe. Subscribe to a reliable source — the Digital SME Alliance, FSFE's newsletter, or a legal/compliance service that covers EU digital law.
Platforms and Alternatives: Where Makers and Small Teams Can Still Sell
| Platform | Best For | Free Listing | Starting Cost | Key Differentiator |
|---|---|---|---|---|
| Lectronz | Open-source hardware, EU-aware makers | Yes | ~5% per transaction | Community-focused, explicit compliance awareness for makers |
| Tindie | Electronics makers globally | Yes | ~5–7% per transaction | Largest maker marketplace by volume, acquired by Supplyframe |
| Crowd Supply | Open hardware with crowdfunding model | Project-based | ~5% + crowdfunding fees | Handles some logistics for funded campaigns |
| Etsy | Handmade/creative physical goods | Yes | ~6.5% transaction + listing fee | Broad audience, no compliance guidance |
| Lemon Squeezy | Digital products, SaaS, subscriptions | Yes (10% tier) | ~5% + $0.50/transaction | Full EU VAT MoR, built specifically for digital products |
| Paddle | SaaS, subscription software | No | ~5% + $0.50/transaction | MoR with tax handling, stronger subscription management |
| Gumroad | Simple digital products | Yes | Free (10% fee) to ~$10/mo (lower fee) | Low friction, lighter MoR coverage for EU VAT |
For teams selling digital products, the platform compliance implications are significant. Lemon Squeezy and Paddle handle EU VAT as merchant of record — that's a genuine regulatory advantage, not just a payment feature. Lectronz is specifically building community infrastructure around EU regulatory navigation for hardware makers. For hardware, no equivalent all-in-one compliance solution exists at small-maker scale, which is the structural gap the Lectronz post is diagnosing.
What the HN Community Is Saying
The discussion broke into several recognizable camps, each with legitimate points that deserve examination rather than dismissal.
The consumer protection advocates acknowledged the legitimacy of CE marking, EMC requirements, and CRA's security goals while accepting the maker community's argument that the cost structure is the problem, not the intent. One well-upvoted thread noted that small-scale electronics without proper EMC certification can genuinely cause radio interference with critical infrastructure — a real concern, not bureaucratic theater. The counter from makers is not that they should be exempt from safety standards, but that compliance cost should scale with business size, the way taxation scales with income, rather than operating as a flat fee that represents 2% of a large manufacturer's product cost and 300% of a small maker's revenue.
The practitioners shared specifics that are hard to dismiss. One HN commenter described paying €8,000 for RED certification on a product they ultimately sold 150 units of — the certification cost exceeded total product revenue. Another described the WEEE registration process in Germany as a multi-month bureaucratic exercise with ongoing quarterly reporting requirements, all for a product generating €2,000 in annual sales. These aren't edge cases used to make a rhetorical point; they're documented, lived friction.
The most analytically interesting thread centered on the asymmetry of enforcement. Several practitioners pointed out that Chinese manufacturers — Shenzhen-scale operators shipping non-certified electronics directly to EU consumers — are largely unaffected by EU regulations because customs enforcement against individual small parcels is weak and inconsistent. Meanwhile, EU-based small makers face full regulatory exposure. The regulation is systematically disadvantaging the producers that are most visible, most local, most transparent, and most aligned with EU industrial values, while the competitive pressure from non-compliant imported goods continues unimpeded.
A minority pushed back on the Lectronz framing, noting that the company has a commercial interest in lighter regulation for small makers — more compliant sellers means more listings, more sales. That's accurate. It doesn't, however, invalidate the underlying regulatory analysis, which is grounded in actual directive text and documented compliance costs.
Risks and Things to Watch
The enforcement gap problem is self-defeating. EU regulations are increasingly real on paper but inconsistently enforced against non-EU sellers. This creates a perverse market dynamic: EU-based compliant small makers bear full costs and get pushed out, while competitors from outside the EU shipping non-compliant products face minimal consequences. The regulation achieves market exclusion of legitimate small operators without actually achieving the consumer protection objectives it was designed to serve. Over time, this incentivizes moving small-scale production outside the EU entirely.
CRA scope drift. The CRA's definition of "product with digital elements" remains broadly written, and enforcement guidance from the European Commission is still being published. Software teams operating on the assumption that they're clearly out of scope because they're "just SaaS" should verify that assumption against the actual guidance as it develops through late 2026 and 2027. The risk is assuming you're exempt, not preparing, and then facing sudden compliance demands when enforcement begins in earnest. Emergency compliance is always more expensive than planned compliance.
AI Act risk misclassification. Our read is that many small teams significantly underestimate which AI Act risk tier their product occupies. The instinct is to classify your own tool as minimal-risk. But tools that touch hiring screening, legal document analysis, credit decisions, or any safety-relevant function are in high-risk territory regardless of how the developer characterizes their intent. The EU's risk classification is based on use case, not the developer's self-assessment. Misclassification is a real exposure.
Merchant of Record false security. Using Paddle or Lemon Squeezy is the correct move for EU VAT compliance on digital products. It is not a compliance solution for the CRA, the Product Liability Directive, or the AI Act. These frameworks address entirely different questions about product safety and liability, not tax collection. Teams that conflate the two are carrying hidden regulatory risk that won't surface until something goes wrong.
Open-source exemption uncertainty. The CRA's open-source exemption for non-commercial software is narrow and still being interpreted. Commercial open-source — any project that accepts payment, has commercial sponsorship, or whose developers derive revenue from the project — is likely not fully exempt. The commercial/non-commercial boundary is undefined in enough implementation guidance to create real legal uncertainty for projects operating in the grey zone between community project and small business.
Framework interactions. A security incident that triggers CRA disclosure requirements may simultaneously trigger GDPR breach notification obligations. The frameworks don't formally coordinate, which means a single event can activate multiple parallel compliance processes. Small teams without documented incident response plans are particularly exposed. The regulations interact in ways that can compound administrative and legal burden unexpectedly.
Frequently Asked Questions
Does the EU Cyber Resilience Act apply to SaaS products?
The CRA primarily targets products with digital elements placed on the market — most cleanly, software sold as a product: apps, firmware, embedded software, standalone tools. Pure SaaS, where software runs on the provider's infrastructure and isn't transferred to the customer, likely falls under the Network and Information Security Directive (NIS2) and related frameworks rather than the CRA directly. The complication is hybrid architectures — SaaS with client-side agents, downloadable components, desktop apps, browser extensions. These are likely in CRA scope. The legal boundary is not crisp, and enforcement guidance is still being published through 2026. If you're in this space, tracking official Commission guidance is not optional.
Can I sell electronics to EU customers from outside the EU without CE marking?
Technically, no — if you're selling to EU consumers, CE marking requirements apply regardless of your location. In practice, enforcement against small-volume non-EU sellers is inconsistent, and many simply sell without compliance. But this exposes customers to unverified products and exposes sellers to liability if something goes wrong. Platforms like Lectronz and Tindie don't verify CE compliance on listings. The practical enforcement risk has historically been lower for small non-EU sellers than for EU-based ones, but EU customs enforcement capacity is increasing. Selling without compliance is a calculated risk, not a legal exemption.
What is Lectronz, and why are they writing about EU regulation?
Lectronz is a marketplace for electronics makers and open-source hardware creators — a more community-focused alternative to Tindie, with stronger focus on the European maker ecosystem. They have a direct commercial interest in lighter regulation for small makers: easier compliance means more sellers, more sales, more platform revenue. That interest doesn't make their analysis of specific regulations and compliance costs inaccurate. The regulatory text they're describing is real; the cost figures they're citing are consistent with what practitioners are documenting in community discussions.
What is the open-source exemption in the Cyber Resilience Act?
During CRA negotiations, advocacy from organizations including the FSFE and OSI secured a partial exemption for open-source software developed and distributed on a genuinely non-commercial basis. The exemption covers software where no commercial transaction is involved — freely distributed code with no payment, no paid support model, no commercial sponsorship arrangement that benefits the developers. Commercial open-source — software that is open-source but sold, used by a revenue-generating company, or where developers receive commercial compensation — does not receive the full exemption. The non-commercial boundary is still being defined in implementation guidance, creating genuine uncertainty for projects that sit between community project and small business.
How does the updated Product Liability Directive affect software developers?
Before the 2024 revision, software was typically treated differently from physical products in EU product liability law — defective physical goods carried strict manufacturer liability, while defective software typically generated contract-based claims. The revised directive explicitly includes software and digital services. A defect in your software that causes demonstrable harm to an EU consumer can now generate a product liability claim under the same framework as a manufacturer facing a product recall. The harm must be real and causally linked to the defect; every bug doesn't create liability. But the legal risk category for software sold to EU consumers has materially changed, and terms of service written under the old regime are not reliable protection.
Is there any realistic way for small makers to sell electronics in the EU without full compliance costs?
Some makers work through EU-based distributors or importers who absorb compliance obligations — but the distributor takes margin, often making small-run products uneconomical at the selling price the market will support. Some makers sell as component kits (unassembled parts) rather than finished products, which can change the regulatory category in some cases. Some categorize products as "for educational use only" — but this doesn't reliably create a regulatory exemption and can create liability problems if customers use products in other contexts. For most makers at genuine micro-scale, the honest answer is that the EU market economics don't work without a compliance partner willing to operate at below-market rates for community reasons.
What is the best merchant of record for a small SaaS team selling to EU customers?
For most early-stage SaaS teams, Lemon Squeezy is the simpler and lower-overhead choice — it handles EU VAT as a full MoR and is popular with indie makers and solo founders. Paddle is more feature-complete for subscription management, better for growth-stage products, and has stronger enterprise support. Both charge approximately 5% plus a per-transaction fee, which is meaningful at scale but reasonable for the compliance infrastructure they provide. Gumroad handles simpler digital products and has a free tier (at 10% fees), but its MoR EU VAT coverage is less comprehensive than Paddle or Lemon Squeezy. For hardware, no equivalent all-in-one solution exists, which is precisely the structural gap the Lectronz post is describing.
Should small teams lobby for regulatory reform or just adapt?
Both, pragmatically and in parallel. Adapting is necessary now — the regulations exist and will be enforced regardless of whether they're proportionate. But the underlying policy design flaw — compliance costs that scale as flat fees rather than proportionally to business size — is a legitimate structural problem worth pushing back on through organized channels. The Digital SME Alliance, FSFE, OSI, and national small business chambers have demonstrable track records of achieving exemptions and amendments. The CRA open-source exemption itself was won through this kind of organized advocacy. Individual voices don't move EU regulatory policy; collective voices through existing organizations sometimes do.
The Verdict
The Lectronz piece is doing something valuable: putting specific numbers on a problem that policy discussions prefer to treat abstractly. When a RED certification costs €3,000–€50,000 and a typical small maker sells 100–300 units annually, the economics aren't close. One HN commenter documented paying €8,000 for certification on a product that generated less than €4,000 in total sales. At those ratios, the question isn't whether small makers will comply — it's whether small makers will exist in the EU market at all.
For Opsvoro's audience — small teams, solo founders, agencies, digital product builders — the hardware maker situation is both directly relevant and a meaningful signal of what's coming. Directly relevant because if you sell software, digital products, or AI-powered tools to EU customers, you're operating in the same regulatory environment. The CRA, the Product Liability Directive, and the AI Act are live or entering full enforcement between 2026 and 2027. The compliance costs for digital products are lower than for hardware — no radio certification, no WEEE registration — but they're not zero, and they're growing with each new directive.
As a signal, what's happening to hardware makers is the earlier-running preview of where EU digital regulation is heading. Each new directive follows the same pattern: legitimate consumer protection goals, enterprise-scale compliance architecture, and cost structures that are trivial for large companies and existential for small ones. The EU is, functionally, treating a three-person SaaS team the same as SAP. That's not proportionate policy.
Our view is that small teams selling to EU customers should treat EU regulatory compliance as a genuine operating cost and a strategic planning variable, not a peripheral concern. For digital products: get a merchant of record in place for VAT if you haven't already, track CRA guidance actively for any product with client-side components, and map your AI Act risk tier before enforcement does it for you. For hardware: be honest about whether the economics of EU compliance actually work for your product and volume. If they don't, the responsible move is to acknowledge it rather than defer the reckoning.
The makers being pushed out of EU markets are part of the innovation substrate that European industrial policy claims to want to cultivate. A regulatory regime that prices out micro-entrepreneurs while large manufacturers absorb compliance costs as a rounding error isn't protecting European consumers. It's concentrating the market. Watch the CRA implementation guidance through late 2026 and early 2027 — the scope decisions still being made there will determine whether the hardware maker exodus Lectronz is documenting becomes the story for small software teams too.