08/16/2026
Some of the most interesting web apps we’ve built were the ones I wasn’t entirely convinced anyone would use.
In 2013, a friend came to us with an ambitious idea: make it possible for almost anyone to participate in solar energy, even if they couldn’t install solar panels on their own roof.
This was still early in residential solar adoption. Panels were expensive. Many HOAs restricted them. Plenty of people thought they were ugly. And concepts like renewable energy credits and virtual solar generation weren’t exactly dinner-table conversation.
This idea was different. People could sponsor individual solar cells or panels connected to a real solar installation and participate in the energy those panels produced.
And the vision went further. As the community grew, solar installations could power participating nonprofits and other community organizations. Local businesses could participate too, offering benefits or discounts to people contributing their solar energy credits.
It was an ambitious ecosystem. But first, they needed to know whether people would understand it.
However, there was one big problem. How do you explain something people have never experienced before?
We decided to make it something they could play with.
Our team built a working prototype connected to hardware at an actual pilot solar installation. Production data flowed into a visual dashboard where people could use simple sliders to experiment with the idea.
Choose the number of solar cells. Change the length of time. Add participants. Then watch the energy add up.
We translated the resulting kilowatt-hours into things people could immediately understand: phones, computers, houses, even high-rise buildings.
Behind the friendly interface was real production data. The business model specifically called for virtual panels whose production was tied to the actual output of a reference solar installation.
We weren’t building software to automate an existing process. We were using technology to help people understand and interact with an idea that barely existed yet.
And the prototype did something else: it gave the company a way to test its assumptions with actual people before investing months building the entire platform. Within weeks, they could begin validating whether people understood the concept and whether the value proposition resonated.
I think about projects like this a lot these days. We tend to ask, “What can we build with this technology?”
Perhaps we need to remember to ask, “What do we need to learn before we build anything more?”
A good prototype doesn’t just prove that the technology works. It helps you discover whether the idea does.