Home
Portfolio
NYC Building Performance Assistant
NYC Building Performance Assistant
NYC Building Performance Assistant

How MEV Built an AI Sustainability PoC in 72 Hours

1st place
1st place
Judged on code quality, AI integration
7 AI agents
7 AI agents
One job each, with a sign-off at every handoff
72 hours
72 hours
From open dataset to working PoC
How MEV Built an AI Sustainability PoC in 72 Hours
Tech Stack
React 19 / TypeScript / FastAPI / Python 3.13 / PostgreSQL 16 / pgvector / scikit-learn / Claude / DigitalOcean / Alembic / Stripe
Project duration
A global electronics company’s AI innovation unit

[ product overview/ ]

MEV worked on the project within a 72-hour innovation challenge run by a global electronics company's AI innovation unit. It served as a working demonstration of a proposed external, AI-first Innovation Pod designed to help internal venture teams turn early concepts into functional prototypes and MVPs within six to eight weeks.

The organizer gave us NYC's Local Law 84 data and left each team to define the product and its users.

New York City requires its large commercial buildings to report energy use every year, and the worst performers face growing penalties. This dataset could serve several roles. We picked one for our proof of concept (PoC), the Building Performance Analyst, and shaped the app around this user persona.

The app reads the city's public energy data and shows the analyst which buildings waste the most energy, then recommends a fix for each one with projected costs and payback periods. By hour 72 the PoC was ready, and it took first place.

The team built a map-first platform for benchmarking building sustainability across 30,000 New York City buildings. A Building Performance Analyst can spot underperforming properties and compare them against relevant peers. The platform also flags LL97 penalty exposure, the fines NYC charges large buildings that exceed their carbon limits.

For each building, the platform returns a grounded retrofit recommendation: the projected energy savings, plus what the fix costs and how long it takes to pay back.

The PoC also included Stripe-based Pro and Enterprise subscription tiers, with AI recommendation limits enforced by the user's plan. Alongside the core analytical workflow, this showed a possible commercial model.

We won using the same approach we run in MEV's AI Innovation Lab. It’s our practice for taking an idea to working software on a set timeline and budget, run by senior engineers who reuse production patterns across projects.

It ships that work through the MEV Innovation Lab Delivery System, a gated pipeline of single-job AI agents that pass work down the line: plan to code, code to review, review to fix, with an engineer sign-off at each end.

The Benchmarking Platform
(Sustainability Benchmarking Platform)
(Sustainability Benchmarking Platform) 1
(Sustainability Benchmarking Platform) 2
(Sustainability Benchmarking Platform) 3
(Sustainability Benchmarking Platform) 4
(Sustainability Benchmarking Platform) 5

Jobs MEV Solved in This Project

The 72-hour timeline and a raw public dataset defined four jobs to solve.
01:
Scope one product from a 30,000-building open dataset
02:
Design a three-day PoC to our production standards
03:
Move fast while ensuring code quality
04:
Keep the infrastructure below $50 per month

[ how we did it/ ]

Solution & Implementation
01:
Picked one user and mapped the journey first
On the first day we chose one user from the several the data could serve, a Building Performance Analyst, who answers for energy performance across a real estate portfolio. We locked that role down and mapped the journey before tackling code.
Result: Every feature mapped to one role's responsibilities and flows, so no screen got rebuilt later.
02:
Ran seven single-job AI agents through a gated pipeline
We ran the build through seven agents, each with a single job: architect, builder, reviewer, fixer, security-reviewer, design-reviewer, and todo-finder. They ran on Claude Code, and passed work down the line: plan to code, code to review, review to fix.
AI Integration
Three-Layer AI Architecture
AI Integration
AI Agent Pipeline
Seven AI agents inside the MEV Innovation Lab Delivery System
AI Agent Pipeline
One command with a ticket number, ran that chain from a task to review-ready code. Each agent works from an agent spec kept beside the code and version-controlled.

View the Seven Agent Specs Used on this Project on GitHub.

View on GitHub 
Result: The agents handled most of the repeatable work: planning, implementation, review, and cleanup. Engineers stayed on the product decisions, edge cases, and final approval. About 90% of engineers’ hours went to mapping the edge cases and writing the test plan, so a missing field or an odd input couldn't take the app down.
03:
Kept engineers at both sign-off gates
The developers stayed in charge at two points: approving the architect's plan before the agents started, and the final result before merge. Everything in between ran on its own. Before opening a pull request, each engineer ran the review chain locally, so the reviewer and security agents caught problems first, sorted by severity from P0 to P4.
Result: The team merged about 127 pull requests this way. At roughly 30 minutes of human review each, the agents handed back close to 60 hours, about a week and a half of one engineer's time.
I follow the human-in-the-loop principle in my practice. Agents still can't fully replace people, but in the right hands they perform well. My job was to take the routine work off the developers, so they spent as little time as possible on it and stayed present at the critical points, where their feedback is irreplaceable.
04:
Assigned a senior team to the build
The team was senior by design, so every engineer could take one part of the product and own it from database to screen. Whoever wrote the code made the architecture calls as they came up.
The work underneath was demanding. The system had to load 300 MB of city energy records without dropping a row or stalling the server, while running the building-ranking math fast enough to keep the map smooth as the user clicked through.
A business analyst held the brief and tested each feature as it landed, a UX designer advised on flows, and a fourth engineer joined on the final day for interface polish.
Result: About 107 hours of people time across three days.
05:
Designed the AI pipeline to keep the runtime bill low
The AI pipeline runs in three stages, and only the last one calls the paid model. The first two stages do the narrowing: a similarity calculation ranks the closest comparable buildings, then a stored library pulls the relevant fixes.
Claude only writes the final recommendation from the data the team already handed it, so the model tailors a vetted fix to the building in front of it.
$45 a month is what it costs to run. See what it cost to build, in the full story.
Result: The system runs at $45 a month: $25 for the API, $5 for the database migrator, and $15 for the database.
06:
Built only what proved the core
We were intentional about the scope and cut anything that grew the feature list without proving the product runs on live data. Our focus was on what proved the core.
That’s why we skipped the second city: 30,000 NYC buildings gave us enough live data to test every layer, and adding another would have run the same import twice.
We loaded three upgrade options from US Department of Energy guidance, enough to prove the engine works the whole way through, from a building's raw data to a finished recommendation. The library is designed to hold hundreds more.
Result: A ready-made PoC on NYC's energy data within 72 hours, with a library built to hold hundreds more later.

[ portfolio/ ]

Related Case Studies

Preferences

Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information

Accept all cookies