NatPower
- role
- Full-stack engineer
- client
- NatPower (renewable energy developer, UK and Luxembourg)
- stack
- Ruby on Rails, PostgreSQL, Sidekiq, AWS
- when
- About a year
- outcome
- Built the internal Rails platform NatPower's ops team uses to track project pipeline status across countries
- demo
- live
The company
NatPower is an independent developer of renewable energy projects, founded in 2019 and headquartered in Luxembourg, with offices in Milan, London, Washington D.C. and Almaty. It runs active development across five countries — Italy, UK, Kazakhstan, US and Canada — spanning three lines of business: solar, wind and hydro projects sold at ready-to-build stage or in operation; battery storage (BESS) developed and operated through investment platforms; and two specialized units, NatPower Marine (clean-energy charging for the maritime sector) and NatPower H (green hydrogen production and refuelling).
(Written from their public site. Check it still reads true before publishing.)
The problem
Five countries, five regulatory regimes, and three different business lines (development-and-sale, BESS investment platforms, marine/hydrogen) meant a project’s status — which permit stage, which land agreement, which milestone — lived in spreadsheets that were only as current as the last manual update. Nobody had one place to see the pipeline across countries or business lines.
What I built
An internal Rails platform modeling the pipeline as projects, sites, permits and milestones, each scoped to a country and a business line, with a backend API and a plain internal-tool front end for the ops team to update and read status across all five countries in one place. Slow external lookups (permitting and GIS data) run as Sidekiq background jobs instead of blocking the request.
Decisions and tradeoffs
- Rails and Postgres over a low-code/spreadsheet tool, because the domain (project → site → permit → milestone, each with history) needed real relations and an audit trail, not a flat table.
- Background jobs for anything touching a slow external data source, so the UI stays responsive regardless of how long an external lookup takes.
- Deliberately plain UI: the audience was a small internal ops team, not customers, so polish took a back seat to getting the data model right.
Outcome
Ops team could see pipeline status without asking someone to compile it. No public metric to point to — this is internal tooling, not a customer-facing product.