Last verified against provider docs: October 17, 2026
What Does Each of Your Apps Actually Cost? How to Track It Per Project
Ask most indie developers what they spend on infrastructure each month and they can give you a rough number. Ask what one specific app costs and the answer gets vague. Ask which apps are still costing money even though nobody has touched them in months, and most people have to go check.
The reason is simple: bills are organized by provider, not by app. You get one invoice from your host, one from your cloud provider, one from each AI API, a few domain renewals, and maybe a server somewhere. Each invoice covers several projects, and every project draws on several invoices.
This guide covers how to build a per-app cost list by hand, which provider tools help, and what to do once you have the list.
Why your bills don't tell you what each app costs
One invoice per provider, many apps per invoice
A single hosting account usually runs several projects. A single cloud account might hold a database for one app, a storage bucket for another, and a server you set up for a weekend experiment. The invoice shows the total, and sometimes a line per service, but rarely a line per app.
One app, many invoices
Look at it from the other side. A typical small app might use:
- a hosting platform for the frontend
- a database or backend service
- an AI API
- a domain
- maybe a rented server for a worker or a bot
That's five or so places to check for one app's monthly cost, and you have to do it for every app.
The apps you stopped using are the hardest to see
Active apps get looked at. The ones you stopped working on don't. They're still deployed, the domain still renews, and the server still runs. Each charge is small enough to ignore on its own, so they add up quietly.
Building a per-app cost list by hand
You can do all of this with a spreadsheet. It takes some time the first time through.
Step 1: Inventory everything
Make one row per app. For each one, note:
- the repo, and when it last had a commit
- where it's deployed
- which domains point at it
- which external services it uses (look in its config and dependency files:
package.json,Dockerfile,wrangler.tomland similar) - any servers it runs on
Step 2: Pull real numbers from each billing source
For each provider, find what you were actually charged, not the list price. A few provider tools help you split costs by project:
- Vercel: open Usage in the dashboard sidebar (pick the team with the team switcher first), then choose a project from the dropdown to see just that project's usage. You can also break usage down by project and region. From the CLI,
vercel usage --since 30d --group-by projectshows the last 30 days by project. (Vercel docs) - AWS: cost allocation tags let you label resources (for example with an app name) and then filter costs by that tag in Cost Explorer. You have to activate a tag before it shows up: in the Billing and Cost Management console, choose Cost allocation tags, select the tag keys, and choose Activate. New tag keys can take up to 24 hours to appear, then up to another 24 hours to activate. Only standalone accounts and an organization's management account can manage these tags. (AWS docs, activation steps)
- OpenAI: the Usage Dashboard has its own project selector, so you can look at one project, several, or all of them. If each app has its own OpenAI project, you can read off its usage directly. You need to be an organization owner or have the Usage Dashboard permission. (OpenAI Help Center)
Other providers vary. Some have billing APIs or detailed invoices, and some only show a plan price.
Step 3: Handle providers with no billing data
Some providers don't expose billing through an API. For those, use the invoice or your card statement. Whatever you do, write down the real number or mark it unknown. Don't guess. A per-app list that mixes real charges with estimates is hard to trust and harder to act on.
Step 4: Keep your own entries separate
Sometimes you know a cost that no system can see, like a yearly domain you paid for at a registrar you haven't connected to anything. Record it, but mark it as entered by you so you can tell it apart from the verified numbers.
Add context: page views and revenue
A cost on its own doesn't tell you much. $20/mo is fine for an app with users and revenue, and a waste for an app with neither.
If you use analytics, add page views per app. If an app takes payments, add its revenue. Then the obvious red flag stands out: real cost, no traffic, no revenue, no recent commits.
What to do with the list
Once every app has a row, sort by cost and go through them:
- Keep: it's active, or it's worth what it costs.
- Dormant: you aren't working on it, but it costs nothing you can see. Archive the repo if you're done with it.
- Kill: you aren't using it and it's still billing you. Pause or delete the hosting, destroy the server, decide what to do with the domain.
Then plan to redo the list regularly, because new projects appear and costs change.
Keeping it current
The manual version tends to go stale. It's a lot of tabs to revisit every month, and the forgotten apps are exactly the ones you won't think to recheck.
How CobwebCheck does this
CobwebCheck is a cost tracker for all your apps. It tracks what every app costs you, and catches the ones quietly billing you after you've stopped using them.
- It builds the inventory from GitHub. A read-only GitHub App (Metadata and Contents: read) reads your repo list, activity dates and a short list of named config and dependency files. It detects services from those files plus public DNS. It never reads your real
.envfiles, and source code is never stored. - It pulls real costs from billing sources you connect:
- Vercel: real charges on Pro and Enterprise teams; plan only on Hobby.
- Cloudflare, DigitalOcean, Vultr, Linode/Akamai, Scaleway.
- AWS: only
ce:GetCostAndUsage. AWS charges $0.01 per request, and each scan makes one. - OpenAI and Anthropic: admin keys, usage and cost read.
- A card statement CSV: only recurring tech charges are kept, and raw rows are never stored.
- Real costs only. If a provider has no billing API or isn't connected, the report says "cost not connected" rather than estimating.
- Each app gets one line: real monthly cost and its source, last activity, domains, and a verdict (the sample report shows kill, sell, dormant and keep). You can add page views (Plausible or PostHog). A Stripe revenue connection is coming soon.
- You can correct any finding: mark it free, not in use, enter a cost yourself (shown separately as "entered by you"), or assign it to a different app.
Free: a full scan that shows your totals (verified spend, entered, and unknown) and your top 3 apps.
Paid ($9/mo or $90/yr): - per-app costs, verdicts, next steps and exports - ongoing tracking: - a weekly re-check of connected key-based billing sources (cloud providers, Cloudflare, AI admin keys) - monthly cost snapshots per app with 6 months of history - a weekly digest email, sent only when something changed: new charges, increases over 20%, or newly detected services
Vercel and bank-statement costs refresh when you run a scan.
Everything CobwebCheck requests, stores and keeps is listed on the permissions page. To see what a report looks like first, the sample report uses fictional apps and needs no login.
See what every app costs you. Read-only, about two minutes, nothing to install.
Sources
- Vercel, "Manage and optimize usage": https://vercel.com/docs/pricing/manage-and-optimize-usage
- AWS, "Organizing and tracking costs using AWS cost allocation tags": https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
- AWS, "Activating user-defined cost allocation tags": https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html
- OpenAI Help Center, "Reviewing API usage and costs": https://help.openai.com/en/articles/10478918-api-usage-dashboard
- CobwebCheck product details: https://cobwebcheck.com/permissions and https://cobwebcheck.com/sample