Q1 2026 - Product & Engineering Roadmap

Q1 2026 - Product & Engineering Roadmap

The following is a guidline for work being done by the sustainability backend team. In addition to the roadmap below we are also driving the discussions with current and potential customers in Amazon GREF and WWOps (EU Water, US Water, etc.), and meeting their needs for monitoring and maintenence of the LoRaWAN Platform (aka “BMS”).

Projects and Ownership

There are several projects worked on by the Sustainability engineering team. Atria and Gref work is currently in development, and the LoRaWAN Platform and Wirefree Quicksight Dashboards are considered under maintenance, with tasks and adjustments made to support our relationship with Amazon and their business needs.

The following are the product owners associations to each given project, who expect direct reports regarding updates to the given project.

Atria - Kristie Lanum (Milvian)

LoRaWAN Platform (BMS) - Francesca Stobbione (EU Amzn) / Nicholas Harrison (NA Amzn)

Wirefree Quicksight Dashboards - Francesca Stobbione (EU Amzn) / Nicholas Harrison (NA Amzn) / Leo Liu (Amzn)

GREF - Nathan Wesselius (Amzn)


Atria Roadmap

1. Complete the Site Survey Application (Top Priority)

Status: Two feedback rounds completed
Goal: Finalize the application and enable automated reporting
Key Tasks:

Implement automated email reporting upon survey submission
Conduct final QA and resolve outstanding bugs
Deploy the application and close out the project

2. Atria Dashboards Applet (React-Based Analytics Dashboards)

Objective: Develop a new Atria-integrated applet to present WWOps data through customizable dashboards. This should open us up to future work with WWOps developing these tools.
Key Components:

Applet shell embedded within Atria
Dashboards built in React using responsive analytics libraries
Support for add-on dashboard configurations
Tagging system for user-based access control
Deploy the application and close out the project
Primary Outcomes:
Real-time operational and leadership visibility
Reduced manual reporting workload
Scalable analytics infrastructure
Secure access to data analytics

Dashboards

Water Dashboard
KPI Dashboard
Site Report Dashboard

3. Continuous Platform Improvements

Ongoing engineering efforts to enhance and evolve the platform.

Upcoming Focus Areas:

Pulse Rate Installation Modal/Calculator for the Installation app
Installation Summary improved import of legacy devices (from before Atria)
Implement Generic Data Verification Method for Sensor Reporting
Phase 1: Applet
Phase 2: Addition to the existing Installer
Phase 3: Addition to existing Site report
Phase 4: Enabling notification/chime for it
UX and usability enhancements
Timestream data cleanup effort across multiple India’s sites to correct excessively high Water Flow (GPM)
Other ticketed improvements and bug fixes

User Profile & Accessibility Initiatives:

Centralized user profile page for viewing/editing details, managing personal info, and secure account deletion

3.1 Data Verification Stack

Data is verified as accurately reporting before installers leave site.
Also notifications for battery check, device downs etc

3.2 Notifications

Operators are made aware of issues as per their subscribed Chimes in the app, or via email (this integrates with verification)

Email notification architecture design will need Outlook integration.

3.3 KPI Dashboards

KPI Report in Atria that displays important metrics for the Sites. It will display device numbers twice per month basically how many gateways, sensors and sites are live at any given time and download the report on monthly basis.

3.4 Subeca Calibration check and reminder

Subeca meters require annual calibration. This process needs to be recorded in Atria, and notifications should be sent prior to calibration.

3.5 Users

Users are present, and settings can be configured via their profile page.

3.6 Data Security

The Site Report is transformed into a Dashboard and placed within the Dashboards Applet to allow per-user restricted access to comply with Amazon.


4. GREF (Global Real Estate and Facilities) - Atria - Amazon

Objective:
Deploy a GREF-specific version of the Atria application in the GREF AWS account, leveraging their AWS infrastructure, Git repository, CI/CD processes, tooling, and engineering standards.

Post-migration, a new applet - tentatively called “GREF Device & Site Health Report” - will be developed and deployed within that Atria instance. The applet will consume data from GREF-provided APIs and provide site/device health and telemetry information to installers and other team members, enabling them to verify installation and device configuration status and confirm successful site/device setup.

This will be executed as a SoW-based engagement, creating a direct revenue opportunity for Atria and enabling possibility of future development/related work within Amazon/GREF environments.

Note:
Currently in the initial phase. Work is expected to begin soon - before the end of Q1 - and continue into early Q2.

Key Phases:

Discuss migration strategy, estimated timeline, and documentation with GREF
Scope, High-level milestones and LoE document - GREF and Milvian
Milvian’s LoE preparation - Milvian
SoW preparation - Milvian
Perform Atria migration to GREF environment
Develop the new applet
GREF APIs integration
Test and deploy the new applet
Documentation / project closeout

Work Across All Phases:

  • Resolve issues with GREF CI/CD pipeline, AWS environment, scanning tools, testing etc.

  • Bug fixes and unforeseen issues.

Expected Outcomes:

  • Address GREF security and governance requirements

  • Replace the existing email-bot workflow with a more efficient application-based solution

  • Enable installers and other members to perform real-time installation/device config verification

  • Provide a robust and scalable solution that directly consumes data from GREF APIs, removing SES-related roadblocks


5. QR Code & Ticket Printer System for Device Identification (Backlog)

Goal: Eliminate manual EUI entry for installers.
Planned Deliverables:

QR code generation for device EUIs
Integration with ticket printers
Installer-facing QR scanning workflow
Backend validation and provisioning support

6. Device Qualification Application (Backlog)

Goal: Provide Provisioners with a tool to qualify devices and document behavior or troubleshooting.
Core Features:

Guided qualification workflows
Data capture for performance, anomalies, and signal metrics
Automated knowledge base generation
Searchable reference history

7. Aqueduct Atria, Fork and Refactor (New Work!)

Goal: Replicate and tailor Atria for deployment in Milvian Aqueduct environments and BMS solutions as an installation solution.
Core Features:

Avoid reproduced work creating a system for device provisioning, installation, and more
Build upon a strong foundation of shared assets with other Atria forks following the same patterns
Maintain felxibility for variable BMS infrastructure
Rapid deployment with a CDK infrastructure

8. LoRaWAN platform update for CloudGate devices support(Egypt project) (New Work)

It has been determined that in order to use LoRaWAN gateways in Egypt, Milvian would need to become a licensed network operator in Egypt. This is not a feasible option. Therefore, we have identified an alternative solution: CloudGate—a cellular device that acts as both a gateway and a pulse counter and does not use LoRaWAN technology.

Goal: Enable deployment in Egypt without LoRaWAN operator licensing by supporting CloudGate devices as an alternative to LoRaWAN gateways.

Planned approach:

Implementation document — Define scope, architecture, and integration approach for CloudGate support.
Schedule — Finalize timelines and milestones once the dates are finalized for the Egypt project.
Implementation — Execute development and rollout per the documented plan.

Notes:

The backlog items from the list above are secondary priorities for Q1, and we’ll likely target these in Q2 unless higher priority business opportunities present themselves. We are also in the meantime available for support for our hardware team, meeting their needs.

The future of Atria and the work we have done here could be forked and refactored in order to replicate its successes for other platforms (such as GREF, Aqueduct, or other clients with an installation solution requirement for these devices) and as such our methodology should reflect the potential for this work in the future.

As maintenance requests for Wirefree Quicksight Dashboards, LoRaWAN Platform, and GREF come in from their respective owners, we will pivot and support their asks as best we can, and demonstrate our commitment to provide competent BMS solutions for to meet their needs.


Summary List (Current Priorities)

  1. Complete Site Survey Application

  2. Atria Dashboards Applet

  3. Platform Enhancements (including Pulse Rate Modal, User Profile, Accessibility)

  4. QR Code & Ticket Printer System

  5. Device Qualification Application