Interconnection workbench that turns DER project applications into study-ready utility cases instead of months of email loops.

1. Interconnection delays are now legible as an engineering-workflow problem, not only a grid-capacity problem, because the cluster explicitly centers the study process as the thing slowing new energy connections.
2. Agentic software is being applied directly to grid-planning work, making automation of study preparation and queue triage newly credible inside a domain that was historically manual.
3. A platform expanding to both utilities and developers suggests there is a real cross-counterparty coordination gap worth solving with shared workflow software.
4. The emphasis on a deeper grid-intelligence layer means founders can build a durable data asset from queue and study outcomes instead of competing as a generic AI assistant.

Catalyst. Piq's seed round and stated expansion of agentic grid-planning software to more utilities and developers show that interconnection-study automation is crossing from niche consulting into a sellable software category.

The product sits between an incoming project application and the utility's legacy study environment. It parses single-line diagrams, load or generation profiles, protection settings, and prior correspondence, flags missing inputs, and creates a first-pass study package that an engineer can approve or edit instead of assembling from scratch. Utilities use it to triage queues, standardize assumptions, and draft upgrade or information-request letters; developers can later use a mirrored portal to see what is missing before resubmission. The first workflow is intake-to-study kickoff for distributed energy and flexible-load projects, where delay often comes from incomplete packets and repetitive model setup rather than hard grid physics. Over time, each reviewed case becomes training data on which application patterns, feeders, and design choices create upgrades, delays, or approvals.

What's different. Legacy planning tools solve power-flow analysis after data is structured, while consultants and queue trackers handle the messy translation from an application packet to a study-ready case. Generic AI copilots can summarize documents, but they do not know utility-specific interconnection rules, response templates, and modeling assumptions. This company wins by owning that translation layer, learning from every accepted, rejected, and upgrade-triggering case, and fitting inside existing planning software rather than asking utilities to replace it.

Jobs to be done

flowchart LR
  Buyer[Utility interconnection team] --> Pain[Application backlog and slow study setup]
  Pain --> Product[Interconnection workbench]
  Product --> Outcome[Faster study kickoff and cleaner approvals]

Executive takeaways

• The sharpest wedge is the packet-to-study handoff, not full utility model replacement.
• The market already has portals, study engines, and consultants, but the translation layer between application packet and study-ready case remains fragmented.
• Regulatory heterogeneity turns each reviewed case into a durable workflow and rules asset.
• Budget is easiest to unlock when sold as engineering-throughput and consultant-avoidance software, not generic AI productivity.

Market definition

U.S.-first software and workflow infrastructure for distribution-utility interconnection teams handling DER and emerging large-load applications. The category sits between intake portals and feeder-study tools: it structures packet data, enforces utility-specific requirements, and creates study-ready cases plus draft stakeholder communications.

Customer and buyer

Primary users are utility interconnection managers, distribution planners, and engineering staff reviewing solar, storage, EV-charging, and other distributed energy applications. The economic buyer is usually a director of interconnection, grid planning, or engineering operations, often with additional governance or procurement oversight in public-power and cooperative settings.

Buying triggers

• Queue volumes are rising while utilities still describe manual, paper-based, or fragmented interconnection workflows. [1][2][24][33]
• Completeness review consumes engineering time because utilities require detailed one-line diagrams, site plans, protection settings, and utility-specific forms before studies even begin. [11][12][13][19]
• Large-load growth from EV infrastructure and data-center-style demand adds new application classes to the same constrained teams. [2][9][35]

Willingness to pay

Utilities already spend on portals, studies, consulting, and grid-data refresh work. A new workbench earns budget when it measurably reduces manual completeness review, shortens time to study kickoff, and improves queue transparency without forcing utilities to rip out their existing study engines. [19][20][24][25][27][29][30]

Category dynamics

Growth signal 15-18% projected peak-demand growth over the next decade

Validation signals

• Piq Energy’s seed round shows investors now treat AI-driven grid-planning and interconnection tooling as a fundable category.
• DOE-backed iQMS work is explicitly aimed at reducing manual DER queue friction with software, forecasting, GIS, and AI.
• GridUnity cites a PG&E deployment where posted integration capacity increased nearly 400% after a software-driven refresh.
• Gridtwin claims 1000+ users on the Eversource interconnection portal, implying utilities will adopt external interconnection software at real scale.

Regulatory & technical constraints

• IEEE 1547 sets baseline interoperability, testing, performance, and abnormal-condition requirements for DER interconnection.
• State and utility rules such as California Rule 21 and New York SIR force jurisdiction-specific workflow logic rather than a single national checklist.
• Utilities can reject or delay packets that lack one-line diagrams, site plans, protection details, or storage-specific assumptions.
• Many utilities already route applicants through named portals such as CIT or PowerClerk, so new software must coexist with those surfaces.
• Study exports still need to fit existing analysis and telemetry ecosystems rather than invent a brand-new operating environment.

Competition comes from utility portals, automated study engines, map-first screening tools, transmission-backlog platforms, and consulting substitutes. The whitespace is not generic “AI for the grid”; it is the utility-specific translation layer from messy packet to engineer-reviewed study case.

Why incumbents do not win by default

• Utility portals. They digitize intake and status tracking, but often still depend on humans to translate drawings, settings, and correspondence into study-ready cases.
• Automated study engines. They automate impact studies once inputs are structured, but they are less centered on packet completeness and applicant back-and-forth.
• Map-first screening tools. They improve site screening and hosting-capacity visibility, but their center of gravity is planning insight rather than utility-side back-office case assembly.
• Engineering consultants. They solve peak workload and bespoke studies, but their knowledge stays inside project labor rather than becoming a reusable workflow dataset.
• Planning and modeling tools. They remain the downstream engine of record, which is exactly why a translation layer can fit beside them instead of replacing them.

This company should start as an interconnection study workbench for mid-sized distribution utilities whose DER and flexible-load queues are growing faster than small engineering teams can convert application packets into study-ready cases. The acute pain is not power-flow math itself; it is the manual packet-to-study handoff across PDFs, spreadsheets, email threads, and consultant overflow, which delays utility response targets and developer project schedules. The first product should stay narrow: an engineer-in-the-loop intake-to-study kickoff layer that checks packet completeness, assembles a first-pass study package, drafts information-request or upgrade letters, and exports into the utility's existing study environment. Go-to-market should mirror that workflow by selling a paid pilot to one utility territory with 150-plus queued applications, pricing by territory or team plus application volume, and using consultants or system integrators as credibility and rollout partners rather than as the primary delivery model. The strategic reason to start beside existing portals and study tools is speed of proof: utilities already budget for backlog reduction and consultant avoidance, while full model replacement would trigger a slower and less credible sales cycle. If the wedge works, the durable asset is a rules and outcome dataset spanning packet defects, engineer edits, correspondence patterns, upgrade triggers, and study outcomes that incumbents do not naturally capture in reusable form. The main disconfirming risk is that jurisdiction-specific rules, messy source documents, and model-stack variability make deployments too services-heavy or keep engineer trust too low for production use. The initial modeled SAM and SOM are $48.0M and $4.8M, and because actual application volumes, dominant model stacks, and utility tolerance for AI-generated draft letters remain open, the venture case depends on proving repeatable second-territory deployments plus adjacent expansion before scaling headcount.

Problem

• Utility interconnection teams with 3-15 engineers still spend days translating one-line diagrams, protection settings, site plans, and correspondence from application packets into utility-specific study assumptions before any feeder analysis starts.
• Existing portals, study engines, and consultants either digitize intake or run downstream analysis, but none reliably eliminate the backlog-causing loop of completeness review, missing-data requests, and first-pass case assembly.

Solution

• Provide a workbench that ingests DER and flexible-load application packets, applies utility-specific completeness and rules checks, structures the technical data, and generates an engineer-reviewable study package plus draft stakeholder communications.
• Start as an add-on beside existing portals and study tools, then expand the same data model into developer preflight, upgrade benchmarking, and large-load interconnection workflows only after the utility-side intake layer is trusted.

Why we win

• The wedge targets the narrow workflow that incumbents leave fragmented: portals capture submissions, study engines analyze structured cases, and consultants bridge the gap manually.
• The product can fit beside existing planning stacks instead of asking utilities to replace them, which matches how regulated buyers adopt new software and makes consultant-avoidance ROI easier to measure.
• Every approved or corrected draft compounds a proprietary rules, defect, and engineer-edit dataset that improves accuracy and supports benchmark analytics across utilities.

Milestones

flowchart LR
  Wedge[Portal-to-study translation wedge] --> MVP[Engineer-in-loop workbench]
  MVP --> Proof[Cycle-time proof]
  Proof --> Expansion[Developer preflight and large-load expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 100-120 first-wave utility territories have enough annual application volume and backlog pain to justify more than $200k of recurring software spend.
• An engineer-in-the-loop workbench can cut median time to study-ready kickoff by at least 50% without increasing compliance or audit risk.
• Utilities using PowerClerk, CIT, or similar portals will still buy a translation-layer add-on instead of waiting for incumbent vendors to extend their workflow.
• The first 3-5 deployments can launch with standardized rule libraries and export adapters rather than project-specific integration work.
• The utility-side dataset on defects, edits, and outcomes becomes valuable enough to support developer-preflight or benchmark expansion within 24 months.

Open diligence questions

• Which specific utility territories in the researched first-wave regions fit the 100-1,000 application and 3-15 engineer beachhead profile today?
• How often do utility buyers fund new workflow software versus expanding PowerClerk, GridUnity, consultant, or in-house process work?
• What exact model, GIS, and export stacks dominate the beachhead, and how many can be supported without bespoke code?
• Will legal, compliance, and records teams approve AI-generated draft response letters if engineers remain the sign-off point?
• How many pilot customers are willing to let the company retain anonymized edits and outcome data to build the moat?

Model sanity

• Revenue engine. Base-case revenue comes from 3 Y1 pilots compounding into 7 paying territories by Q4Y2 and 12 by Q4Y3, with blended ARPU exiting near $31K monthly.
• Must go right. Export-first deployments and reusable jurisdiction templates must hold so gross margin can rise from pilot-era highs-50s to roughly 74% by Q4Y3.
• Model breaks if. If production conversions slip a quarter and integrations keep gross margin 5 points lower, the downside case bottoms near -$370K cash before Y3 ends.
• Next-round proof. A seed case is justified once the company shows 6-8 production territories, sub-6-week standard deployments, and one benchmark or preflight expansion inside a live account.

Scenarios

Sensitivity

flowchart LR
  TargetAccounts[Target utility accounts] --> PaidPilots[Paid pilots]
  PaidPilots --> ProductionTerritories[Production territories]
  ProductionTerritories --> Revenue[Blended ARPU]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash runway]

Flags: The base case still depends on landing 3 paid pilots in the first 12 months despite utility procurement friction; a one-quarter sales slip removes about $351K of Y3 revenue and about $401K of cash. · Gross margin does not clear the 70% target until Y2/Y3, so bespoke integrations or heavy human review can flip Y3 back to negative EBITDA. · The $2.0M round sits at the bottom of the BP range and the base case cash low point is only about $0.4M, so seed fundraising should begin before Q2Y3. · Year-3 upside still relies on ARPU lift from benchmark or preflight expansion, not just raw logo growth, because the logo universe is only about 120 first-wave territories.

• Utility adoption friction. Utilities may resist letting software touch regulated engineering workflows and may default to consultants or incumbent internal processes. Mitigation: Start as an engineer-review layer that produces draft study packages and audit logs while integrating into the existing planning stack rather than replacing it.
• Legacy-model integration. The product only works if it fits messy document repositories, feeder-study environments, and asset-data systems that vary by utility. Mitigation: Target a narrow set of common data formats first, ship opinionated adapters, and sell early deployments with scoped implementation support.
• Two-sided focus creep. Trying to serve utilities and developers equally from day one could blur the roadmap and weaken the core wedge. Mitigation: Win the utility-side intake workflow first, then expose a developer preflight portal only after the utility product is sticky.