Homepage
Marketplace
DashBoard
Transactions
Energy Flow

NeighborWatt

Decentralised Peer-to-Peer Solar Mesh

Tagline: Locally generated. Intelligently managed. Community powered.

Category: Renewable Energy / ClimateTech / Community Energy\ Project type: Academic web application prototype

Prototype status: This report describes the NeighborWatt concept and intended MVP. Treat generation, battery state, forecasting, wallet credits and P2P settlement as simulated unless they have been implemented and tested in the submitted app. Replace screenshot placeholders with genuine screenshots before submission. Do not present illustrative values as measured field results.

Inspiration

Access to reliable and affordable electricity can remain difficult in remote and underserved communities. Extending conventional infrastructure into geographically challenging areas can be expensive, while locally generated renewable energy may not always be used where and when it is needed.

NeighborWatt was inspired by a simple question: What if a household with surplus solar energy could share that surplus with a nearby household that needs it?

The project explores a community-centred approach in which households can act as energy sellers or buyers. A shared marketplace makes offers visible, while a transaction ledger records simulated exchanges. The broader vision combines solar generation, battery energy storage, energy-management logic, demand forecasting and cooperative ownership.

Locally generated. Intelligently managed. Community powered.

NeighborWatt is a prototype and proposed solution---not a claim that electricity is already being physically delivered between households.

What it does

NeighborWatt is a web application concept for a decentralised, community-based renewable-energy marketplace. It has two primary user roles with separate login experiences and workflows.

Buyer portal

The Buyer represents a household that needs additional energy.

Sign in through the dedicated Buyer login.
Browse energy offers published by Sellers.
Compare available quantities and prices per kilowatt-hour.
Select an offer and quantity.
Review the estimated total cost.
Confirm or cancel the purchase.
View demo wallet balance and purchase history.

The simulated purchase cost is:

[ \text{Total Cost}{=tex} = \text{Energy Purchased (kWh)}{=tex} \times{=tex}\text{Price per kWh}{=tex} ]

Seller portal

The Seller represents a household or local producer with potential solar surplus.

Sign in through the dedicated Seller login.
Review simulated generation, household demand and estimated surplus.
Create an offer with an energy quantity and price.
Publish, review, edit or cancel eligible offers.
Track completed sales and demo credits.
Review transaction history.

This estimate is only as reliable as the supplied data. In an academic MVP, values may be simulated and must not be treated as verified physical energy availability.

Shared peer-to-peer marketplace

Buyer and Seller portals use the same marketplace. A published offer should be visible to Buyers, and a successful simulated purchase should update the remaining offer quantity and related transaction records consistently.

A trade should validate offer quantity and demo balance, record a unique transaction, update the remaining quantity and demo account balances, and show the result in both users' histories. If validation fails, no partial update should occur.

The prototype uses demo credits, not real money. It does not itself deliver electricity, connect to utility meters or execute regulated energy settlement.

Energy-system demonstration

The wider concept includes:

Solar PV: locally generated renewable electricity.
BESS: battery energy storage to shift energy availability over time.
EMS: compares generation, demand and reserve requirements.
P2P marketplace: interface for simulated surplus offers and purchases.
Demand forecasting: demonstrates how predicted demand could inform battery scheduling and flexible loads.
USSD concept: feature-phone-friendly menu for users without smartphones.
Community impact: illustrative indicators such as energy traded, participating households and solar utilisation.

How we built it

Product design approach

NeighborWatt is structured around distinct user roles and a shared marketplace. The landing page explains the project, while application routes guide users to the workflow relevant to their role.

The visual direction is premium but restrained: natural energy imagery, editorial typography, readable data visualisations, considered whitespace and purposeful animation. The interface should avoid excessive glow effects, custom cursors and decorative motion that distracts from the product.

Main application areas

Area Purpose

Public landing page Explains the problem, solution and project vision

Buyer portal Browses offers, simulates purchases, and shows wallet/history

Seller portal Estimates surplus and creates or manages listings

Shared marketplace Makes active offers available to Buyers

Transaction service Validates and records simulated trades consistently

Energy simulation Displays illustrative generation, demand and battery state

Forecast demonstration Shows how predicted demand could support scheduling

Impact view Summarises sample metrics and the proposed roadmap

Technology choices

Use this list only if it matches the actual codebase; update it before submission.

Frontend: React and TypeScript, with Next.js or an equivalent React setup.
Styling: Tailwind CSS and reusable components.
Animation: Framer Motion and CSS transitions.
Visualisation: Recharts, SVG or another lightweight charting approach.
Icons: Lucide or a consistent icon set.
State and data: shared application state and service layer for offers, accounts and transactions.
Prototype persistence: browser-local storage, if no backend is configured.
Future backend: secure API, database and server-side transaction handling.

Do not list a tool as used unless it is present in the actual project. For a frontend-only MVP, describe local storage and demo data honestly rather than implying a production backend exists.

Transaction consistency

A successful purchase should update the Buyer's demo balance, Seller's demo credits, offer quantity and transaction history together. If validation fails, none of those values should be partially updated.

In production, this operation should be enforced by a backend using database transactions and suitable concurrency controls. Browser-only state is appropriate for a demonstration, not secure real-world trading.

Challenges we ran into

Representing physical energy in a web application

A marketplace listing cannot prove electricity is available at a particular household or can be delivered through local infrastructure.

Approach: Separate the software workflow from physical electricity delivery. Use illustrative values and make the simulation boundary explicit.

Keeping Buyer and Seller workflows separate but connected

Buyers and Sellers need different screens and permissions but must interact with the same offers and transaction records.

Approach: Use role-aware routes and interfaces over a shared marketplace model. Enforce role checks instead of relying on navigation links alone.

Maintaining transaction consistency

If offer quantity changes but a wallet or history does not, the application becomes unreliable.

Approach: Validate balance and quantity before committing a trade, prevent duplicate submissions, and update related records through one transaction service.

Balancing visual ambition with performance

Cinematic pages can become slow when they depend on large videos, heavy 3D scenes or excessive scroll effects.

Approach: Prefer optimised imagery, lightweight SVG/CSS motion, lazy-loaded visualisations, responsive layouts and reduced-motion support.

Distinguishing a prototype from a deployable energy system

Real peer-to-peer electricity sharing involves hardware, metering, safety, regulation, settlement and cooperative governance.

Approach: Keep the academic prototype focused on the software interaction model and document real-world integrations as future work.

Keep only challenges and solutions that reflect work actually performed. Describe unfinished features as planned approaches, not completed achievements.

Accomplishments that we're proud of

NeighborWatt brings several related ideas into one understandable community-energy experience.

Role-based marketplace concept: distinct Buyer and Seller journeys connected through shared offers and simulated trades.
End-to-end workflow: offer publication, offer discovery, quantity selection, validation, trade recording and transaction history.
Explainable energy model: generation, demand, battery and surplus concepts presented through understandable formulas and visualisations.
Accessibility consideration: a feature-phone/USSD concept explores access for people who do not use smartphones.
Path from prototype to pilot: separates the software demonstration from future metering, hardware telemetry, production authentication and real settlement.

Evidence to add before submission

Mark an item complete only after verifying it in the running application.

[ ] Buyer and Seller can sign in through their respective flows.
[ ] Role restrictions work for protected routes.
[ ] Sellers can publish valid offers.
[ ] Buyers can complete a simulated purchase.
[ ] Balances, quantities and histories update consistently.
[ ] Demo state persists after reload, if persistence is implemented.
[ ] The application runs using the documented commands.
[ ] The production build completes successfully.

Replace this checklist with confirmed results and screenshots after testing.

What we learned

Product workflows must shape the interface

The Buyer needs to discover and purchase an offer; the Seller needs to estimate surplus and manage listings. Separate dashboards are useful when they map clearly to each role's tasks.

Shared data is essential

A marketplace is not truly interactive if Buyer and Seller views operate on unrelated sample data. A shared model and consistent transaction process are central to the experience.

Energy calculations need clear assumptions

Surplus depends on generation, demand, reserve requirements and time. A single number without its assumptions can mislead users.

Design and performance must work together

Visual sophistication comes from composition, typography, imagery and well-timed motion---not effects everywhere. Lightweight animation helps preserve usability.

Responsible claims build trust

A simulated transaction is not delivered electricity. A forecast example is not evidence of a validated AI model. Labelling prototype behaviour honestly makes the project more credible.

A prototype is the start of a larger system

A working marketplace can demonstrate the software interaction model. Physical deployment requires further engineering, field validation, regulatory review and community participation.

What's next for NeighborWatt

NeighborWatt proposes a four-stage roadmap from academic MVP toward a pilot.

Phase 1 --- Cooperative micro-grid pilot (Months 1--12)

Validate the use case with local stakeholders.
Assess solar generation, household demand, storage and safety needs.
Define cooperative ownership and operating responsibilities.
Establish baseline measures for energy access and household impact.

Phase 2 --- P2P energy marketplace (Months 6--18)

Develop beyond simulated data.
Integrate verified metering and a suitable backend.
Evaluate a lightweight ledger and accessible feature-phone workflows.
Review applicable electricity-market rules before live trading.

Phase 3 --- Demand forecasting and balancing (Months 12--24)

Gather appropriate, consented operational data.
Evaluate forecasting methods against measured outcomes.
Test battery scheduling and flexible-load recommendations.
Measure reliability and battery utilisation before making performance claims.

Phase 4 --- Carbon and impact monetisation (Months 24--36)

Establish defensible baselines and monitoring methods.
Assess eligibility under relevant carbon-credit standards.
Verify measurement, reporting and verification requirements.
Ensure any revenue-sharing arrangement is transparent to cooperative members.

These are proposed milestones, not confirmed deployments or guaranteed results.

Long-term vision

The long-term vision is to help communities coordinate local renewable generation, storage and energy sharing through an accessible digital platform. NeighborWatt aims to keep the user experience understandable while making energy and transaction data more transparent.

Generate locally. Store intelligently. Exchange locally. Manage transparently.

Appendix A --- Suggested test scenarios

Test Expected result

Buyer opens Seller-only route Access denied or redirected

Seller publishes a negative Validation error; no offer created quantity

Buyer requests more energy than Purchase rejected available

Buyer has insufficient demo balance Purchase rejected without partial updates

Buyer completes a valid purchase Offer, demo balances and histories update consistently

Buyer submits the same purchase Duplicate processing prevented repeatedly

User logs out and opens a protected Authentication required again route

Mobile viewport is used Main workflows remain usable without unintended horizontal overflow

Appendix B --- Screenshot checklist

Capture screenshots from the actual running application before submission:

01-landing-page.png --- landing page and hero.
02-buyer-login.png --- Buyer login.
03-buyer-marketplace.png --- offer list and price details.
04-buyer-purchase.png --- purchase summary or successful confirmation.
05-seller-dashboard.png --- generation, demand and surplus simulation.
06-seller-offers.png --- create/manage offers.
07-transaction-history.png --- matching trade records.
08-energy-flow.png --- energy-flow or forecasting demonstration.

Keep screenshots legible, remove credentials and ensure captions accurately describe what is visible. Do not use concept art as evidence of implemented functionality.

Project Summary

NeighborWatt is a community-energy web application concept that explores how households with surplus renewable energy could connect with households that need energy. Its academic MVP centres on separate Buyer and Seller portals, a shared peer-to-peer marketplace, consistent simulated transactions, and visual demonstrations of solar generation, battery storage and demand forecasting.

The project combines a practical software workflow with a broader vision for accessible, locally coordinated renewable energy.