Company profile · 2 min read
Vela: an execution layer for large-load energy projects
Vela describes a live operating model for power infrastructure projects, with agents and portals shaped around each team’s workflow.
Cofounder of Lazyweb (a16z Speedrun). Previously grew subscriptions and built native ads at Duolingo. Writes First1000 (90,000+ subscribers).
Published · Updated
Vela connects power-project data, dependencies and decisions into a shared execution model for energy and data-center teams.
What it does
The company homepage shows workstreams, a critical path and a project brain that remembers changes and why they happened. The data-center page describes reading interconnection threads, utility studies and long-lead registers.
Buyer and task
Energy and data-center developers managing interconnection, procurement, site-control and energization dependencies.
Workflow boundaries
No project delivery result, pricing or implementation detail is independently established. The workflow examples are product demonstrations.
What I would ask
Ask how source documents become the live model, who can change a dependency, and what the system does when a utility date or supplier commitment moves.
Why it fits
Vela’s public interface makes the dependency problem visible. A project page shows workstreams, a critical path and changes flowing from drawings, procurement, interconnection and commercial obligations. Its data-center page describes the same model for a campus: site control, utility applications, studies, long-lead orders and energization. The stated benefit is that an answer names the document it came from and routes a change to the people it affects, with a person signing off before anything is written back.
That is a meaningful fit for power infrastructure and data-center developers because the risk is often a missed relationship between dates, commitments and documents rather than one missing file. A buyer should start with one live project and test a moved supplier date, a superseded drawing and a utility obligation. The question is whether the model shows the downstream impact and preserves the source, not whether an AI summary sounds plausible.
The product examples establish a decision-support workflow, not a security review. The checked public pages do not establish delivery results, pricing or implementation effort. The safest boundary is decision support and coordination with human sign-off, not autonomous project control.
Quick facts
| Field | Sourced detail |
|---|---|
| Buyer | Energy and data-center project teams |
| Inputs | Interconnection threads, utility studies, drawings and long-lead registers |
| Outputs | Live project model, downstream impacts, routed actions and source-linked answers |
| Pricing and outcomes | Not documented in the checked public pages |
Sources checked
official Speedrun profile · company homepage · source page
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 ↗