Company profile · 2 min read
Panorama: finding repeatable workflows before building automation
Panorama describes an AI transformation service that learns how a business works, identifies high-value changes and productionizes the selected system.
Cofounder of Lazyweb (a16z Speedrun). Previously grew subscriptions and built native ads at Duolingo. Writes First1000 (90,000+ subscribers).
Published · Updated
Panorama combines workflow discovery and implementation for teams deciding what to automate first.
What it does
The company homepage describes a strategy phase that studies business and systems, followed by productionization. The homepage says Panorama learns how a business and its systems work before recommending what to build.
Buyer and task
Organizations with repetitive workflows or an AI system that need help deciding what to automate first.
Workflow boundaries
No pricing, implementation result or independent customer evidence is documented here. The public page is enough to describe the service surface, not to rank it.
What I would ask
Ask what data is observed, which workflow becomes the first production system, and who owns the resulting software.
Why it fits
Panorama describes a three-step relationship: Strategy learns how a business and its systems work before code is written, Productionize takes the chosen system into the stack with evaluations, monitoring and runbooks, and Partnership leaves the client team able to extend it. The homepage then names the concrete systems it builds: retrieval, context engineering, LLM cost optimization, data strategy and post-training.
That is more specific than hiring a team to “add AI.” The buyer can start with a messy retrieval or data problem, get a view of what is worth building, and carry the selected system into a production process with evaluation and monitoring. The homepage’s workflow language does not turn that service description into a measured case study. The displayed cost, speed and user figures are not independently established in the checked public pages.
The right question is what remains after the engagement: an evaluated service in the client’s stack, an internal owner, a runbook and a set of tests that can catch drift. Ask who operates it when the model changes, what data is needed for discovery and which engineering decisions stay with the client. Pricing and implementation outcomes are not documented in the reviewed public pages.
Quick facts
| Field | Sourced detail |
|---|---|
| Buyer | Organizations with an AI system or data workflow that needs production rigor |
| Stages | Strategy, productionization and partnership |
| Systems named | Retrieval, context engineering, cost optimization, data strategy and post-training |
| Pricing and outcomes | Not documented independently in the checked pages |
Sources checked
official Speedrun profile · company homepage
Sources checked — September 20, 2026.
About the author
Cofounder of Lazyweb (a16z Speedrun). Previously grew subscriptions and built native ads at Duolingo. Writes First1000 (90,000+ subscribers).
I cofound Lazyweb and publish Mudpie. This is an owner-written publication, not an independent testing organization. Research notes distinguish observations, sourced reporting and editorial judgment.
First1000 ↗ · X ↗