# Business Lens

## Does this make sense for Vercel?

Yes, with one important rule: the artifact should model Vercel's business mechanics without pretending to know Vercel's internal gross margin or cloud contracts.

Vercel sells a developer and AI infrastructure platform where the value metric is usage: requests, active compute, data transfer, storage, build/deploy activity, security/observability events, and AI model traffic. Public pricing exposes this through units such as Edge Requests, Fast Data Transfer, Functions active CPU, provisioned memory, invocations, Blob/storage, Image Optimization, and AI Gateway.

That means the Strategic Finance, EPD problem is not generic FP&A. It is usage telemetry translated into product-level unit economics:

- What does one more edge request cost before AI workload costs?
- Which product or workload owns the cost?
- Which customers or segments drive margin pressure?
- When should EPD optimize architecture, cache, routing, or vendor strategy?
- When should Finance revisit included usage, overages, or AI pricing?
- Can these allocations survive audit, close, and IPO-readiness scrutiny?

## The rule

Use public Vercel vocabulary; use synthetic numbers; do not imply inside knowledge.

The artifact should say: "Here is how I would structure the operating system."

It should not say: "Here is what Vercel's real COGS or margins are."

## Why hosting it on Vercel helps

Hosting the artifact on Vercel reinforces the point. It shows product affinity, makes the artifact easy to share, and creates a neat meta-signal: a Vercel-hosted demo about making Vercel-style infrastructure economics legible.

The page should remain static and lightweight. The goal is not to build a complex app; it is to demonstrate judgment, business fluency, and the ability to translate EPD usage into finance decisions.