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.

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 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