Wattage
Wattage was an online hardware-design platform for creating custom electronics without deep hardware expertise. Its shutdown shows that abstracting a difficult workflow is not enough unless a specific buyer segment already has urgent, paid demand for the underlying job.
View original storyProduct snapshot
What it was
Wattage aimed to let users configure and create custom electronics through an online design workflow.
Who it was for
Problem / value
It promised to make hardware creation accessible to people who did not want to handle electrical design, power routing, manufacturing, and fulfillment themselves.
Core workflow
Users would design or configure a programmable physical product online, while Wattage handled hidden design and production complexity behind the interface.
Core dependency
The model depended on urgent demand for custom electronics, paid project completion, manufacturing reliability, support cost, gross margin, and customer education.
Product form
Pricing model
Public sources describe a plan to sell user-created hardware and later support a marketplace, but do not disclose pricing, take rate, order volume, gross margin, or paid conversion.
Competitors or alternatives
What happened
Summary
Wattage shut down in 2015 after pursuing a technically ambitious custom-electronics platform without enough public evidence of market demand, paid projects, or funding confidence.
Outcome
The company ceased operations before the broader platform or marketplace vision reached durable traction.
Core risk
The product abstracted a hard workflow before proving that a specific buyer segment had urgent, repeated, paid demand for custom electronics projects.
Timeline
- Wattage started as a Toronto startup focused on custom electronics creation.
- BetaKit profiled its product vision in April 2015.
- In May 2015, BetaKit reported that co-founder and CEO Jeremy Bell announced Wattage had shut down.
- Secondary summaries later described the company as failing to validate market interest and secure a crucial seed round.
Before you build
Why it matters
No-code, AI, marketplace, and developer-platform products often win by hiding difficult work. But if customers do not already need the outcome badly enough, the abstraction itself becomes a demo rather than a business.
Primary check
Before building a no-code platform, AI tool, or marketplace that abstracts a complex workflow, validate who urgently needs the outcome, what they will pay, and whether real projects can be completed repeatedly before investing in a polished interface.
Checklist
- Sell a manual custom project before building the full builder.
- Track project completion and support time, not only signups.
- Measure willingness to pay for one narrow device category.
- Run small-batch fulfillment tests with real customers.
- Test whether customer education cost falls after repeated sales conversations.
- Who has an urgent custom-electronics job today?
- Will they pay before the interface is fully automated?
- Can real projects be completed repeatedly with acceptable support time?
- Does fulfillment still work after quality issues, returns, and delivery delays?
- Is there one narrow use case strong enough before building a general platform?
Relevant if
- You are building a no-code builder, AI creation tool, developer platform, hardware workflow, or marketplace that makes hard work look simple.
- Your product needs customers to understand a new category before they can buy.
- The interface is easier to validate than the full delivery, support, or fulfillment path.
Less relevant if
- Your buyers already complete the workflow frequently and pay for existing alternatives.
- The product is pure software with no hidden delivery, support, or manufacturing burden.
Pre-build tests
- Concierge custom-electronics pilot
- Paid preorder for one narrow hardware category
- Manual quote-to-delivery workflow
- Small-batch manufacturing and support test
Transferable lessons
- Start with a narrow repeated job, not a broad platform promise.
- Validate paid project completion before polishing the abstraction layer.
- Measure education cost when the product creates a new category.
- Do not use technical feasibility as a substitute for willingness-to-pay proof.
- If physical fulfillment is involved, validate quality, support, delivery, and margin early.