See what every Heroku app costs and shrink it in place

Build me an app for running a monthly Heroku cost pass. I am an engineering lead who wants to see what my whole Heroku estate costs per month, which apps are the expensive ones, and where I can safely cut, and I want to make those cuts from the same screen instead of opening the Heroku dashboard app by app. Keep the framing on money saved rather than infrastructure detail, and never apply a change without me confirming it first.

Main screen: one table with a row per app. Load apps from Heroku with List Apps, plus List Team Apps for each team returned by List Teams, and dedupe by app id. For each app pull its process formation with List Formation (process type, dyno size, quantity), its currently running dynos with List Dynos, and its attached add-ons with their plan names. Do the add-ons in one pass across the account using List All Add-ons and group the results by app rather than calling per row, falling back to List App Add-ons when a single row is refreshed. Also read the most recent releases per app with List Releases so each row knows how long ago that app last shipped.

Cost math: each row shows a computed monthly run rate. Add-on plan prices must be read from Heroku rather than hardcoded, since every marketplace add-on defines its own plan pricing. Get them from the plan attached to each add-on, using Get Add-on Plan or List Add-on Plans for the add-on service. Dyno costs come from an editable rate table in the app settings, seeded with the standard published monthly rate per dyno size, so someone on a discounted contract can correct the numbers. An app's monthly run rate is the sum across process types of dyno rate times quantity, plus the sum of its add-on plan prices. Show the dyno subtotal and the add-on subtotal separately so it is obvious where the money is going, sort the table by run rate descending by default so the expensive apps surface first, and show a total estate run rate at the top of the page.

Flags: mark rows worth attention with a small chip and a one-line reason. Flag apps running more dynos than they look like they need (for example several web dynos on an app with very little recent release or dyno activity), performance size dynos on apps with almost no release activity in the last few months, and add-ons on paid plans attached to apps that have not shipped in months. Make the staleness window (months since last release) a setting, and let a user dismiss or snooze a flag on a row so next month's pass is not noisy.

Inline actions, because I want to act without leaving the screen. On each row let me change a process type's dyno size or quantity in place, applying with Scale Formation for a single process type and Batch Update Formation when I have changed several at once. Let me move an add-on up or down a plan with a dropdown of the plans available for that add-on service from List Add-on Plans, each shown with its price, applying with Update Add-on Plan. Both actions sit behind a confirmation dialog that shows the before and after monthly cost for that app, the monthly delta, and the effect on the estate total. Nothing auto-applies. After a change lands, refresh that row and show the new run rate. If Heroku rejects a change on permission grounds, say so plainly on the row instead of failing silently.

Export snapshot button: appends the current month's per-app cost breakdown to a Google Sheet using Append Values, one row per app with the snapshot date, app name, owning team or account, dyno subtotal, add-on subtotal, total monthly run rate, dyno counts by size, add-on plan names, and any flags. Make the spreadsheet and tab configurable in settings. In the UI, explain why this button exists: Heroku's own API gives back no historical billing, so this sheet is how finance builds a spend trend over time.

Review this app button on each row: kicks off a background agent for that one app. The agent reads the app's formation (List Formation), running dynos (List Dynos), attached add-ons (List App Add-ons), recent releases (List Releases), and recent logs (Create Log Session), then writes a plain-English rightsizing recommendation: what it would change, roughly how much that saves per month, and what the risk of making that change is. Store the recommendation and a timestamp against the app in the app's own storage so the row can show it in an expandable notes panel underneath. Show a pending state on the row while the agent is working and surface the result when it lands. Keep the write-up in the language of money and risk rather than infrastructure jargon, and have it end with one concrete suggested action I can carry out with the inline controls on that same row.

Persistence: settings (the dyno rate table, the staleness thresholds, the export target) and the stored review notes and snoozed flags persist for the workspace so the state is there next month. The whole app is something a founder or engineering lead opens once a month to cut spend, so the top of the screen should answer one question immediately: what does this estate cost me per month, and what are the three biggest things I could cut today.