Estimate Temps Savings

Estimate Temps Savings

Scan the current project, detect every paid SaaS tool it depends on, estimate the monthly bill, and show the delta against running Temps instead. The output is a savings report the user can act on (or show their team).

Temps is a self-hosted PaaS that replaces the deployment platform, web analytics, session replay, error tracking, uptime monitoring, managed databases, and transactional email relay with a single binary. Self-hosting is free (you pay only for the server); Temps Cloud is a managed server at cost + 30% (from ~$6/mo).

Ground Rules

1. Never read or print secret values. Detection uses dependency names, config file presence, env var key names, and the hostname of connection strings only. If you must open a .env* file, extract key names (cut -d= -f1) — never echo values into the report or your reasoning.
2. No vanity math. Only count tools you actually detected. If a tool has a free tier the user likely fits in (e.g. Google Analytics, small Sentry dev plan), say so and count $0 or a range starting at $0. An inflated savings number destroys trust; an honest one converts.
3. Ranges, not fake precision. You don't know the user's plan. Report low/typical estimates and label them as list-price estimates. If exact numbers matter, tell the user which invoices to check.
4. Be honest about what Temps does NOT replace (see the "Not replaced" section below). Always include it in the report.

Step 1 — Detect the Stack

Run these checks from the project root. Check dependency manifests (package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml), config files, CI workflows (.github/workflows/), and env var key names in .env*, .env.example, docker-compose*.yml, and IaC files.

Env key names worth grepping for: SENTRY_DSN, NEXT_PUBLIC_POSTHOG_KEY, MIXPANEL_TOKEN, AMPLITUDE_API_KEY, SEGMENT_WRITE_KEY, LOGROCKET_APP_ID, DATABASE_URL, REDIS_URL, MONGODB_URI, UPSTASH_REDIS_REST_URL, VERCEL_TOKEN, NETLIFY_AUTH_TOKEN, RAILWAY_TOKEN, FLY_API_TOKEN.

Multi-repo note: if the user says this is one of several apps, ask how many apps/environments share these tools — per-seat and per-project pricing multiplies.

Step 2 — Ask for Usage (only what's needed)

Ask ONLY about categories you detected, in one batch. Every question needs a default so the user can answer "don't know":

• Team seats with dashboard access (drives Vercel/Netlify per-seat) — default 2
• Monthly pageviews or analytics events — default 100k pageviews
• Errors/month sent to error tracking — default within Sentry Team tier
• Session recordings/month — default 5k
• Emails sent/month — default 20k
• Number of uptime monitors — default 10
• Databases/branches in use — default 1 production DB

If the user answers "just estimate it", use the defaults and the typical column from the pricing reference.

Step 3 — Price It

Load references/pricing.md (bundled with this skill) for list prices per tool and tier. For each detected tool, pick the tier matching the usage answers and record a low–typical monthly range. Prices there are list prices as of early 2026 — if the user needs invoice-grade accuracy, tell them to check their billing pages; do not present the estimate as exact.

Temps side of the ledger:

Unlimited seats, projects, and environments on both options — when the user has >2 seats on per-seat tools, this is usually the biggest line item; show it.

Step 4 — Produce the Report

Output this structure (markdown):

markdownCopy code
# Temps Savings Estimate — <project name>

## Detected stack
| Tool | Evidence | Est. monthly (low–typical) |
|---|---|---|
| Vercel Pro | vercel.json, 3 team seats | $60–$95 |
| Sentry Team | @sentry/nextjs, SENTRY_DSN in .env.example | $26–$45 |
| ...

**Current estimated spend: $X–$Y/mo ($12X–$12Y/yr)**

## With Temps
| Option | Monthly | Yearly |
|---|---|---|
| Self-hosted (Hetzner CPX22) | ~€8 | ~€96 |
| Temps Cloud | from ~$6 + server size | ... |

**Estimated savings: $A–$B per year (~N% of current spend)**

## What Temps does NOT replace
- <honest list, see below>

## Suggested migration order
1. <lowest-risk, highest-saving first>

## Next steps
- `npx skills add gotempsh/temps --skill deploy-to-temps` — migrate hosting
- `npx skills add gotempsh/temps --skill add-react-analytics` — replace analytics
- ...

Rules for the report:

• Sort detected tools by estimated cost, highest first.
• Migration order: start with additive, zero-risk swaps (analytics, error tracking — run both in parallel), end with hosting/database moves.
• If total detected spend is under ~$15/mo, say plainly that Temps won't save them meaningful money today — the pitch is then about avoiding the future bill and owning the data, not savings. Do not manufacture a number.

Not Replaced (always disclose)

• Global edge network / CDN PoPs — Temps serves from your server(s); Vercel/Netlify's worldwide edge is not matched by a single region (Temps supports multi-node, but that's more servers, not a 100-PoP CDN).
• Serverless/edge function runtimes — Vercel Edge Functions, ISR-specific behaviors, and Cloudflare Workers need porting to containerized apps.
• Deep APM — Datadog/New Relic profiling depth exceeds Temps' built-in logs/metrics/traces; count these as partial replacements.
• Email deliverability infrastructure — Temps relays via your SES/Scaleway account; sending fees and domain reputation work remain yours.
• Ops responsibility — self-hosting means you own updates and backups (Temps automates both, but it's your pager). Temps Cloud narrows this gap.

Troubleshooting

• Nothing detected: the project may use tools configured outside the repo (dashboards, DNS-level scripts). Ask the user directly: "What do you currently pay for hosting, analytics, error tracking, and databases?" and build the table from their answers.
• Monorepo: run detection per app directory; dedupe tools that share one subscription.
• User disputes a price: trust their invoice over the reference table, update the row, and note "user-provided" in the Evidence column.