Team

About the Library


History of the Library

The Library started when NFE was a company of just 3 people to make sharing information efficient and easy. We knew that future NFE team-members wouldn’t be able to see emails about process changes that were being sent before they joined and that most of the people who would eventually join NFE likely hadn’t even heard of us yet. This Library was our way of ensuring that all of our company information was accessible to everyone regardless of when they became part of the team.

Advantages

At NFE our Library is extensive and keeping it relevant is an important part of everyone’s job. It is a vital part of who we are and how we communicate. We established these processes because we saw these benefits:

  1. Reading is much faster than listening.
  2. Reading is async, you don’t have to interrupt someone or wait for them to become available.
  3. Talent Acquisition is easier if people can see what we stand for and how we operate.
  4. Retention is better if people know what they are getting into before they join.
  5. On-boarding is easier if you can find all relevant information spelled out.
  6. Teamwork is easier if you can read how other parts of the company work.
  7. Discussing changes is easier if you can read what the current process is.
  8. Communicating change is easier if you can just point to the page history.
  9. Everyone can contribute to it by directly editing a page.

One common concern newcomers to the Library express is that the strict documentation makes the company more rigid. In fact, writing down our current process in the handbook has the effect of empowering contributors to propose change. As a result, this Library is far from rigid. You only need to look at the Library home page to see the evidence. Every attempt is made to document guidelines and processes in the Library. However, it is not possible to document every possible situation or scenario that could potentially occur. Just because something is not yet in the Library does not mean that it is allowed. Aaron Tushabe is the primary custodian of the Library, please talk to him in the #general channel on Matrix if you're unsure about something concerning this Library. 

Library Interpretation

The Library is subject to interpretation. We do our best to be as clear as possible to minimize confusion and/or misinterpretation. We also recognize that we have a global audience and that may bring different interpretations. If you have any questions or need further clarification please check with the content owner of any given page. When in doubt please reach out and ask.

Remember that everything is in draft at NFE and subject to change, this includes our Library. 

We rarely mark any content or proposals as drafts. Everything is always in draft and subject to change. When everything is in draft, contributions from team members as well as the wider community are welcomed. By having everything in draft and assuming others have low context, confusion can be reduced as people have shared access to information.


Community Checkins

Agendas, Meeting notes and recordings for all our meetings

Community Checkins

Previous Meetings Recorded

 


 

 

Community Checkins

NFE Checkin - 16/05/2025

Agenda 

Action items 

Community Checkins

NFE Checkin - 23/05/2025

Action items 

Community Checkins

NFE Checkin - 30/05/2025

Agenda 

Action items 

Community Checkins

NFE Checkin - 06/06/2025

Agenda 

Action items 

6/13/2025

Updates and Action items

- Dansturn

Community Checkins

NFE Checkin - 20/06/2025

Agenda 

Operation Updates 

Fundraising updates 

Other collaboration tools 

MicroPower Manager - 

Action Items 

 

Community Checkins

NFE Checkin - June 24th 2025

Action items 

Community Checkins

NFE <> EnAccess Checkin

Attendees 

Meeting link:  https://meet.google.com/rpg-vpmw-zzh

Agenda 

Notes 

Quick summary

During this meeting, Aaron, Vivien, and Daniel discussed the Nearly Free Energy mini-grid project, the history and current status of the Microgrid Power Manager (MPM) software, challenges related to community adoption and technical implementation, and potential collaboration on pilot deployment and funding sustainability.

Action items for Aaron

Action items for Vivien

Action items for Daniel

 

Community Checkins

NFE Checkin - July 4th 2025

Agenda 

Action items 

Community Checkins

NFE Checkin - July 9th 2025

Agenda 

- 

Community Checkins

NFE Checkin 11/7/2025

Agenda 

Review of Last week's Action items 

Action items for this week

Community Checkins

NFE Checkin 18/7/2025

Agenda 

Action items 

Community Checkins

NFE checkin 26/07/2025

Agenda 

Previous action items 

New items to discuss

Action items 

Community Checkins

NFE <> Power for All - July 31st 2025

Had a meet and great with Joel, Alba and Sumaya from power for all. 

They shared plenty of questions and feedback on our model. Here's some resources they shared that I am following up on. 

I invited them to join our advisory team. 

Community Checkins

NFE checkin 02/08/2025

Agenda 

Action items from last week

New items 

New Action items 

Community Checkins

NFE Mid week 08/06/2025

Agenda 

Action items 

Community Checkins

NFE Checkin 8/8/2025

Agenda 

Action items  from Last Week

New updates

New Actions items

Community Checkins

NFE / SLS Energy / Energy IoT -intro meeting

Quick summary

During this meeting, Arila, Merci, Léandre, and Aaron discussed a collaboration on an open-source microgrid project in Uganda, focusing on battery storage solutions, battery-as-a-service models, and integration with open-source energy management systems. They explored technical specifications, cost models, and operational challenges related to battery backup, grid outages, and energy trading platforms. The participants also considered opportunities for mentorship programs and local community involvement to support sustainable energy solutions.

Action items for Arila

Action items for Léandre

Action items for Aaron

Community Checkins

NFE Checkin 03/08/2025

Agenda

Notes

Action items 

Community Checkins

NFE checkin August 30th 2025

Attendees 

Agenda 

Notes 

Action Items 

Community Checkins

NFE Checkin - Sept 6th 2025

Going live - any blockers and questions 

Action items 

 

 

Community Checkins

NFE Weekly Checkin September 13th 2025

Agenda 

Actions 

Community Checkins

NFE Weekly Checkin September 19th 2025

Agenda 

Actions from previous meeting

Retro was conducted: https://ideaboardz.com/for/Sezibwa%20Phase%201%20Retro/5640560

Community Checkins

NFE Mid week Checkin September 25th 2025

 

Notes 

Actions 

Community Checkins

NFE weekly checkin October 11th 2025

General Updates 

Agenda 

Pending Action items 

Community Checkins

NFE Weekly - October 18th 2025

Previous actions 

Agenda 

Action 

Community Checkins

NFE Weekly Checkin - October 25th 2025

Agenda 

Action items 

Community Checkins

NFE Weekly Checkin - Nov 1st 2025

Agenda 

Action items 

Community Checkins

NFE Weekly Checkin - Nov 15th 2025

Previous meeting action items
Actions Items

Community Checkins

NFE Checkin - Jan 7th 2026

Agenda 

Action Items 

Community Checkins

NFE weekly checkin - Jan 22nd 2026

Agenda 


Action Items 

Community Checkins

NFE weekly checkin - Jan 29th 2026

Notes   

Action items 

 

Community Checkins

NFE Checkin - Feb 6th 2026

Agenda 

 

Community Checkins

NFE checkin - Feb 12 2026

Deployment Checklist 

Action Items 

Community Checkins

NFE Weekly Checkin - March 21 2026

Agenda 

Action items 

Community Checkins

NFE Tech Huddle - April 3rd 2026

Quick summary

During this meeting, Aaron, Hillary discussed, the current meter-logging system, data buffering and aggregation approach, deployment pipeline, backup and metadata storage, and commissioning/precommissioning of meters.

Action items for Aaron

Action items for Hillary

Notes: Hillary already demonstrated the buffering (10s sampling, 15-min average) and the backup/upload service; team agreed to start with hourly uploads and scale as needed. Commissioning constraints and Modbus address conflicts were discussed; precommissioning workflow will be created to avoid on-site conflicts.

Community Checkins

Nfe Weekly checkin - 4th April 2026

Agenda 

Action items feedback

Action items 

Community Checkins

Tech Huddle - Behind the Meter Connection for each customer

How each customer is metered and controlled behind the bulk connection, in the Street-EMS design. Companion to the authoritative page "NFE metering strategy + Glen Street-EMS".

The question

Behind NFE's single bulk utility connection sit many single-phase tenants. "Behind the meter connection for each customer" is how we meter, bill, and control each of them individually without a separate utility meter per tenant.

Today (CHINT + Pi)

Each tenant has a CHINT DDSU666 postpaid meter on a DIN rail. A Raspberry Pi gateway polls them over Modbus RTU / RS485 and feeds OpenEMS. Billing is postpaid off the meter reads. Control (disconnect) is manual at the breaker.

Street-EMS (next generation)

One cabinet meters and controls up to 9 tenants (3 per phase) with no per-tenant meter:

Ratified: 1P (do not switch neutral except for EV), 80A rating for future EV. See the authoritative page for the full line diagram, firmware vision, and workshop context.

Community Checkins

NFE Checkin - 11th April 2026

Agenda 

Action items 

Community Checkins

NFE Checkin - May 16th 2026

Agenda 

Action items 

Community Checkins

NFE Checkin - May 23rd 2026

Last week's Agenda 

Action items 

Agenda

Action items 

Community Checkins

EnAccess <> NFE Checkin - June 2nd 2026

Attendees

Overview

The call focused on whether MPM should evolve to better support grid-connected mini-grids, especially postpaid billing, meter integrations, and monitoring of batteries/solar assets. The team agreed the current direction is promising for the Nigerian mini-grid use case, but emphasized that new capabilities should be integrated carefully so the platform remains technically coherent and maintainable.

Why the conversation happened

Aaron raised a strategic question: whether the current MPM product is being pushed beyond its original design by supporting grid-connected mini-grids, or whether a new system should be built instead. Vivien and Daniel clarified that MPM was historically built as a mini-grid CRM and later adapted by solar home system companies by the newest work in Mozambique. However, new conversations with REI in Nigeria is increasingly steering it toward mini-grid needs again.

Product positioning and strategic direction

Vivien explained that MPM’s roots are in mini-grid operations and CRM workflows, not solar home systems, even though solar home system companies adopted it over time. He noted that recent demand from Mozambique and a larger contract in Nigeria are driving more mini-grid-specific work, including OEM integrations, dashboard hardening, and other adaptations.

The team also discussed the upcoming PayGo Ops community edition, which may better serve some solar home system users. Vivien’s view was that this does not undermine MPM’s mini-grid identity; rather, it highlights that MPM should keep focusing on the mini-grid segment while remaining open to adjacent use cases where appropriate.

Postpaid vs. prepaid metering

A major topic was Aaron’s observation that the pilot became easier when the team moved away from a proprietary prepaid meter setup and adopted postpaid billing. Aaron had originally feared that MPM might be too biased toward prepaid workflows, and wondered whether postpaid mini-grid support would require an entirely new system.

Daniel responded that prepaid metering is easier to support technically because the abstraction is straightforward: a customer pays, a tariff applies, and energy is delivered. Postpaid introduces more complexity because it requires tracking usage over a billing period, calculating debt/amount owed, and handling billing logic in a less linear way. Daniel said MPM already has some related concepts, but postpaid still requires careful design so the abstractions remain coherent.

Metering and data acquisition lessons from the pilot

Aaron described the operational problems they faced with a Chinese vendor, Kalin: the meters claimed to support both prepaid and postpaid, but the vendor did not expose meter data directly. Instead, the team had to use proprietary middleware APIs hosted by the vendor, which caused reliability issues, token-lockout problems, slow support response times, and pressure to place larger orders before the pilot was stable.

To solve this, the team switched in March 2026 to locally sourced meters that are postpaid-only and expose data via RS-45/Modbus into a Raspberry Pi, which is then connected to the internet through a modem. This setup gave them direct access to meter data, reduced dependency on the vendor, and eliminated the operational risk of needing tokens from overseas just to unlock a customer meter.

Aaron also noted that the meters are physically clustered in a single PDU, which makes wired connectivity practical in this pilot. Vivien pointed out that this works for dense apartment-complex style deployments, but would not translate well to rural, dispersed mini-grids where wireless communication is usually more appropriate.

Open-source monitoring and OpenEMS integration

Aaron said the pilot team had already contributed a plugin to OpenEMS so that usage data from the new meters can be read in real time. He suggested a future model where OpenEMS handles monitoring of meters, batteries, and solar assets, while MPM handles business functions such as billing, invoicing, and customer communication.

Daniel and Vivien were receptive to this division of labor. Vivien emphasized that the goal should be integration rather than rebuilding existing open-source tools. He referenced the existing Prospect integration as a model: ideally, MPM should connect with external monitoring systems in a way that lets users move seamlessly between tools rather than duplicating functionality.

Battery and solar support

Aaron asked whether MPM was originally intended to handle batteries and solar generation data as part of mini-grid operations. Daniel clarified that this was not part of the original core focus. MPM’s main scope has been customer transaction management and business workflows, not system monitoring.

That said, Daniel acknowledged that there is a gray area where battery or solar data affects billing, and therefore may need to be integrated into MPM workflows. He stressed that system monitoring should not simply be bolted on as a disconnected feature. Instead, the team should think carefully about where such data belongs, how it is modeled, and how it can be integrated without making the product overly complicated.

Billing, customer visibility, and invoicing features

Aaron demonstrated the pilot’s customer-facing web app, which lets customers see their usage, estimated bill, and end-of-month projection. The app refreshes automatically every six hours, with manual refresh available. This was intended to reduce uncertainty for customers and let them see charges before the monthly billing cycle closes.

He also showed the microgrid manager billing interface, where customer data is imported, billing cycles are created monthly, invoices are generated, and payment links are attached through a payment service. Aaron highlighted this as one of the strongest parts of the pilot and argued that MPM should gain similar invoicing capability, alongside an integrated payment-provider flow and an OpenEMS data source.

The group agreed that these were the most concrete candidate features to pursue. Aaron said his team could likely push the payment integration and invoicing work, while also helping define the OpenEMS plugin approach and continuing conversations with Nigerian partners.

Nigeria and regulatory relevance

Vivien stressed that Nigeria is especially relevant because it has an active mini-grid market, including grid-connected mini-grids, structured regulation, and tariff systems that resemble the use case Aaron is working on. Aaron agreed, noting that Uganda’s regulator is increasingly looking to Nigeria as an example for policy development, and that his team is preparing a paper to make the case for adopting elements of Nigeria’s regulatory framework.

The discussion made clear that Nigeria is both a strong market for the problem and a promising source of practical solutions. Vivien also suggested Aaron could observe some conversations EnAccess has with other community members who are focussing on Mini-grids. 

Managing codebase complexity and simplification

Later in the call, Aaron asked whether there should be a roadmap for removing or disabling legacy features from MPM, since long-running applications tend to accumulate unused functionality. Daniel said the team had spent much of 2025 removing things, but had recently shifted toward adding new capabilities. He agreed that managing complexity is an ongoing concern.

Daniel distinguished between two kinds of simplification:

Obinna added that from his experience, the team usually receives feature requests rather than removal requests. He suggested that if the roadmap included clearer visibility into unused functionality, he could help identify features that no one appears to use and also warn when something that looks unused is actually used by someone else.

Key takeaways

Community Checkins

NFE checkin - June 6th 2026

Agenda 

Notes and action items 

Community Checkins

NFE Mid week checkin - June 11th

Attendees

Agenda 

Recording is here

Community Checkins

Hillary / Aaron - Tech Huddle - June 29th 2026

 Meeting Transcription.txt

Recording here

Community Checkins

NFE Checkin - July 4th 2026

Agenda 

Community Checkins

NFE Checkin - July 25th 2026

Agenda 

Meeting title: Meeting Transcription
Date/time started: 2026-07-25T03:21:56.000Z
Participants: Hillary Arinda, Aaron Tushabe, Dansturn Kimbowa

Summary (up to three sentences)

Action items by person

Aaron Tushabe

Hillary Arinda

Dansturn Kimbowa

No other participants were assigned tasks.

Community Checkins

NFE Checkin - August 8th 2026

Date: 8 August 2026
Attendees: Aaron Tushabe, Dansturn Kimbowa, Hillary Arinda
Duration: ~2 hours 5 minutes

1. Nansana Pilot & Battery Backup

The Nansana battery backup system is now live and billing has proceeded without major issues. Initial operation indicates a significant reliability improvement, particularly during the daytime. During outages, the batteries have generally supported the site for approximately 1–1.5 hours under heavier evening loads, and substantially longer when customers reduce high-consumption appliances.

A useful behavior has also emerged organically: residents notify each other when the site has switched to battery and encourage reduced consumption. The team agreed this should eventually be automated so customers are notified when they switch to backup power. This would both help extend battery runtime and make the reliability value of the NFE service more visible to customers.

The telemetry stack is not yet sufficiently stable to accurately measure and report outage duration, battery behavior and reliability over time. The immediate priority is therefore to stabilize telemetry and establish a reliable baseline before experimenting extensively with battery operating strategies.

Battery Optimization

The current battery configuration primarily preserves stored energy for outages. The team discussed experimenting with time-of-use arbitrage, where batteries charge during cheaper off-peak periods and discharge during peak tariff periods while maintaining a minimum reserve for outages.

One possible configuration discussed was allowing discharge to approximately 50% during peak periods before reverting to grid supply. These experiments should only begin once telemetry is stable enough to compare their impact on both reliability and margins.

2. OpenEMS Migration & Q3 Technical Priorities

The Q3 development objective remains to consolidate both metering and battery monitoring onto OpenEMS, creating a common technology stack for future deployments. Once the OpenEMS metering integration and automated billing flow are stable, NFE should have a more commercially scalable sub-metering platform.

Progress has been made integrating the inverter, although discrepancies between available documentation and the installed inverter firmware have required experimentation. The target is to resolve the outstanding inverter integration issues during the coming week.

The team also discussed configuration management within OpenEMS. For Q3, the current configuration-file/Felix UI approach will continue rather than building a new management interface. Building a separate interface was considered outside the current Q3 scope.

Some technical questions remain around:

Historical backfilling was considered secondary to getting current data flowing correctly into OpenEMS.

3. Billing, Service Charge & Economics

The team reviewed the economics of the Nansana site. It is still too early to determine whether battery installation has materially improved margins because:

The reliability improvement is already more apparent than the profitability impact.

The discussion highlighted the need for a more rigorous model for determining the appropriate monthly service charge. Future pricing should reflect both:

  1. the value of improved reliability delivered to customers; and

  2. NFE's actual operating and maintenance costs.

The existing service-charge adjustment was acknowledged as a reasonable pilot decision rather than a fully cost-derived commercial price.

4. Battery Funder / Data Sharing

The battery funder is aware that the backup system has been installed and has indicated willingness to potentially contribute an additional small amount toward installation costs. Aaron has a follow-up meeting scheduled for Monday to provide an update and review the roadmap.

The original arrangement requires NFE to share operational data. The team agreed there is no need to make historical data migration a blocker. Existing spreadsheet records can be shared for earlier periods, while newer telemetry can be exported from the current database/OpenEMS stack.

5. Analytics Layer / AI-native Operations

The current system collects telemetry into InfluxDB, but NFE does not yet have a defined analytics layer.

The team revisited the broader Microgrid OS architecture and discussed potentially avoiding a dashboard-heavy analytics approach. One promising direction is an LLM-powered operational analytics interface sitting over the telemetry data, potentially using MCP or a similar interface to allow users to ask questions such as:

The analytics architecture should be revisited as part of future/Q4 Microgrid OS planning.

6. Nairobi Workshop — Generation 3 Hardware

The Nairobi workshop is proceeding, with three sponsored participation slots currently available.

The team clarified that the objective should not simply be to attend or observe the workshop. The explicit goal is to leave Nairobi with a pathway toward Generation 3 of the NFE microgrid/sub-metering stack.

The generations were framed as:

Generation 1

Generation 2

Generation 3

A preliminary BOQ discussed during the meeting suggested an equipment cost of roughly US$64 per customer for the workshop hardware configuration, although this still needs validation.

The team acknowledged that moving the workshop prototype into a production-grade NFE system will require additional engineering, testing, enclosure/assembly work and software integration.

7. UNBS Certification

A key open issue for Generation 3 hardware is regulatory approval.

Once NFE begins assembling its own metering hardware and using it for customer billing, UNBS certification/calibration requirements will become important. The team needs clarity on:

This will determine whether the open-hardware approach remains economically attractive relative to using already-certified commercial meters.

8. Customer Pipeline

Chanjala / Three-phase Connection

The outstanding issue remains the three-phase supply/meter installation. UMEME appears ready to install once the required meter payment and outstanding site-side issues are addressed.

The team discussed proceeding with the meter installation while treating any problems with the customer's internal/network infrastructure separately.

Dansturn Home Installation

Dansturn would like NFE monitoring installed at his home so that he can better understand his electricity consumption.

This is also considered a useful test environment because it provides the engineering team with a site that is easier to access than Nansana. The same installation can help refine the product before installing for Edward and other individual customers.

Target discussed: Monday/Tuesday during the coming week, subject to technician availability.

9. Target Customer Strategy

The team revisited whether NFE should prioritize new construction or existing sites.

The conclusion was that existing developments with:

remain the more attractive near-term market.

New developments can still be considered where the developer bears the upfront metering/infrastructure cost, but NFE should avoid tying up its own capital for years waiting for occupancy and consumption to ramp up.

10. Conferences & Industry Engagement

Nairobi

NFE currently has three sponsored passes and expects to send the founders/team, subject to individual availability.

Kigali

The team is also exploring participation in a Kigali event. Aaron will investigate whether NFE can obtain passes and potentially participate as workshop facilitators or presenters.

The team agreed to resume a physical working session on Friday, with Nairobi preparation being one of the main priorities.

11. Fundraising & Corporate Readiness

NFE is awaiting outcomes from current grant opportunities and needs to identify additional fundraising avenues, particularly to support further deployment work at Pearl Marina and other sites.

The team also briefly discussed ensuring NFE's equity/shareholding documentation is properly organized ahead of future grant, investment or corporate due-diligence processes.

Action Items

Action Owner Timing
Stabilize OpenEMS telemetry so outage, battery and reliability metrics can be reliably collected Aaron / Hillary August priority
Complete outstanding inverter/OpenEMS integration work Aaron / Hillary Target: next week
Move remaining Nansana meters onto the common OpenEMS monitoring/dashboard stack Technical team During August
Design automated customer notification when the site switches to battery backup Hillary / Technical team After telemetry stabilization
Establish a reliability baseline before testing new battery dispatch configurations Technical team After telemetry stabilization
Test peak/off-peak battery dispatch strategies and measure effect on reliability and margins Technical team After baseline is established
Develop a more rigorous cost/service-charge pricing model for future commercial sites Aaron / Team Before next larger commercial deployment
Meet battery funder, provide deployment update and discuss roadmap/data-sharing expectations Aaron Monday
Clarify how OpenEMS writes settings to inverter registers and how automated control could modify those settings Aaron / Hillary Technical investigation
Revisit Microgrid OS analytics-layer architecture, including LLM/MCP-based querying over telemetry Aaron / Hillary Q4 planning
Review Nairobi workshop BOQ/components and ensure the team understands the proposed hardware architecture Aaron, Hillary & Dansturn Before Nairobi
Define a concrete Generation 3 deliverable/plan for the Nairobi workshop All Before Nairobi
Investigate UNBS certification/calibration requirements and likely costs for NFE-assembled meters/PDU Team — owner to be confirmed Before Generation 3 production deployment
Follow up on Chanjala three-phase meter installation Aaron Ongoing
Arrange monitoring installation at Dansturn's home Aaron / Technician; Dansturn to coordinate availability Target Monday/Tuesday
Use Dansturn installation as a nearby development/test environment before rolling out to Edward and similar customers Technical team After installation
Investigate Kigali conference/workshop passes and participation Aaron Follow-up
Hold physical NFE working session focused on Nairobi preparation All Friday
Identify additional fundraising opportunities for upcoming deployments All Ongoing
Ensure NFE shareholding/equity documentation is organized for future grants/investment processes Founders Upcoming
Community Checkins

NFE Checkin - August 29th 2026

Agenda 

Participants: Aaron Tushabe, Dansturn Kimbowa, Hillary Arinda

1. Power Africa / Nairobi

NFE has received travel support for the upcoming Power Africa/IEEE-related activities in Nairobi. The current support appears to include reimbursement of Uganda–Nairobi bus transport up to US$150/person, accommodation, airport transfers and most meals. The main outstanding question is the approximately US$300 conference registration fee, which was the item NFE had originally hoped would be sponsored.

Aaron's attendance remains tentative because of possible travel restrictions, while Dansturn is expected to attend if possible. The team also discussed the possibility of participating in related activities in Rwanda later in October.

Decision: Continue preparing for Nairobi, but clarify whether registration fees can also be covered.

2. Financing NFE deployments

Aaron reported on his discussion with Stanbic's renewable-energy financing team.

Two financing structures were discussed:

Indicative Stanbic terms are up to about 15% per annum, potentially lower for larger transactions, with financing periods potentially extending considerably longer for larger projects.

However, the bank may require:

This highlighted an important issue for NFE: procurement, installation and maintenance are currently somewhat separated. For bank-financed projects it may be advantageous to structure these more formally around an EPC relationship with clear manufacturer authorization, installation responsibility and warranties.

For the proposed ~UGX 4 million solar investment at Nansana, the team estimated repayment at roughly UGX 190k–200k/month over two years, depending on the bank's calculation methodology.

The discussion was not simply about obtaining UGX 4 million. The strategic value would be learning the bank's financing process and establishing a financing pathway that could later support much larger deployments such as Pearl Marina.

Dansturn raised the counterargument that debt can encourage progressively larger borrowing and therefore increases risk. Aaron's view was that project-level asset financing can be appropriate where the asset and its project cash flows support the loan and the lender's remedy in a failed project is largely tied to the financed assets.

Working direction: Continue investigating the Stanbic facility rather than dismissing it. The team generally considered 15% potentially workable, although Hillary would prefer a lower rate if one is available.

3. NFE accounting readiness

The financing discussion reinforces the need for NFE's financial records to become audit-ready.

Aaron has started migrating the company's accounting into Zoho Books and needs to finish bringing the records up to date before engaging an auditor.

The team also discussed Esther's role supporting the books. Aaron had proposed a UGX 50,000 monthly stipend, while Esther asked whether she could receive equity instead.

The existing NFE equity-for-work framework requires roughly five hours of regular contribution per month. At the current transaction volume, the bookkeeping work probably does not yet reach that threshold.

Working position: Continue with cash compensation for now rather than allocating equity, while leaving open the possibility of equity if the finance workload grows sufficiently.

4. Nansana battery operation and arbitrage

Hillary raised a concern about whether customer demand could undermine the economics of battery arbitrage.

If customer load exceeds inverter capacity, the inverter may move into bypass/grid operation. This could be particularly important during evening peak periods, when NFE expects battery discharge to reduce grid consumption and improve margins.

The team needs to understand the exact inverter behavior under:

The team also reviewed recent energy summaries and noticed surprisingly little reported battery discharge, despite known instances where the site has operated on battery.

This raises the possibility of a reporting/algorithm problem rather than an actual absence of discharge.

Decision: Investigate the battery discharge reporting before relying heavily on the existing daily summaries.

The team also agreed that NFE does not need to wait for solar installation before testing battery arbitrage. With grid supply currently relatively stable, this is actually a good opportunity to begin controlled peak-discharge experiments.

5. Phase balancing and low-voltage problem at Nansana

Following the recent phase-balancing work, one customer has reported that high-load appliances such as the microwave/hot plate are not operating properly.

The leading hypothesis is a loose electrical connection, particularly a neutral connection, producing acceptable unloaded voltage but excessive voltage drop once significant current flows.

The site technician was expected to visit the site and:

  1. tighten/check all relevant terminals;

  2. test voltage;

  3. have the customer switch on a significant load such as the microwave;

  4. verify that voltage remains stable under load.

The recent balancing work has nevertheless significantly improved phase distribution. The approximate phase allocation is now around:

A further meter transfer could potentially move this toward roughly 31/35/34, but this is not urgent because the current distribution is already substantially better than before.

The additional move requires suitable 16 mm² copper cable, which is not currently available.

6. Improve the physical meter installation

While reviewing the Nansana installation, the team agreed that the current wiring arrangement is functional but not sufficiently clean or scalable for future commercial deployments.

Particular attention should be given to the RS485/Modbus wiring and the general routing of conductors.

The team discussed developing something more analogous to a busbar/distribution arrangement so connections are organized rather than looping and hanging between devices.

Principle: Nansana can remain an experimental installation, but the next installation—particularly Pearl Marina—needs a significantly cleaner and more repeatable hardware design.

7. Pearl Marina engineering proposal

Aaron met with Pearl Marina's engineering/management representatives to understand what would be required for formal approval.

They want a proper engineering proposal showing:

They also want the proposal and drawings reviewed by a qualified/certified engineering firm. Multiconsult was mentioned as one firm they already work with and would likely trust.

Dansturn explained that the starting point should be Pearl Marina's existing as-built electrical/MEP drawings. These would allow NFE to overlay the proposed system architecture.

For the solar component, NFE also needs the roof plan. The roof plan establishes available area, while structural calculations or information from the structural engineer will be needed to determine allowable loading from the proposed panels.

Decision: Prioritize completing the Pearl Marina proposal rather than pursuing the other stalled development immediately.

The second project discussed remains potentially viable but construction has slowed because the developer appears to have funding constraints.

8. Additional embedded-systems engineering support

Hillary described another engineer with skills in:

The team believes this person could be particularly relevant to the IEEE/open-hardware work.

Hillary will introduce him to the material already shared in NFE's IEEE Smart Village collaboration channel, including the previous workshop documentation and NFE's broader generation/capability roadmap.

The goal is not merely to have him study individual technical documents, but to understand NFE's direction toward increasingly open, locally maintainable hardware.

9. Calin meters and EnAccess

The team confirmed that NFE no longer has a strong commercial use for the decommissioned Calin meters.

EnAccess is interested in them for MicroPowerManager integration/testing, particularly because Calin meters are apparently used considerably in West Africa.

Decision: NFE is willing to donate the available used meters to EnAccess provided EnAccess covers shipping.

The meters should be clearly described as used, and EnAccess should understand that NFE cannot guarantee continued access to Calin's hosted AMI/API.

The broader lesson remains that relying on vendor-hosted APIs creates long-term platform risk. NFE prefers equipment with interfaces that can be accessed directly and independently.

10. Smart Metering Crisis Response opportunity

The team discussed the new OSEA/EnAccess Smart Metering Crisis Response initiative following the collapse/distress of major meter providers.

Approximately a quarter-million connections across numerous countries may be affected.

Emergency funding is being used to preserve existing platforms, including attempts to obtain source code and encryption keys so affected operators can continue operating deployed meters.

However, the initiative is also considering what a long-term, vendor-independent architecture should look like.

Aaron has already positioned NFE as a potential contributor.

This fits strongly with NFE's Microgrid OS thesis:

Operators should be able to integrate directly with meters through documented interfaces, while the management layer remains open source and self-hostable if necessary.

There may therefore be both a technical collaboration opportunity and potentially access to catalytic funding.

The team should follow the Discord channel and prepare to contribute to the expected September discussions/workshop, potentially in Nairobi.

Q3 progress

The team reviewed the existing Q3 goals and concluded that substantial progress has been made:

More operating data is still required before some of these can be considered fully validated.

Action Items

Owner Action
Aaron Follow up with Power Africa/IEEE organizers and ask whether the US$300 conference registration can be sponsored/reimbursed.
Aaron / Dansturn Continue Nairobi preparations; Dansturn to plan on attending while Aaron's attendance remains tentative.
Aaron Obtain Stanbic's complete asset-financing requirements/checklist.
Aaron Finish updating NFE's financial records in Zoho Books.
Aaron Investigate the requirements/cost of having NFE's accounts audited.
Aaron Respond to Esther regarding compensation; current direction is UGX 50k stipend rather than equity at the current workload.
Aaron / Hillary Investigate the apparent battery-discharge reporting bug in the daily energy summaries.
Hillary / Aaron Confirm inverter behavior when customer instantaneous demand exceeds inverter output while battery/grid are available.
Hillary / Aaron Begin planning/testing controlled battery arbitrage / peak discharge without waiting for solar.
Site technician / Dansturn / Hillary Diagnose the Nansana low-voltage problem: inspect/tighten terminals, especially neutral, and verify voltage under load using the customer's microwave or similar appliance.
Team Obtain suitable 16 mm² copper cable before completing the remaining phase-balancing move.
Technical team Develop a cleaner wiring/RS485/bus arrangement for the next-generation meter installation.
Aaron Request Pearl Marina's as-built electrical/MEP drawings and relevant roof drawings/plans.
Dansturn Use the Pearl Marina as-built drawings to begin developing the proposed electrical integration drawings once received.
Aaron / Dansturn Determine what structural information/calculations are required to demonstrate that the Pearl Marina roof can safely carry the solar array.
Aaron Begin drafting the broader Pearl Marina technical/project proposal around the engineering drawings.
Hillary Introduce/onboard the embedded-systems engineer to the IEEE/open-hardware work and share relevant workshop/wiki materials plus NFE's generation roadmap.
Hillary Continue trying to contact the person holding the unused Calin meter inventory.
Aaron Coordinate donation of the decommissioned Calin meters to EnAccess, with EnAccess covering shipping.
All Follow the OSEA #smart-metering-crisis-response channel and familiarize yourselves with the initiative before upcoming discussions.
Aaron / team Develop NFE's position/proposal for how the Microgrid OS/open metering architecture could contribute to the long-term smart-metering crisis response.
Aaron + Dansturn Plan an in-person technical working session for Tuesday, including procurement/setup work discussed at the end of the meeting.

Most important priorities before the next weekly meeting

I would reduce the above to five immediate priorities: (1) resolve the Nansana voltage fault, (2) investigate battery discharge reporting and start arbitrage testing, (3) get Pearl Marina's as-built/roof drawings and start the proposal, (4) obtain Stanbic's financing requirements and make the books audit-ready, and (5) develop NFE's concrete contribution to the Smart Metering Crisis Response rather than participating only as an observer.

Community Checkins

NFE checkin - 12/09/2026

Agenda 

Below is a cleaned-up summary of the NFE weekly meeting held on 12 September 2026, focusing on decisions, progress, risks, and concrete follow-ups rather than reproducing the full discussion.

NFE Weekly Meeting — 12 September 2026

Participants: Aaron Tushabe, Dansturn Kimbowa, Hillary Arinda
Duration: ~95 minutes

1. Power Africa / Nairobi planning

The team confirmed that the Power Africa organizers will cover the conference fees, resolving one of the main outstanding travel issues.

Travel planning is now focused on finalizing attendance, accommodation and flights. Aaron indicated that he may need to fly depending on travel restrictions and timing. Hillary was asked to confirm whether she can participate for at least part of the trip, potentially from around 20–26 September. Dansturn's schedule is constrained by a crusade beginning around 17 September.

Aaron also plans to schedule time with Ben before the conference for a short preparation session so the team can better understand what to expect and how to make the most of the event.

Direction: Proceed with registrations and hotel arrangements now; delay booking any uncertain flights until individual attendance is confirmed.

2. Nansana pilot — problematic Meter 007

Meter 007 continues to lose connectivity unpredictably.

The team previously identified a configuration issue which, once corrected on-site, temporarily brought the meter back online. However, the problem returned without a clear triggering event.

Because configuration changes require physical interaction with the meter and the meter's own controls are unreliable, the team agreed it is no longer worth repeatedly troubleshooting it in production.

Decision: Replace Meter 007 at the site with Aaron's known-working test meter and bring the problematic unit back for bench/lab investigation.

For the current billing period, the team can capture the meter's opening/closing readings manually so the customer's bill remains accurate even if the telemetry data is incomplete.

3. Customer communication — email vs WhatsApp

The team revisited how NFE should communicate with customers as the pilot grows.

At present, WhatsApp is convenient, but the team sees several drawbacks:

Aaron proposed gradually shifting formal customer communication toward email, especially for:

NFE already has a support email address and a support application, which could make email easier to automate and manage.

Hillary noted that WhatsApp is deeply embedded in everyday business communication in markets such as India and may remain important for customer convenience.

Working position: Do not necessarily abandon WhatsApp, but build email as the durable system of record. Ideally, customer notifications could eventually go to both WhatsApp and email, while support operations are centrally tracked.

4. Financing / Stanbic loan process

There was little progress on the Stanbic financing application during the week.

The main blockers remain:

Aaron acknowledged that this process may take longer than initially expected and could delay the Nansana solar expansion if NFE waits for the loan.

However, the team did not change its earlier position that going through the bank process is strategically useful.

Both Hillary and Dansturn supported continuing with the financing application so NFE can learn the process, even if it takes time.

Decision: Continue pursuing Stanbic financing, but do not necessarily make the current Nansana solar expansion dependent on the loan.

5. Possible commercial / industrial microgrid model

A major new discussion focused on whether NFE's model could be extended to commercial or industrial customers.

The proposed model is:

A business already pays a predictable utility bill, perhaps UGX 4–5 million/month. NFE installs solar, storage and controls that materially reduce the underlying grid cost while offering improved reliability.

Rather than selling cheap electricity as the sole value proposition, NFE could potentially allow the customer to continue paying something near its historic energy spend while redirecting the cost savings toward financing the new system.

That predictable historical bill could also become evidence for a bank or other financier that the customer already has sufficient recurring cash flow to support the asset.

This resembles, in some respects, the model used by companies such as the previously discussed lease/energy-service providers, but NFE would aim to build it on much lower equipment and financing costs.

A potential initial candidate discussed was a commercial property with monthly electricity expenditure around UGX 4–5 million.

Next step: Build the economics first and test whether the model produces sufficiently attractive margins before presenting it externally.

The team agreed that this should remain an adjacent opportunity rather than distracting NFE from its core residential/community microgrid strategy.

6. Industrial hardware considerations

Hillary raised an important consideration from her observations of larger commercial/industrial installations: at higher power levels, customers and EPCs may expect more established "industrial-grade" equipment brands such as SMA or BYD, rather than the smaller-scale equipment NFE currently uses.

That does not necessarily invalidate the model, but equipment requirements and customer expectations may materially change the economics.

Aaron noted that discussions with bank-approved EPCs showed that several major equipment brands are available locally.

Implication: Any industrial/commercial economics model should include a realistic hardware scenario rather than simply scaling up NFE's current residential BOM.

7. Candidate commercial site — analyze electricity consumption

The team reviewed existing electricity bills for one prospective commercial customer.

Consumption appears substantial enough to justify deeper investigation, with some periods and tariff categories significantly higher than others.

The immediate analytical goal is to understand:

Decision: Aaron will develop the economics and bring the model back to the team before approaching the customer or a financier.

8. Pearl Marina

There was no meaningful progress this week on obtaining the Pearl Marina building drawings needed to develop the engineering proposal.

The earlier action remains outstanding: obtain the building/as-built electrical and roof drawings so Dansturn can begin developing the proposed microgrid integration.

This remains an important follow-up rather than a changed decision.

9. Raspberry Pi / gateway connectivity problem

The team spent time troubleshooting one of the Raspberry Pi gateways that had previously connected successfully but had since gone offline.

The Pi appears powered, but is not reconnecting to the configured Wi-Fi network.

The likely problem is network connectivity rather than the application itself.

The proposed recovery process is:

  1. obtain an Ethernet cable;

  2. move the Pi near the router;

  3. connect it by Ethernet;

  4. restore remote access;

  5. reconfigure/test Wi-Fi;

  6. return it to its installation location once connectivity is stable.

If that fails, the SD card can be removed and the image/configuration rebuilt.

This also highlighted a broader product issue: NFE's current Raspberry Pi setup still requires too much ad-hoc field troubleshooting.

10. Move toward industrial DIN-rail gateways

The gateway troubleshooting led into a useful hardware discussion.

Aaron shared an industrial-style DIN-rail computing/gateway option that includes features such as:

Hillary noted that once the cost of the Raspberry Pi plus enclosure, RS485 adapter, networking accessories and other peripherals is considered, the cost difference may not be very large.

The team therefore sees merit in moving toward a more integrated industrial gateway for future deployments.

Direction: Continue evaluating DIN-rail industrial gateway options, especially direct-from-China pricing for small quantities.

This could substantially improve installation quality and reliability for future NFE deployments.

11. Billing system

The team reviewed the latest monthly billing workflow.

The current system can generate bills for a defined billing period, but some steps remain manual and the user experience needs improvement.

The desired end-state is that NFE can:

  1. close the monthly billing period;

  2. automatically generate all customer invoices;

  3. click "send bills";

  4. distribute them automatically by email;

  5. eventually also send relevant notifications through WhatsApp if appropriate.

Some current issues include:

The team agreed that these are mainly refinement issues rather than blockers.

12. Pilot revenue / energy use trend

The team noticed that monthly customer energy/revenue has risen from roughly 600 to 700 units.

Several factors may be contributing:

This last point is significant because before the battery installation, outages effectively capped NFE's sellable energy.

The utility bill has also increased, however, creating a stronger incentive to begin controlling when the batteries charge and discharge.

Conclusion: NFE is now beginning to see the economic effect of improved reliability, but it also makes battery arbitrage increasingly important.

13. Battery arbitrage is now a priority

Because NFE charges customers using a relatively flat tariff while the upstream utility cost varies by time of use, increased consumption during expensive periods could reduce margins.

The team therefore agreed that it is time to move from merely monitoring the batteries toward actively testing arbitrage algorithms.

The goal is to:

Solar will improve this further, but the team agreed that arbitrage can begin before solar is installed.

Q3 roadmap status

The team believes the core Q3 milestones have largely been achieved.

Metering: operational, though a few problematic devices remain.

Outage detection: achieved.

Battery integration: achieved.

Billing: functioning, although still partially manual.

Customer energy data: being collected and becoming useful for operational/economic analysis.

The rest of September can therefore focus more on stabilization, automation, UX improvements and closing outstanding bugs rather than adding major new capability.

Action Items

Owner Action
Aaron Register/finalize remaining Power Africa attendees.
Hillary Confirm Power Africa/Nairobi availability and travel dates.
Aaron Finalize hotel arrangements and only book flights once attendance is confirmed.
Aaron Arrange a short Power Africa preparation session with Ben before the conference.
Aaron + site technician Visit Nansana and replace Meter 007 with the known-working test meter.
Aaron Bring Meter 007 back for controlled troubleshooting/bench testing.
Aaron Capture manual opening/closing readings for Meter 007 so billing remains accurate.
Aaron Continue research into moving customer support/billing notifications toward email, while preserving WhatsApp where useful.
Aaron Assess how NFE's support tooling can centralize and retain customer communications.
Aaron Continue the Stanbic asset-financing application and requirements process.
Aaron Continue bringing NFE's accounting books into audit-ready condition.
Aaron Develop the commercial/industrial microgrid economics model using the prospective customer's utility bills.
Aaron Share the commercial model internally before presenting it to a customer, shareholder or bank.
Hillary / Dansturn / Aaron Review suitable industrial-grade inverter/storage options and how they change project economics.
Aaron Obtain the outstanding Pearl Marina electrical/as-built and roof drawings.
Dansturn Begin Pearl Marina proposed integration drawings once the source drawings are available.
Dansturn Obtain an Ethernet cable for the offline Raspberry Pi gateway.
Aaron / Hillary / Dansturn Restore Pi connectivity over Ethernet, then reconfigure/test Wi-Fi.
Aaron / Hillary Continue evaluating DIN-rail industrial gateway/computer options with integrated RS485/networking.
Dansturn Check China pricing for suitable industrial gateway hardware, especially small-batch quantities.
Aaron Improve the billing workflow toward automated invoice creation and one-click bill distribution.
Aaron / Hillary Investigate remaining billing/meter data gaps.
Technical team Start practical testing of battery arbitrage / peak-period discharge.
Aaron Use the rest of September to close Q3 bugs, usability gaps and automation items rather than expanding scope unnecessarily.

Highest-priority items before the next meeting

I would narrow this week's execution focus to five things: (1) replace and isolate Meter 007, (2) start actual battery arbitrage testing, (3) build the first commercial-customer economics model, (4) restore the offline Pi and decide whether the industrial DIN-rail gateway is the future standard, and (5) make concrete progress on either Pearl Marina drawings or the Stanbic financing package so those larger opportunities do not remain perpetually "next week."

Community Checkins

NFE x NESL PAC2026 Pre-workshop checkin

Date: 15 September 2026
Participants: Glenn Algie (NESL), Aaron Tushabe, Hillary Arinda, Dansturn Kimbowa, Dismas Friday
Purpose: Prepare the NFE team for the Street EMS hands-on workshop in Nairobi and identify areas for continued NFE–NESL collaboration.

1. Nairobi workshop preparation

Glenn is already in Nairobi and brought roughly US$2,000 worth of equipment, including 15 Street EMS boards, SSR boards, leakage sensors and one cabinet. Two additional cabinets will need to be sourced locally. The preferred cabinet size is approximately 400 × 300 × 200 mm, with plastic preferred because it is easier to drill.

The tentative workshop structure is:

The NFE team should all be in Nairobi by Saturday. Aaron is travelling Wednesday, Hillary is flying later in the week, while Dansturn and Dismas are travelling by bus.

2. Street EMS architecture

Glenn has now published the Street EMS hardware publicly on GitHub, including the schematic and Gerber files. The hardware uses the CERN strongly reciprocal open hardware licence, although NESL is open to negotiating licensing arrangements where companies want to commercially manufacture or integrate the hardware at scale.

A major objective of the Nairobi workshop is to move beyond demonstration and eventually deploy Street EMS on a live feeder.

The Street EMS includes an expansion architecture based on a 2×20 SPI connector, supporting several interchangeable modules. CircuitSetup six-channel metering boards can be stacked, potentially allowing a Street EMS to meter up to 18 channels.

3. Intelligent feeder / autonomous feeder concept

A significant part of Glenn's vision is moving intelligence from a centrally managed mini-grid down to the feeder level.

NESL is experimenting with a low-cost Waveshare ESP32-P4 compute module, costing roughly US$16, installed once per feeder. This would act as a policy or supervisory controller across approximately 10–15 Street EMS units.

The feeder controller could communicate with:

The long-term concept is an autonomous feeder capable of understanding generation, storage and demand across a community and making local energy-management decisions.

This closely overlaps with NFE's interest in distributed energy management and community-owned microgrids.

4. DTM EMS and power-quality monitoring

NESL has developed a Distribution Transformer Monitor EMS (DTM EMS) using a Ditronix EPEM module built around the ATM90E36 metering chipset.

The device monitors areas such as:

Unlike the Street EMS hardware, the DTM EMS software is currently closed source/licensable.

Glenn plans to have Robert Burke of wmac.cloud in New Zealand test the DTM EMS alongside Robert's existing DTM equipment. Robert has reportedly deployed over 5,000 transformer monitoring devices, giving NESL a useful benchmark for accuracy and performance.

Glenn is willing to make the DTM EMS software available to NFE under an appropriate commercial/licensing relationship.

5. Leakage detection and electrical safety

NESL is integrating IVY Metering AC/DC leakage sensors, originally designed for EV charging applications. These sensors communicate over Modbus and require 12 V DC.

The ESP32-P4 prototype interface can display leakage and neutral imbalance data in real time.

This capability could become important for NFE deployments where feeder safety, grounding quality and equipment protection need to be monitored continuously.

6. EV charging opportunity

NFE raised its interest in eventually incorporating EV charging/e-mobility into the Street EMS architecture.

Glenn has already developed an EV charging software stack for wmac.cloud. It will not be released publicly, but he is willing to provide NFE access under licence.

Even if physical EV charging hardware is not available during the Nairobi workshop, the NFE team would like to understand the architecture and integration model.

7. Meter calibration and certification

Aaron raised the need to understand how Street EMS metering could eventually meet UNBS/KEBS or utility-grade certification requirements.

Calibration emerged as an important area for further collaboration.

The proposed architecture includes:

Glenn believes properly calibrated systems could achieve better than approximately 0.5% measurement accuracy.

Glenn currently has a working three-phase power-supply design but does not want to personally take responsibility for formally publishing/certifying the high-voltage section because of the safety implications.

Dansturn, who has high-voltage experience, offered to review and potentially help take technical ownership of this aspect.

8. Proposed code challenges

Several development projects were proposed for the workshop and subsequent collaboration:

  1. DLMS/COSEM support for Street EMS, potentially in collaboration with SteamaCo.

  2. ESP32-P4 compute-only expansion board for feeder-level policy/control.

  3. Factory test harness using Raspberry Pi or ESP32 hardware with automated Python-based tests.

  4. Automated calibration rig for Street EMS boards and three-phase power supplies, including QR-code generation and calibration-data storage.

  5. Open-source three-phase sensing power supply, with a properly engineered and certified reference design.

Glenn's broader goal is to use the workshop to identify people willing to own or contribute to each challenge rather than trying to complete everything during the event.

The week following the workshop, EnAccess/A2EI activities are scheduled for 29 September–2 October, with an emphasis on the emerging OpenAMI standard.

Glenn also sees value in allowing Street EMS installations to work with either OpenAMI or DLMS/COSEM, rather than forcing users into one communications architecture.

Glenn offered to facilitate introductions or calls with several relevant technical collaborators, particularly:

Dave Williams — Ditronix: power-quality and measurement hardware, open source and STEM interests.

Robert Burke — wmac.cloud: extensive real-world distribution-transformer monitoring experience in New Zealand.

There may also be an opportunity to engage the designer behind the CircuitSetup metering hardware.

Decisions / Agreements

The team agreed that Aaron's existing Street EMS cabinet from Uganda should be brought to Nairobi as an additional workshop unit.

Cabinet assembly should remain part of the hands-on workshop where possible, with Glenn confirming the final arrangement with Jude. The NFE team will regroup by Saturday or Sunday at the latest to determine whether any pre-workshop assembly is required.

Questions and coordination between now and the workshop will continue through Element.

Aaron also proposed establishing a more systematic post-workshop collaboration cadence, such as a 30-minute call every two months, which Glenn supported.

Action Items

Owner Action Target
Glenn Send detailed equipment/tools inventory to NFE 15 Sep evening / 16 Sep morning
Glenn Share Street EMS GitHub repository on Element Before workshop
Glenn Confirm whether a step drill is already available Before team travels
Glenn Share latest Street EMS one-line diagram Before workshop
Glenn Confirm pre-assembled vs hands-on build split with Jude Once Jude arrives
Glenn Share the three-phase sensing power-supply schematic Before/during workshop
Glenn Arrange introduction/Zoom with Dave Williams of Ditronix Workshop period
Glenn Arrange introduction/Zoom with Robert Burke of wmac.cloud Workshop period
NFE team Bring Phillips and slotted screwdrivers Travel
NFE team Bring a step drill bit if available Travel
NFE team Bring Aaron's Street EMS cabinet from Uganda Travel
NFE team Bring spare three-phase PSU PCB and/or SSR board Travel
NFE team Source two additional ~400 × 300 × 200 mm cabinets in Nairobi Before Tuesday
Dansturn Review three-phase power-supply schematic and support HV design/safety review Workshop
Aaron Discuss UNBS/KEBS certification, meter calibration and utility-grade approval pathway with Glenn Workshop
NFE + Glenn Explore EV-charging code/licensing opportunity Workshop/follow-up
NFE + NESL Identify which proposed code challenges NFE can own or contribute to Workshop
Aaron + Glenn Establish recurring ~30-minute collaboration check-in every other month Post-workshop
All Regroup and decide whether pre-assembly is needed Sat 19 / Sun 20 Sep

Most important NFE opportunities coming out of the discussion

For NFE, I would prioritize three threads during the Nairobi workshop: getting Street EMS running on an actual feeder or realistic NFE configuration; taking a meaningful role in the calibration/certification + three-phase sensing work; and understanding how the ESP32-P4 feeder controller, DTM EMS and Street EMS could fit into NFE's broader Microgrid OS architecture.

The EV charging work is also strategically relevant, but I would treat that as an adjacent opportunity rather than letting it distract the team from getting the core feeder, metering and calibration architecture working first.

Community Checkins

NFE Checkin - 18/09/2026

Date: 19 September 2026
Participants: Aaron Tushabe, Dansturn Kimbowa, Hillary Arinda
Main topics: Commercial customer model, Worship Harvest opportunity, system sizing and validation, conference/workshop objectives, Street EMS certification, and travel/logistics.

1. Commercial customer model

The team reviewed the emerging NFE model for supplying commercial/non-residential customers with reliable power at approximately the same effective cost they already pay for electricity, while NFE owns and operates the reliability infrastructure.

The proposed commercial deployment model is:

A key conclusion was that, unlike some residential deployments, the commercial model appears to require significant solar PV in Phase 2 to make the economics work well.

2. Worship Harvest as the first commercial case

The Worship Harvest facility was used as the primary case study.

The available utility-bill data suggests consumption of approximately 6.9 MWh/month, with much of the load occurring during shoulder periods and some during peak periods.

The preliminary system concept discussed was approximately:

The preliminary project CAPEX discussed was in the range of roughly UGX 120–140 million, although the team agreed that these numbers still need engineering validation.

The current model appears to generate positive economics for NFE, with discussion around annual returns in the vicinity of 20%, but the team explicitly recognized that the figures need to be challenged and independently reviewed before being treated as reliable.

3. Worship Harvest’s real reliability problem may be bigger than the utility bill suggests

Dansturn provided important operational context from the customer side.

Worship Harvest reportedly uses its generator regularly on Sundays and for important functions even when utility power is available, because reliability during events is considered too important to risk.

The installed main generator is approximately 200 kVA, and additional generators may also be brought in for large events, particularly where temporary external tents, LED screens, speakers and other event loads need power.

This means the business case should not be evaluated only against the utility bill.

A potentially significant part of the customer value proposition is replacing or reducing:

The team estimated Sunday generator use alone could be around UGX 2.5 million/month or more, with total generator-related costs potentially significantly higher once other events are included.

This materially strengthens the potential commercial case.

4. Peak-demand sizing is the main technical uncertainty

Hillary highlighted the biggest engineering concern: a 50 kW inverter may be far too small if the existing site generator is 200 kVA and actual event loads approach that level.

The monthly energy figures alone do not tell NFE enough about instantaneous peak demand.

The team therefore agreed that the commercial model needs actual load-profile measurements before final system sizing.

Phase 1 metering should capture:

A major design requirement is to position the meter after the utility/generator changeover point, if practical, so that NFE can measure total facility demand regardless of whether it is being supplied by the grid or generator.

5. Generator integration and exceptional events

The team discussed whether existing generators should disappear completely under the NFE model.

The current thinking is not necessarily.

For normal operations, the NFE system should aim to remove the need for routine generator use.

However, the customer could retain generators for unusual high-demand events, especially while NFE is learning the facility’s load profile.

Over time, Phase 3 optimization could expand the NFE system so that these exceptional generator requirements also decline.

The team also recognized that parts of the Worship Harvest site are currently supplied using temporary electrical infrastructure during large events. A future design may therefore need to address not just generation capacity but also site distribution infrastructure to external event areas.

6. Customer value proposition

Dansturn deliberately challenged the proposal from the perspective of Worship Harvest management.

The working customer proposition is:

Reliable electricity without the customer having to finance the solar, batteries and inverter upfront.

NFE bears the infrastructure CAPEX.

The customer continues paying for electricity, but receives:

A future lease-to-own / ownership option could also be offered.

Under that model, the customer would pay an additional amount over perhaps 15–25 years, eventually taking ownership of the solar, battery and related infrastructure. At that point, the customer would primarily pay only for whatever residual electricity it still imports from the utility, plus any optional NFE operating/service agreement.

The team agreed that customers should have a clear long-term exit/ownership path rather than feeling permanently dependent on NFE.

7. Commercial customer threshold

The preliminary financial model suggested that customers consuming approximately 2 MWh/month or more may begin to become attractive candidates for the NFE commercial model.

This is not yet a final investment rule, but it gives NFE an initial screening threshold for:

The commercial model was seen as attractive relative to residential deployments because each installation represents one comparatively large customer, avoiding some of the customer-acquisition and metering complexity associated with serving many small households.

8. Financing strategy

The Worship Harvest-type project would require meaningful upfront capital.

Rather than financing every installation directly from NFE’s balance sheet, the team discussed bringing in bank or project-finance partners.

If the underlying commercial model holds, these installations could ultimately behave like long-lived infrastructure assets with recurring cash flows.

However, the team agreed that the financial model must first survive a rigorous engineering and financial review before approaching external financing partners.

9. Immediate Worship Harvest strategy

The proposed next sequence is:

  1. Internally stress-test the financial and engineering assumptions.

  2. Engage Worship Harvest decision-makers.

  3. Deploy Phase 1 metering as early as possible.

  4. Collect granular demand and generator-use data.

  5. Redesign the Phase 2 system using actual peak-load information.

  6. If viable, aim to obtain customer approval and move toward deployment before the end of October.

Dansturn indicated that he could help facilitate access to the appropriate Worship Harvest decision-makers.

Nairobi conference/workshop objectives

The team also discussed what NFE should aim to achieve during the upcoming Street EMS-related activities in Nairobi.

10. Understand the complete Street EMS architecture

Hillary emphasized that the team should leave Nairobi with a much stronger understanding of the overall Street EMS architecture, including:

The goal should be enough understanding that the NFE team can independently evaluate and eventually deploy the system rather than only following a guided demonstration.

11. Certification is a priority outcome

Hillary identified meter certification as one of the most important goals.

The key question is:

What is the practical path from the current Street EMS design to a meter that can legally and credibly be used for billing in Uganda?

The team wants to understand:

Hillary identified the Uganda electricity meter rules/regulations as an important reference and agreed to help surface them for review.

12. OpenAMI and software architecture

Hillary also wants deeper understanding of the software side, particularly how OpenAMI and DLMS/COSEM fit together.

The team should use the workshop to understand:

Aaron agreed to reshare the relevant technical material on Element before the workshop.

Decisions

The team agreed that the Worship Harvest commercial model is promising enough to pursue, but the current financial and engineering assumptions are not yet sufficiently validated to present as final.

The biggest immediate technical gap is peak-demand data.

The team also agreed that the Nairobi workshop should focus primarily on technical understanding and certification, rather than treating fundraising as the main objective.

Funding relationships can still be developed, but the immediate goal is to strengthen NFE’s technical capability and credibility.

Action Items

Owner Action Timing
Aaron Share detailed Worship Harvest financial model and assumptions with Hillary and Dansturn Immediately
Hillary Review the proposed inverter, battery, PV and peak-demand assumptions Before customer pitch
Dansturn Review the model from both engineering and Worship Harvest/customer perspectives Before customer pitch
Dansturn Help confirm actual generator configuration, site loads and operational practices Next review
Dansturn Facilitate access to Worship Harvest decision-makers After internal review
NFE team Determine suitable metering location after the grid/generator changeover Phase 1 design
NFE team Capture generator consumption as well as utility consumption Phase 1
NFE team Develop 15-minute or finer load-data collection plan Phase 1
NFE team Reassess whether 50 kW inverter / 120 kWh battery is sufficient After load data
Aaron Refine commercial model to include avoided diesel and generator costs Next model revision
Aaron Explore project/bank financing model rather than assuming full NFE self-financing After model validation
Hillary Locate/share Uganda electricity meter rules / UNBS requirements Before/during Nairobi workshop
NFE team Ask workshop experts for the practical Street EMS certification pathway Nairobi workshop
Hillary Investigate OpenAMI/DLMS/COSEM architecture in more detail Nairobi workshop
Aaron Reshare relevant Street EMS / Energy IoT technical documents on Element Before workshop
NFE team Leave Nairobi with a solid end-to-end understanding of Street EMS architecture Workshop objective
Aaron / team Add the AI-assisted AutoCAD/design workflow discussion to next week's agenda Next weekly meeting

The three things I would carry forward most prominently

The biggest development from this meeting is that the Worship Harvest opportunity appears stronger than the utility bills alone suggested. Generator use is not merely backup for outages; it is being used proactively because reliability during important events is valuable. That avoided diesel and generator spend should therefore become a first-class part of the financial model.

Second, the current system sizing should remain provisional. A 6.9 MWh/month customer can still have a very high peak demand, and the 200 kVA generator is a strong warning against sizing a system primarily from monthly kWh.

Third, the clearest technical objective for Nairobi is now quite specific: understand what it would take to turn Street EMS from promising open hardware into a metering platform NFE can legally deploy and bill through in Uganda. That makes certification, calibration and the software architecture especially valuable questions for Glenn and the other experts.

Community Checkins

NFE Checkin - October 3rd 2026 - Q4 Planning

Agenda 

Opportunity Map 

Culture, Vision and Values

What you can expect from our culture and distributed work environment.

Culture, Vision and Values

Vision, Strategy, Key Results

Vision

Thriving Communities 

ChatGPT Image May 20, 2025, 04_49_44 PM.png

Strategy 

Advancing Sustainable, Reliable, Affordable Energy through resilient Community Owned Microgrids. We build and operate these microgrids and teach others how to do the same. 

Future.jpeg

Key Results 

Completed

Now

Next

Later

Culture, Vision and Values

Collaboration Tools

Overview

This page contains useful tips for working at NFE and for various tools we use. These tools can be found at dashboard.NearlyFreeEnergy.com

Email and Celandar with NextCloud 

Email and Calendar 

Documentation with Bookstack 

Wiki / Documentation  

Kimai for Time tracking 

Time tracking 

Company Website with Wordpress 

Website 

Group Chat with Matrix and Element 

Group chat 

Code Repository with Gitea 

Version Source Control 

Customer Help desk with Freescout 

Customer Help desk 

CRM with Espo 

Customer Relationship Management (CRM) 

Project Management with Plane

You can access plane here and their documentation. 

Video Calls with Jitsi

Jitsi is an important part of GitLab’s strategy for communication between team members. As such, extra care needs to be given to ensure the safety and integrity of data. For how to use Jitsi, refer to their official documentation

Scheduling Meetings with Calcom

Most of our work is asynchronous but we'll occassionally need to meet with each other and with external stakeholders. This is what Calcom is for. It's Free Software like most of our tools so you can search online for more information on how to use it. Here's how you can set up your NFE account. 

In Nextcloud Calendar, hover over the link icon to the right of the calendar in question, e.g. Personal, and you see an edit icon. Click the edit icon:

image.png


You'll see a pop-up like the following. You will want to click the + for "Share link" and then clck the resulting clipboard icon that copies the link to the clipboard:

image.png


Then, you'll want to go to your Cal.com pop-up for configuring CalDav and paste the link:

image.png


Then continue the process of connecting to your Nextcloud calendar via CalDav, confirming event creation:

image.png


Complete the remaining steps. You can leave video settings for later. Confirm your availability times. Add a profile photo / avatar.
Culture, Vision and Values

Values


Collaboration

We are better Together: If you want to go quickly, go alone but if you want to go far, go together

Curiosity

Always learning, frequently questioning and listening. 

Community 

Default to Openness. We want to learn and build in public so that others who care about what we are working on can also learn and consider contributing to our mission. They'll be a few things that need to be private like our customers contact information but we aim to be open about how and what we are working on. So when in doubt, just share it.

People first

Relationships count most, invest in them. We want to give reach other room to center our lives around family and friends, not our jobs. 

Managers of One

People need to be reminded more often than they need to be instructed. What it means to be a manager of one. 


Culture, Vision and Values

Culture - how we work

Most of our work is asynchronous, this is the best way for people in different timezones, schedules and places to effectively collaborate. The people at Gitlab wrote a good guide on asynchronous work, please go read it. 

Here's some tips from Aaron

Culture, Vision and Values

NFE is a Social Venture!

Our Identity

We, Nearly Free Energy (NFE), operate as a social enterprise — a mission-driven business committed to providing affordable, sustainable energy solutions while generating profit in a responsible and inclusive manner.

Our Purpose

Nearly Free Energy exists to:

Our Core Principles

We are guided by the following values:

People-Centered Impact

We prioritize the needs, dignity, and aspirations of the communities we serve. Our solutions are co-designed with our users, and we strive to create long-term value and inclusion.

Environmental Stewardship

We commit to environmental sustainability in our products, services, and operations — advancing renewable energy efficiency solutions to reduce reliance on fossil fuels.

Financial Sustainability

We operate for profit to ensure our longer-term viability. We reinvest earnings in innovation, infrastructure, and impact — balancing financial returns with social outcomes.

Transparency and Accountability

We share our goals, progress, and challenges openly with our stakeholders. We maintain integrity in our dealings with customers, employees, partners, and investors.

Community Partnership

We build local capacity and respect local knowledge. We collaborate with community organizations, public agencies, and other enterprises to maximize shared value.

Governance and Decision-Making

Reporting and Learning

Our Long-Term Vision

We envision a world where energy is:

Till every community can sustain their energy needs.  

Culture, Vision and Values

Co-op Resources from Startup.coop

We also encourage you to check out our free Lean Co-op course if you haven’t already and see if there are local resources within the Cooperation Works network who can continue to help you refine your vision! 


We have also listed advocacy, technical assistance, financing and general startup resources on the build and resource pages of our website.  And have provided a list of additional resources below:

Glossary

NFE Acronym Glossary

This glossary consolidates acronyms used across the NFE BookStack. It covers business, energy, metering, software, finance, logistics, and regulatory terminology. Product model numbers and register codes are excluded unless they are genuine acronyms.

Inventory reviewed: 134 BookStack pages. Last updated: 27 August 2026.

AcronymMeaningNFE context
A2EIAccess to Energy InstituteEnergy-access research and data organization.
ACAlternating CurrentElectrical current that periodically reverses direction.
ADRArchitecture Decision RecordA durable record of an important technical decision.
AfDBAfrican Development BankRegional development-finance institution.
AIArtificial IntelligenceSoftware techniques used for prediction, automation, or decision support.
AMIAdvanced Metering InfrastructureMeters, communications, and systems used for remote measurement and management.
APIApplication Programming InterfaceA defined interface through which software systems exchange data or commands.
BESSBattery Energy Storage SystemA battery installation together with its power conversion, controls, and protection.
BMSBattery Management SystemElectronics that monitor, protect, and control a battery pack.
BOMBill of MaterialsItemized list of components required to build a system.
BOQBill of QuantitiesItemized estimate of materials, work, quantities, and costs.
BYDBuild Your DreamsBattery and electric-vehicle manufacturer referenced in procurement research.
CIFCost, Insurance, and FreightShipping-price basis that includes the goods, insurance, and freight to the destination port.
CIUCustomer Interface UnitCustomer-facing device used to interact with a meter, commonly for prepaid metering.
COSEMCompanion Specification for Energy MeteringObject model used with DLMS for energy-meter data.
CRMCustomer Relationship ManagementSystem for managing customer information and interactions.
CTCurrent TransformerSensor that scales electrical current for safe metering or protection.
DCDirect CurrentElectrical current flowing in one direction.
DCIDriver, Consulted, InformedNFE decision-ownership framework identifying who drives, advises, and is kept informed.
DCUData Concentrator UnitDevice that aggregates data from multiple meters for upstream communication.
DERDistributed Energy ResourceSmall-scale generation, storage, or controllable load connected within a distribution network.
DLMSDevice Language Message SpecificationApplication-layer standard used to exchange utility-meter data.
DRIDirectly Responsible IndividualThe person accountable for driving a task or outcome.
DTUData Transfer UnitCommunications device that relays field-device data to another system.
EACUEast African Customs UnionRegional customs framework relevant to imports into Uganda.
EMSEnergy Management SystemSoftware and controls used to monitor and optimize energy flows.
ERAElectricity Regulatory AuthorityUganda's electricity-sector regulator.
ESMAPEnergy Sector Management Assistance ProgramWorld Bank energy-sector technical-assistance program.
ESSEnergy Storage SystemA storage asset and its associated controls and power electronics.
EVElectric VehicleVehicle propelled partly or entirely by electric power.
FCLFull Container LoadShipping arrangement in which one consignee uses a full container.
G3-PLCG3 Power Line CommunicationPower-line communications technology used by smart-grid devices.
GCPGoogle Cloud PlatformGoogle's cloud-computing platform.
GFFGreen Future FoundationOrganization referenced in NFE fundraising materials.
GUIGraphical User InterfaceVisual interface through which a person operates software.
GxFGrid eXchange FabricOpen smart-grid software platform evaluated by NFE.
IECInternational Electrotechnical CommissionInternational standards body for electrical and electronic technologies.
IEEEInstitute of Electrical and Electronics EngineersProfessional association and technical-standards organization.
IDISInteroperable Device Interface SpecificationsInteroperability profile for DLMS/COSEM smart-meter implementations.
IoTInternet of ThingsNetworked physical devices that collect data or receive commands.
IPCInsulation Piercing ConnectorConnector that makes contact through a cable's insulation.
ISVIEEE Smart VillageIEEE program supporting energy access and community development.
LCLLess than Container LoadShipping arrangement in which cargo shares a container.
LFPLithium Iron PhosphateLithium-ion battery chemistry commonly written LiFePO₄.
LVLow VoltageLow-voltage portion of an electrical distribution system.
MBEMetering and Billing EngineNFE software capability for turning meter data into customer billing records.
MoUMemorandum of UnderstandingDocument recording intended cooperation between parties.
MPMMicrogrid Power ManagerNFE's microgrid control and management product concept.
MQTTMessage Queuing Telemetry TransportLightweight publish/subscribe messaging protocol commonly used by IoT systems.
NCMNickel Cobalt ManganeseLithium-ion battery cathode chemistry.
NFENearly Free EnergyThe organization and cooperative developing the NFE Microgrid OS.
NPVNet Present ValuePresent value of future cash flows minus investment cost.
OBISObject Identification SystemStandard identifiers for measurements and data objects in utility meters.
OEMOriginal Equipment ManufacturerCompany that manufactures a product or component sold under its own or another brand.
OSOperating SystemIn 'Microgrid OS,' the coordinating software layer for microgrid operations and services.
OSGPOpen Smart Grid ProtocolOpen protocol suite for smart-grid communications.
PDUPower Distribution UnitAssembly that distributes and protects electrical power to downstream circuits.
PFPower FactorRatio of real power to apparent power in an AC circuit.
PLCPower Line CommunicationCommunication that carries data over electrical power conductors.
PRPull RequestProposed set of source-code changes submitted for review and merging.
PVPhotovoltaicConversion of sunlight into electricity; commonly refers to solar panels or arrays.
ROIReturn on InvestmentGain or value produced relative to investment cost.
RS-485Recommended Standard 485Differential serial communications standard widely used with Modbus field devices.
RTURemote Terminal UnitIn Modbus RTU, the compact binary serial framing commonly used over RS-485.
SCADASupervisory Control and Data AcquisitionSystem for monitoring and controlling distributed industrial equipment.
SEFASustainable Energy Fund for AfricaAfDB-managed fund supporting sustainable-energy projects.
SOCState of ChargeEstimated percentage of usable energy remaining in a battery.
SSHSecure ShellEncrypted protocol for remote command-line access.
SSRSolid-State RelayElectronic switching device with no moving contacts.
TCPTransmission Control ProtocolReliable, connection-oriented internet transport protocol.
TLSTransport Layer SecurityProtocol that encrypts and authenticates network connections.
TOUTime of UseTariff or operating schedule that varies by time period.
UEDCLUganda Electricity Distribution Company LimitedUgandan electricity distribution company and macrogrid operator referenced by NFE.
UGXUgandan ShillingISO 4217 currency code for Uganda's currency.
UNBSUganda National Bureau of StandardsUganda's national standards body.
URAUganda Revenue AuthorityUganda's tax and customs authority.
USBUniversal Serial BusStandard wired interface used for peripherals and serial adapters.
USDUnited States DollarISO 4217 currency code for the United States dollar.
VATValue Added TaxConsumption tax applied to the value added to goods and services.
VMVirtual MachineSoftware-defined computer running within a physical host.
VNCVirtual Network ComputingProtocol for remotely viewing and controlling a graphical desktop.
VPNVirtual Private NetworkEncrypted private network carried over another network such as the internet.
WSSWebSocket SecureWebSocket communication protected by TLS.

ByLaws


ByLaws

Welcome

This work, "NFE Bylaws", works as the operating agreement for Watt Works Foundation Limited and is a derivative of "Ampled ByLaws and East Bay Permanent Real Estate Cooperative Bylaws" by theselc.org, used under CC BY-SA 4.0.

Our Bylaws

This is the guidebook for NFE. This document explains how shared ownership model works, how decisions are made, and how profit is shared.

These Bylaws provide guidance for Watt Works Foundation Limited (dba NFE), our desire is to empower each other to steward NFE's vision well and go beyond simply following the letter of the bylaws. 

We think having the ByLaws in place can be a helpful safety net when conflict inevitably arises but we expect and encourage 1:1 conversational deliberations rooted in our values to be the first tool we reach for to resolve conflicts peacefully. 

ByLaws

Mission and Values

Mission

We are here to advance energy resilience using community owned sustainable energy microgrids. 

Values 

Collaboration

We are better Together: If you want to go quickly, go alone but if you want to go far, go together

Curiosity

Always learning, frequently questioning and listening. 

Community 

Default to Openness. We want to learn and build in public so that others who care about what we are working on can also learn and consider contributing to our mission. They'll be a few things that need to be private like our customers contact information but we aim to be open about how and what we are working on. So when in doubt, just share it.

People first

Relationships count most, invest in them. We want to give each other room to center our lives around family and friends, not our jobs. 

Managers of One

People need to be reminded more often than they need to be instructed. What it means to be a manager of one. 

Five dysfunctions

Our values also help us to prevent the five dysfunctions:

  1. Fear of conflict Seeking artificial harmony over constructive passionate debate => prevented by transparency, specifically Managers of One and Collaboration. 
  2. Absence of trust Unwilling to be vulnerable within the group => prevented by Collaboration, specifically People first. 
  3. Avoidance of accountability Ducking the responsibility to call peers on counterproductive behavior which sets low standards => prevented by Community. 
  4. Inattention to results Focusing on personal success, status, and ego before team success => prevented by Managers of One
  5. Lack of commitment Feigning buy-in for group decisions creates ambiguity throughout the organization => prevented by Community and Managers of One

Some dysfunctions are not addressed directly by our values; for example, trust is not one of our values. Similar to happiness, trust is something that is an outcome, not something you can strive for directly. We hope that the way we work and our values will instill trust, instead of mandating it from people; trust is earned, not given

ByLaws

Ownership

NFE is owned by the community of people contributing to NFE's mission. 

Owners or Members

Owner-member is the term we use to refer to people NFE recognizes as owners or members of the NFE co-operative.

Workers

Funders 

Customers

Please note that NFE membership is voluntary. Individuals or organizations can be funders, workers or customers and chose not to apply for member/ownership. 

Responsibilities of Owner-Members

Benefits of Owner-Members 

Suspending Membership 

Non Owner Community Members 

Not all our stakeholders are currently eligible for becoming members but are still part of the community so theoretically could be owners in the future. 


ByLaws

Board of Directors

This group are the guardians of the NFE mission. They help steer and make all major decisions. 

Board Members 

Responsibilities 

Board Elections

Board member removal 

Binding NFE

The Secretary or Chairperson or CEO may sign a document or make a binding commitment on behalf of NFE. The Board may designate other people through a board resolution, to do the same.

ByLaws

Directly Responsible Individuals

NFE is a community owned organization but we rely very little on consensus to make most decisions. Directly Responsible Individuals (DRIs) at NFE own particular projects, initiatives, or activity and make most decisions concerning those areas. 

What is a directly responsible individual?

Apple coined the term “directly responsible individual” (DRI). The idea is that every project is assigned a DRI who is ultimately held accountable for the success (or failure) of that project.

They likely won’t be the only person working on their assigned project, but it’s “up to that person to get it done or find the resources needed.”

DRIs may be a lead or senior or associate worker. The selection of a DRI and their specific role will vary based on their own skillset and the requirements of their assigned task. What’s most important is that they’re empowered.

While the DRI is the individual who is ultimately held accountable for the success or failure of any given project, they are not necessarily the individual that does the tactical project work. The DRI should consult and collaborate with all teams and stakeholders involved to ensure they have all relevant context, to gather input/feedback from others, and to divide action items and tasks amongst those involved.

Empowering DRIs

It is important to understand that DRIs do not owe anyone an explanation for their decisions. If you force a DRI to explain too much, you’ll create incentives to ship projects under the radar. The fear of falling into a perpetual loop of explaining can derail a DRI, and cause people to defer rather than working with a bias for action.

We would much rather foster a culture where DRIs are willing to put their ideas in the open. This enables feedback from a broad range of diverse perspectives, which the DRI can take into account and choose how (if at all) it shapes their thinking.

Communication and feedback

A DRI should be able to articulate the objectives, check progress and give and receive feedback. This will ensure the DRI can change direction or plan ahead to avoid any setbacks.

At NFE we communicate and work asynchronously, you can read more about it on this page.

One thing to consider when a DRI needs to give or receive feedback is that they may not be the actual manager of the other members of the team.

DRI, Consulted, Informed (DCI)

Different organizations use different methods of assigning responsibility; one of the most popular is the RACI Matrix, which outlines who the Responsible-Accountable-Consulted-Informed people should be on a decision or project.

GitLab’s implementation of a DRI for decision-making means that we have evolved the RACI matrix to DCI (DRI, Consulted, Informed).

The Responsible and Accountable person is the DRI, the Consulted people are those whose opinions are sought, typically subject-matter experts; and with whom there is two-way communication. and Informed people are those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication. 

Circumstances Requiring the Rare Need for Approvals

ByLaws

Surplus Sharing

What and why

If, instead of surpluses, there are losses, the losses will be allocated in any manner that the Board determines to be fair and equitable, in consideration of the circumstances leading to the loss.

How Surplus is Distributed

ByLaws

Will & Testament

How NFE will close 

Any proposal to sell, dissolve, or liquidate NFE or it's projects must be approved by 2/3 of the board. In such an event, after paying or adequately providing for all debts, liabilities, and repayment to contributors, NFE shall make payments in following the procedures described under “Surplus Sharing”

Defending and Compensating members

NFE shall have the power to indemnify its Workers, Customers, Funders and their agents to the fullest extent permitted by law. NFE shall compensate a Worker, Customer or Funder for any expenses incurred from lawsuits, penalties, fines, and costs of defense if the person incurred these expenses in connection with fulfilling their duties as a Worker, Customer or Funder. This is also called “indemnification.”

However, NFE is not obligated to “indemnify” a person if such expenses arose from a situation where the person stole funds, knowingly received funds they were not entitled to, intentionally committed a crime, or recklessly or intentionally harmed NFE or its members.

ByLaws

Changing Bylaws

Prior to the first Board election, these Bylaws may be changed by approval of a majority of Initial Worker-Owners.

Once a Board has been elected, with exceptions listed below or on a specific Bylaws page, these Bylaws may be changed by approval of 2/3 of Board at a duly called Owner meeting, or by 2/3 of those voting by electronic ballot duly submitted to Owners, so long as a quorum participates. All elections should provide at least 15 days prior notice. 

Exceptions include:

Ownership (Membership)

This project is community owned as per the model described here. 

This the membership for NFE co-operative. 

Funders 

Workers 

Customers 

Membership

Workers 

Funders 

Customers 

Advisors 


Roadmap

Now 

Next 

Later 

Released

Financial Model Game plan - Q2

🎯 The 3 Goals

  1. Microgrid unit economics model

  2. Fundraising narrative

  3. Stress test your monetization models (Owned vs Partner)

🧭 Phase 1 (Week 1–2): Build Financial Clarity (Foundation)


1) Microgrid Unit Economics Model


What you’re building


A per-site financial model that answers:


“If we deploy one microgrid, does it make money?”

Step 1: Define core inputs


Start simple (don’t overcomplicate):


Costs (CapEx)


Revenue


Operating costs (OpEx)

Step 2: Build outputs


You want 5 key metrics:

Step 3: Answer key questions

Deliverable


👉 A simple Google Sheet model (I can help you structure this next)

🧭 Phase 2 (Week 2–3): Stress Test Your Two Models


Now apply the model to your two strategies:

Model A: NFE-Owned Microgrid


What to evaluate


Key insight you want:


“How fast can we scale before we run out of cash?”

Model B: Partner-Owned Microgrid


What to evaluate


Key insight:


“Is this a high-margin, low-capex business?”

Compare side-by-side

Metric

NFE-Owned

Partner Model

Capital required

High

Low

Margin

High (long-term)

Lower but steady

Risk

Higher

Lower

Speed of scale

Slower

Faster

Strategic output


You should be able to say:


👉 This becomes core to your pitch

🧭 Phase 3 (Week 3–4): Build Your Fundraising Narrative


Now turn your numbers into a story investors understand

1) Problem (you already do this well)

2) Solution (tighten this)

3) Business Model (now backed by numbers)


Use your model to clearly show:

4) Traction

5) Scaling Strategy (THIS is key)


From your analysis:


Example:

6) Use of funds


Your model should let you say:

Deliverable


👉 A clean 8–10 slide pitch (or 1–2 page memo)

🧭 Phase 4 (Week 4–6): Add Financial Discipline


This replaces what a CFO would start doing.

1) Monthly financial tracking


Track:

2) Define 5 core KPIs


For NFE, I’d suggest:

3) Cash planning (critical)


Build a simple view:

⚠️ Critical mindset shift

You’re moving from:


“We are building microgrids”


to:


“We are deploying capital into energy assets that must return money”


That shift is what investors care about.

🧩 How this all connects