Software for the grid

// The problem

A distribution utility inspects poles, lines and transformers on paper forms, and defects reach the work plan late, often missing photos and locations.

// What we would build

An iOS and Android app for inspectors and crews that works offline on a map of the network, with structured inspections, photos and defects that become work orders, and a web back office for planners tied to the GIS and the asset system.

// What is in it

// Stack

• React Native
• Next.js
• PostgreSQL with PostGIS
• Esri ArcGIS APIs
• IBM Maximo or SAP integration
• Microsoft Azure

// The problem

Control room operators and field supervisors search binders and shared drives for the right switching procedure, operating instruction or manual, often in the middle of an event.

// What we would build

An assistant that answers from your own procedures, operating instructions and past switching orders, citing the document and section, on an open-source model running on a server inside your network so nothing touches the internet. It reads and cites; it never operates equipment.

// What is in it

// Stack

• Llama or Mistral (open-source)
• vLLM
• PostgreSQL with pgvector
• Next.js
• Lenovo GPU server on site

// The problem

An energy retailer buys renewable output from several independent generators and resells the attributes to corporate customers, and tracking it in spreadsheets means nobody can prove a certificate was not sold twice.

// What we would build

A private permissioned ledger where generators, the retailer and an independent verifier each run a node: metered output becomes certificates, each certificate is assigned or retired once, and customers get a statement they can check. Where an official tracking registry covers your market it stays the record of title, and this ledger handles the contracts and matching around it; if one party is trusted by all, a database does the same for less.

// What is in it

// Stack

• Hyperledger Besu (private, permissioned)
• Solidity
• Next.js
• PostgreSQL
• Microsoft Azure

// The problem

A distribution planner forecasts load per feeder from last year's peaks, while heat pumps, EV chargers and rooftop solar change demand faster than the spreadsheet can follow.

// What we would build

A custom forecasting model, fine-tuned from an open time-series foundation model on your own meter, feeder and weather history, that forecasts load per feeder for the days and seasons ahead, with a web view for planners. A custom model fits because the patterns are yours and the data is sensitive; it is retrained as new meter data arrives.

// What is in it

// Stack

• PyTorch
• Chronos or TimesFM (open time-series models)
• Python
• Next.js
• PostgreSQL with TimescaleDB
• AWS GPU

// The problem

A distribution utility's reliability figures are compiled by hand each quarter from the outage system, crew records and customer counts, and the answers change depending on who ran them.

// What we would build

An analytics store loaded every night from your outage, work management and customer systems, with one agreed way of counting interruptions, maps of where they cluster, and the regulator's reliability indices produced from the same data.

// What is in it

// Stack

• PostgreSQL with PostGIS
• dbt
• Apache Superset
• Python
• DigitalOcean

// The problem

A utility's asset map, work order system and customer system each hold their own copy of the network, and crews find the differences in the field.

// What we would build

An integration that keeps assets in step between your GIS, work management and customer systems, sends field changes back to the map for a person to approve, and lists every record the systems disagree on until someone resolves it.

// What is in it

// Stack

• Node.js
• PostgreSQL with PostGIS
• REST
• OpenAPI
• DigitalOcean