.png)
[Tl;DR]
MEV shipped a proof of concept (PoC) in 72 hours: an app that reads New York City's public energy data and shows building teams which properties waste the most energy, with a suggested cost fix for each one. Three engineers ran the build with seven AI agents as part of the MEV Innovation Lab Delivery System, MEV's gated pipeline of single-job AI agents with engineer sign-off at each stage, built to ship fast. The engineers spent their hours on planning and testing, the calls that needed senior engineering expertise. The PoC app runs at $45 a month. The seven agent specs from this build are public on GitHub.
Inside MEV's AI Innovation Lab: Shipping a PoC in 72 Hours
A global electronics company's AI innovation unit ran a 72-hour build among development firms.
The brief was deliberately light. The organizer set NYC's Local Law 84 data and left the product and its users for each team to define.
Large commercial buildings in New York City must report their energy use annually, and the worst performers face growing penalties. Our app reads that public data and shows Building Performance Analysts which buildings waste the most energy, then recommends a fix for each one with projected costs and payback periods.
Three engineers and seven AI agents ran the build across three days, with a fourth engineer joining for the final day.
By hour 72 the app was live, and it won first place on the two scores the organizer set: code quality and AI integration.
The seven agent specs behind the MEV Innovation Lab Delivery System, public on GitHub.
How Do You Scope a Product from an Open Dataset
You pick one user the dataset can serve and map their journey before writing code. Local Law 84 gave us about 30,000 buildings of public data, the richest source available for this kind of work and quick to put to use in three days.
It was rich enough to serve three or four different roles, so we spent the first morning picking just one. The user journey pointed to a Building Performance Analyst, the person who answers for energy performance across a whole real-estate portfolio. We mapped this path before tackling the code.
How a User Persona Shaped the Build
Naming one user, a Building Performance Analyst, set every feature the team built. The work started in parallel: the engineers took on the infrastructure while the business analyst and designer mapped the flows for the user role we'd chosen.
Meet Jordan, a Building Performance Analyst who oversees 20 to 200+ commercial properties and reports to an executive.
His job is to keep that portfolio compliant with the city's emissions rules and to report on it. He doesn’t renovate the buildings himself: he finds the underperformers, works out what's wrong, recommends a fix, and persuades leadership to pay for it.
A score on its own does nothing for Jordan, he needs analysis he can defend in a meeting: the reasoning behind it and the cost-benefit math to back the spend.
Here is what he can do with our app:
- Compare a building against similar ones, so a weak score comes with context
- Get an AI fix for each poor performer, with the projected cost and payback period attached
- Ask a question in plain English and get an answer grounded in the building's data
How Seven AI Agents Fit into a 72-hour Build
Seven AI agents worked alongside our engineers, each built for a single job. They ran as a part of the MEV Innovation Lab Delivery System, a gated pipeline where agents pass work down the line: plan to code, code to review, review to fix, with a human sign-off at each end. We ran it on Claude Code, Anthropic's tool for agentic development.
Every agent's behavior lives in a written spec we keep next to the code, version-controlled like everything else.
The seven agents and what they do:
One command, /dev with a ticket number, runs the whole chain from a task on the list to code that's ready for review.
It's the same agentic workflow pattern of stages and approval gates we run on partners' projects. This build used a stripped-down cut of it.
What had to be ready before the agents could start?
Before any engineer opened a ticket, the delivery pipeline was already running. We set up hosting on DigitalOcean and configured GitHub Issues so the agents could work from the ticketing system directly.
Every merge deployed on its own, and any migration a developer added ran through a separate job after the commit merged.
The build runs on a human-in-the-loop principle: people stay in charge at two moments. The first is at the start, reading the architect's plan and signing off on scope before the agents pick it up.
The second is at the end, giving the final sign-off before the work merges. Everything between those two points runs on its own, and the judgment calls on either side stay with the experts.
"Most of our time on this build went into planning and testing, about 90% of it. The agents handled the code quickly, so our hours went into the work ahead of it: mapping the edge cases and writing the test plan. Skip that work and the agent gets the happy path running. It falls over on a missing field or an unexpected input, unless someone planned for that case.”
Ivan Makarov, Engineering Manager at MEV
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 down to P4.
The team merged about 127 pull requests this way. A human review runs 30 minutes or more per pull request, so the agents handed back close to 60 hours, about a week and a half of one engineer's time.
Why Does a Senior Team Matter on an AI Build
The team was senior by design, so that every engineer could take one part of the product and own it from the database to the screen. The architecture calls that held the build together came from the expert who owned that vertical: be it the circuit breaker for when the AI provider goes down or the pre-deploy migration guard.
That ownership is how a small team moved fast: the person writing the code also made the architecture call the moment it came up.
The work underneath was demanding. 300 MB of city energy records had to load without dropping a row or stalling the server, and the math that ranks each building against its peers had to stay fast enough to keep the map smooth as the user clicked through.
The business analyst held the brief and tested each feature as it landed. The UX designer advised on the flows. The fourth engineer joined on the final day for interface polish. Across the three days, the people on the project put in about 107 hours.
The AI Lab build ran smoothly because the team had already been practicing the agentic workflow approach, so they applied a method they knew rather than assembling one on the clock.
How We Kept a PoC at $45 a Month
The PoC runs at $45 a month: $25 for the API, $5 for the migrator that handles database updates, $15 for the database. That's what it costs to run. Building it though cost more: four engineers, each on a $200/month Claude Code plan. Here are a few decisions that kept the runtime bill there.
How do you keep AI API costs low?
The AI pipeline produces each building's recommendation in three stages, and only the last one costs money to call. The first two do the narrowing: statistics find the most similar buildings, then a stored library pulls the relevant fixes. Only the last stage, writing the recommendation, goes to Claude. By then the model is working from the data we handed it, so it adapts a vetted answer to the building in front of it.
What happens when the AI provider goes down?
We designed the app to keep running through an AI outage. If the provider goes down or rate-limits us, the map and the building comparisons stay live, and a notice fills the recommendation slot instead of breaking the page. We build this in from the start, the way we do on client systems, since adding it later costs more.
How do you bill for AI usage?
We wired up Stripe with two subscription tiers and checked each user's plan before every AI call. Our logs capture every AI call, so we can trace which prompt version produced which recommendation and what it cost.
The prices were placeholders but the billing structure was what you'd put in front of paying customers.
Three pieces would carry the app into production:
- Subscription billing, with AI usage capped by plan
- An admin panel tracking the health of the incoming data
- A full record of every AI call, so we can trace what the system said and why
Later on the stack would need scaling for production traffic. That's the expected next step for a PoC that proves out.
What do you cut to ship a PoC in three days
We cut anything that grew the feature list without proving the product runs on live data. The clock settled every scope call: does this prove the core, or just add to the list? We spent our hours on the first kind.
We skipped a 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 instead of hundreds. The engine recommends a fix for each building, like adding insulation or a heat pump, and pulls from a stored library of these options. The three upgrade options came from US Department of Energy guidance. That was enough to prove the engine works the whole way through, from a building's raw data to a finished recommendation.
Overall, we built the library to hold hundreds more but filling out the rest is content work for later.
We skipped custom interface work. Off-the-shelf components handled the screens, which freed time for the flows underneath.
The whole build ran on one principle: prove the core on live data, and let the rest grow from there.
What the build proved
Three days, six people, and a $45-a-month infrastructure bill produced a PoC live on NYC's energy data. The agents handled the bulk coding to clear 60 hours of manual review. Meanwhile, senior engineers drove the strategy: architecting the scope upfront and signing off on the final code before merge.
The seven agent specs from the MEV Innovation Lab Delivery System applied for this build are public on GitHub.
We run AI labs, like the one you just read about, for clients under our Innovation Lab as a Service, helping partners validate an idea and produce a PoC quickly.
If you have one in mind, or need help with a product already underway, let's talk.
.png)
