34 — Cost and FinOps Checklist#

Verify that technology spending is attributable, visible, forecastable, and optimized for business value without compromising required quality, reliability, security, or user outcomes. FinOps is a shared product, engineering, finance, and procurement practice—not simply a directive to minimize the cloud bill.

Scope: Frontend-specific. This file is one part of the 34_Cost_and_FinOps.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Cost scope / providers / billing currency:
• Budget, forecast, and allocation policy references:
• FinOps / product / engineering / finance owners:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this reusable checklist into project-specific review records; leave the shared template unchecked.
2. Mark [x] only after verification from provider billing data, ownership metadata, cost forecasts, approved budgets, utilization measurements, unit metrics, or documented decisions. Record failed checks and genuine N/A rationales in project-specific notes or issues using their COST IDs; do not add evidence tables to this repository template.
3. Tailor controls to the technology costs that apply: cloud resources, SaaS, licenses, data platforms, vendor APIs, AI inference, or on-premises infrastructure. Not every project uses commitments, multiple providers, chargeback, or business-unit unit economics.
4. Review ## API Checks and ## Frontend Checks independently where relevant. If one surface does not exist, document N/A and why in project records.
5. Revisit cost baselines, forecasts, allocation rules, and guardrails after major demand, architecture, provider, contract, pricing, or launch changes. Review material contractual and financial decisions with qualified stakeholders.

Frontend Checks#

• COST-107 Measure transferred asset bytes and request counts for key frontend routes and representative devices.
• COST-108 Identify oversized images, video, fonts, JavaScript bundles, and third-party assets that increase CDN or transfer costs.
• COST-109 Use compression, responsive images, code splitting, and caching where they reduce cost without harming user experience.
• COST-110 Define cache-control and asset versioning rules that prevent excessive refetching while avoiding stale or private responses.
• COST-111 Check CDN cache-hit trends, geographic delivery, and origin egress for major pages and media.
• COST-112 Avoid unnecessary client polling, repeated API calls, and refetch loops on common interactions.
• COST-113 Cancel obsolete requests and de-duplicate concurrent fetches so navigation does not create avoidable billable work.
• COST-114 Ensure retry logic has bounds and backoff so network disruptions do not produce repeated API or serverless charges.
• COST-115 Review prefetching and preloading strategies so speculative downloads are proportionate to realized user value.
• COST-116 Test service workers and offline caches for runaway retries, unintended repeated downloads, and incompatible asset versions where used.
• COST-117 Measure third-party analytics, ads, maps, video, and chat widgets for load, transfer, and per-use charges where relevant.
• COST-118 Use lazy loading for noncritical assets and modules when appropriate without delaying above-the-fold essentials.
• COST-119 Set limits and clear feedback for user-driven bulk exports, uploads, generated media, and other potentially costly actions.
• COST-120 Explain material user-facing usage limits, quotas, or fees accurately before initiating a chargeable operation where applicable.
• COST-121 Prevent accidental duplicate paid actions from double clicks, repeated submissions, or inconsistent optimistic state.
• COST-122 Verify frontend feature flags and staged rollouts do not unintentionally enable expensive endpoints for unintended cohorts.
• COST-123 Include appropriate client-side resource and API traffic metrics in release cost reviews without collecting prohibited user data.
• COST-124 Ensure savings-focused changes preserve accessibility, responsive behavior, visual quality, and core task completion.
• COST-125 Check that expired sessions, hidden tabs, and background pages do not continue costly polling indefinitely.
• COST-126 Coordinate frontend caching changes with API rate-limit, billing, and version compatibility rules.

Release gate#

• The release has named product, engineering, and financial owners for its material technology costs, with an approved allocation approach for shared and direct costs.
• Budget, baseline, forecast, principal assumptions, and potential cost-impacting launch or growth scenarios are documented at an appropriate level of detail.
• Critical spending and usage reports reconcile to trusted provider or financial data within accepted tolerances, and material unallocated charges are explained or assigned for investigation.
• Budget threshold, unusual-spend, and quota alerts or equivalent guardrails have owners and a tested escalation route appropriate to release risk.
• Significant compute, storage, data-transfer, SaaS, API, and frontend cost drivers are reviewed for avoidable use without undermining performance, accessibility, security, or reliability commitments.
• Applicable API and frontend operations have controls against unbounded or duplicate billable actions, with appropriate behavior when quotas or limits are reached.
• Any material over-budget forecast, unaffordable unit economics, unapproved commitment, or other significant cost risk has an explicit authorized disposition and remediation owner.

Domain-specific approval rule: Block cost readiness approval if material spend is unowned and invisible, foreseeable high-impact cost exposure lacks acceptable bounds, or a required budget/contract approval is missing. Meeting a cost target does not justify bypassing legal, security, quality, accessibility, or reliability requirements.

Trusted references and scope#

These review questions are informed by the following primary FinOps and architectural guidance. Source recommendations are not universal compliance obligations; adapt them to the workload and commercial model.

• FinOps Foundation — FinOps Framework — cross-functional technology cost accountability, value, and operating model.
• FinOps Foundation — Allocation — cost ownership, tagging and hierarchy, shared cost treatment, and allocation coverage.
• FinOps Foundation — Anomaly Management — detection, routing, investigation, and resolution of unplanned spend.
• FinOps Foundation — Forecasting — forecast models, business drivers, scenarios, and variance tracking.
• FinOps Foundation — Unit Economics — aligning technology unit costs to product/business outcomes.
• FOCUS — FinOps Open Cost and Usage Specification 1.3 — standardized billing vocabulary and cost/usage data when compatible datasets are used.
• FOCUS — Cost and Usage dataset — distinct billed, effective, contracted, and list cost fields; billing period and metadata.
• Microsoft Azure Well-Architected — Cost Optimization checklist — financial responsibility, budgets, guardrails, unit cost, utilization, optimization, and trade-offs.
• Microsoft Azure Well-Architected — Cost Optimization — usage, rate, and continuous optimization principles.

Applicability: FOCUS 1.3 provides a published data specification, not an assertion that every provider export is FOCUS 1.3-compatible or that 1.3 is the newest version. Cloud-specific rate models and tagging practices do not apply unchanged to every SaaS, AI, data center, or on-premises product. Account for billing delays, discounts, currency, shared services, and business value before claiming realized savings.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: usage tagging, budget alerts, cost estimates, and anomaly scenarios; include browser and client behavior where applicable.
• Cross-stack: Infracost.
• Python: Cloud Custodian + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• cost-optimization — Review resource costs and attribution (wshobson/agents, 42,437 repo stars).
• cost-analysis — Review Azure cost data when applicable (microsoft/skills, 3,198 repo stars).
• aws-cost-optimize — Review AWS spending where applicable (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.