01 /Overview.
Solar decisions mix physical constraints, price assumptions, and financial projections. A dashboard can become a spreadsheet wearing neon if those layers are not staged deliberately.
Why it matters. People making a solar decision need to understand which outputs come from the site, which come from assumptions, and which are scenarios. The interface should make that chain inspectable.
Workflow. The product moves from site context to recommended system scale, scenario economics, and longer-term potential while keeping assumptions visible.
Outcome. A product surface that makes rooftop potential, solar scenarios, and financial assumptions easier to inspect in sequence.
02 /My contribution.
I contributed the interface direction and product experience: the sequence from site context to recommendation, scenario exploration, and financial framing.
Collaborators and attribution. Nivedana: architecture and full-stack development. Ayush Roy: interface direction and product experience.
Constraints.
- Rooftop geometry and financial assumptions are coupled.
- Scenario values are illustrative and must not read as investment advice.
- Team attribution has to remain explicit at the product boundary.
03 /System architecture.
04 /Technical implementation.
Primary technologies. Next.js · TypeScript · Three.js · Recharts · Motion
- The experience connects site context, rooftop/solar visualization, and scenario controls.
- Financial framing is shown as an assumption-bound scenario rather than a guaranteed return.
- The interface stages technical and financial density so a user can understand the decision path.
Hardest engineering problem. The project needs a sequence through geometry, recommendation, and economics. Flattening those layers into one dashboard would hide assumptions and make the experience look more certain than the model is.
Make scenarios legible
Controls change bounded illustrative roof and solar states rather than implying a live engineering simulation.
Stage information density
The experience moves from recommendation to financial detail instead of presenting every number at once.
Preserve team attribution
The case study names Ayush's interface/product contribution and retains repository credit for architecture and development.
05 /Testing and validation.
- Repository evidence supports the interface and scenario experience; this case study does not claim a production calculation audit.
- The next validation surface is the domain model: tariff assumptions, cash-flow equations, and multi-site boundaries.
06 /Results and evidence.
Repository-described experimental project. The hosted URL was reachable during the portfolio audit; production readiness, installer operations, and investment suitability are not claimed.
- Rooftop potential, scenario economics, and longer-term framing share one navigable product experience.
- Contribution boundaries remain visible instead of collapsing team work into a single-owner claim.
- Decision model
- Scenario-basedIllustrative values with visible assumptions
- Ownership
- SharedInterface direction separated from architecture/full-stack credit
See the system.
These visuals come from the project repository. They explain the product surface and the engineering path; they are not a substitute for deployment or field evidence.
Interactive system view.
Baseline illustrative roof scenario selected. Values remain assumption-bound.
The shared machine world follows this project. This panel remains complete without graphics.
07 /Limitations.
- Experimental project; outputs are not investment advice.
- Portfolio roof interaction and financial values are illustrative.
- No claim of guaranteed subsidies, physical survey accuracy, installer operations, or production readiness.
08 /What I would build next.
Separate the domain calculations from the scene, then add tests for tariff assumptions, cash-flow equations, and multi-site scenario boundaries.
- Complex interfaces need a sequence, not just more widgets.
- Good attribution is part of engineering credibility.