Can I use Electrum for a product that is mostly software with a small hardware component?

[yoelf22]

I'm building a home energy monitor. The hardware is minimal — a CT clamp sensor on the mains cable, an ESP32 reading it, and a WiFi connection to a cloud dashboard. 90% of the product value is in the software (analytics, recommendations, utility API integrations).

Is Electrum overkill for this? The system description template seems designed for products with complex mechanical subsystems and multiple firmware domains. Should I skip phases or use a different approach?

[yoelf22]

Not overkill — but you'll use the phases differently.

A CT clamp energy monitor looks simple, but the HW/SW boundary questions are still real. A few that the process would surface:

• Sampling rate vs. accuracy tradeoff: To detect individual appliances (disaggregation), you need high-frequency sampling (kHz range). A basic ESP32 ADC at 12-bit may not cut it — you might need an external ADC. This is a hardware decision driven by a software feature.
• Calibration: CT clamps have nonlinear response curves. Who owns calibration — factory firmware, user setup in the app, or continuous auto-calibration in the cloud? Each answer has different hardware and software implications.
• Safety isolation: The CT clamp is on mains voltage. Even though it's inductively coupled, your product needs to meet safety standards (UL/IEC). This affects PCB layout, enclosure design, and certification cost — things that are easy to overlook when you think of it as "just an ESP32."
• Power: Is the sensor node mains-powered (needs a small PSU, adds safety complexity) or battery-powered (needs low-power firmware, sleep modes, intermittent WiFi)? This single decision reshapes the firmware architecture.

Which phases to focus on

Phase 1 (Explore): Run this fully. It will classify your product as "static electronic" (no moving parts) and map the HW/SW boundary. For your product, the boundary is narrow but high-stakes: the CT clamp interface, the ADC, and the WiFi connection are the only hardware — but each one has software implications.

Phase 2 (High-Level Design): Yes, but your block diagram will be simple — sensor, ADC, MCU, WiFi, cloud. The value here is in naming the three hardest problems. For an energy monitor, they're probably: (1) appliance disaggregation accuracy, (2) zero-configuration setup for non-technical users, (3) reliable long-term operation without physical access.

Phase 3 (Component Arrangement): You can skip this or keep it minimal. A single PCB in a small enclosure doesn't need spatial analysis.

Phase 4 (System Description): Run this, but expect to mark several mechanical subsystem sections as N/A. The firmware and cloud sections will be where you spend your time. The system description template's interface specification section is especially useful — it forces you to define the data pipeline from CT clamp reading to cloud dashboard, including sampling rate, data format, transmission frequency, and error handling at every hop.

Phase 5 (Gate Checklist): Run this. You'll mark many mechanical items N/A, but the electrical safety, connectivity, firmware update, and cloud integration items are directly relevant. Expect 30-40 items to be N/A, 30-35 to be PASS/FAIL, and the FAILs to cluster around safety certification and cloud reliability.

The general principle

Electrum is most useful when the product has a HW/SW boundary that both teams need to understand. Your product has a narrow boundary (CT clamp + ESP32), but the questions at that boundary are high-consequence (safety, accuracy, reliability). The process scales down gracefully — skip phases that don't apply, but don't skip the gate checklist.