Renewable Project Development Software: Knowing Which Sites to Kill Before They Eat the Development Budget

Why a development pipeline outgrows the spreadsheet at about twenty projects

A VP of development is asked in a Monday investment call which projects should get the next tranche of at-risk capital. The honest answer requires knowing, for each of 34 projects, whether site control is signed or under option, when the next option payment falls due, what the title report flagged and whether it was cured, where the project sits in a cluster study and what the withdrawal penalty is if it exits, whether the county has changed its solar ordinance since the site was picked, and whether an offtake conversation is real or polite. That answer lives across a shared drive, a land agent's inbox, a GIS project file, a utility portal login, and the VP's memory.

So the pipeline gets rebuilt in a spreadsheet before every board meeting. Each rebuild is a snapshot that is stale within a week, and it flattens the one thing that matters into a single column called status. Meanwhile capital keeps flowing to projects on the momentum of prior decisions, because nothing in the process forces the question of whether this specific site still has a path to notice to proceed.

The failure mode is expensive and quiet. A developer keeps paying option payments and consultant fees on a project whose interconnection position became uneconomic when the cluster study came back with a network upgrade allocation nobody read carefully. Or a milestone deadline passes, the position is forfeited, and the site becomes worthless land control. Nobody made a bad decision. Nobody made a decision at all, because the information required to make one was never assembled in one place.

Problem 1: stage gates without evidence are just labels

Every developer has stages. Prospecting, site control, diligence, permitting, interconnection, notice to proceed. In the spreadsheet these are dropdown values, and a project moves when someone updates the cell. There is no requirement that anything be true. A project can sit in permitting for eight months while the actual permit application was never filed because the survey it depends on is unpaid.

Sitetracker is a competent deployment and project management product and it is strong once a project is being built, which is a different problem from deciding whether it should be. Aurora Solar and PVcase are design and energy modelling tools and they do that job well, but a layout does not tell you whether the easement is recorded. Anza Renewables addresses module procurement and LevelTen addresses offtake price discovery. None of them is a development stage risk and capital allocation system, and the reason is simple: that system encodes a specific developer's underwriting judgement, which is exactly what a developer does not want a vendor to standardise.

A custom build makes the gate a set of evidence conditions rather than a label. Site control means an executed document of a recognised type, with a term long enough to cover the expected development timeline, uploaded and dated. Interconnection means a queue position with a study phase, a deposit posted, and the next milestone date. The system will not let a project sit in a stage it does not qualify for, and the pipeline report becomes an assertion the finance team can rely on rather than a summary of what people typed.

Problem 2: the three data sets that never meet

Development runs on three unrelated bodies of information. Spatial data: parcels, ownership, setbacks, wetlands, transmission proximity, slope, the county's overlay districts. Legal documents: leases and options with escalators and extension terms, title commitments with exceptions, easements, ordinances, and the crossing agreement someone negotiated two years ago. And utility process data: the queue position, the study phase, the deposit ladder, the network upgrade estimate, and the interconnection agreement deadline.

They live in a GIS project on one analyst's machine, a document folder organised by whoever created it, and a utility portal that emails PDFs. Nothing joins them, so the question that matters, which is whether this particular parcel under this particular lease can host a project that clears this particular queue position economically, is answered by a person reading three sources and holding the result in their head.

A custom build makes the project the joining object and attaches all three. Parcels come in as geometry with the attributes your underwriting cares about. Documents are stored against the project with their key terms extracted as structured fields, so an option payment schedule is a set of dated obligations rather than a paragraph on page nine. Queue positions carry study phase, deposits and deadlines as dates the system can act on. This is where document extraction genuinely earns its place: a portfolio of a few hundred leases and title commitments contains payment dates and expiry terms that no human is going to re-read quarterly, and the extracted fields turn them into a calendar with money attached.

Problem 3: deadlines that forfeit value while nobody is watching

Development is a calendar business punctuated by dates that destroy value if missed. An option expiring unexercised. A deposit due in a cluster study process where withdrawal carries a penalty and re-entry means going to the back of the queue. A permit condition with an appeal window. A tax credit safe harbour position that depends on when construction is deemed to start, which is a question for your tax counsel and not for a project management tool, but which nonetheless has to be tracked against real procurement and construction evidence.

The interconnection queue reforms that moved most regions to first-ready first-served cluster processes made this worse, not better, from a tracking perspective. Readiness demonstrations, site control requirements and withdrawal penalties now arrive on the utility's schedule with real money attached, and a developer with thirty positions across four utilities is managing thirty different clocks that arrive by email to different people.

A custom build turns every obligation into a dated record with an owner, a money value and an escalation path. The useful version does not just remind, it ranks: the Monday view shows the obligations falling due in the next 60 days sorted by capital at risk, so the VP sees that the $40,000 deposit on a project with a weak offtake path is due before the $6,000 option payment on the best site in the portfolio. That is a decision prompt, not a task list.

What a custom development pipeline build has to include

• Stage gates defined as evidence conditions, with the project unable to advance until the required documents and dates exist.
• Site control as a first class object: instrument type, parties, term, extension options, payment schedule and recorded status, with obligations posted to a calendar automatically.
• Interconnection positions with study phase, deposits, milestone dates, network upgrade estimates and withdrawal terms per utility.
• Parcel and GIS integration so spatial constraints and ownership sit on the same record as the legal and queue data.
• Document storage with extraction of the terms that carry dates or money, reviewed by a human before they become obligations.
• A capital-at-risk view per project and per portfolio, showing money already spent, money committed, and the next decision point.
• Scenario modelling at portfolio level, so a change in a network upgrade estimate or an offtake price can be pushed through the pipeline and the ranking recomputed.

What it costs and how long it takes

From the renewable development and infrastructure work Digital Heroes has delivered, the shape is this. A first release covering evidence-based stage gates, site control with payment obligations, interconnection positions with deadlines, and a capital-at-risk view runs $55,000 to $120,000 and ships in 10 to 14 weeks. A full platform adding parcel and GIS integration, document extraction across the lease and title portfolio, permitting and offtake workflows and portfolio scenario modelling runs $150,000 to $350,000 phased over 6 to 12 months.

What drives cost up for developers specifically: the number of utility territories, because every interconnection process has its own stages, deposit structure and document formats and there is no shortcut. Multi-technology portfolios, since a wind project's diligence set is not a solar project's and storage adds its own siting and interconnection questions. GIS depth, because pulling county parcel data at scale across several states is a real data engineering exercise with inconsistent sources. And the document backlog, since extracting terms from four hundred existing leases is a project of its own that pays back immediately and should be scoped honestly rather than assumed.

What keeps cost down: starting with the projects that are live rather than the archive, gating on the five or six evidence conditions that actually change decisions rather than the twenty a committee will propose, and leaving GIS integration to phase two unless spatial screening is your differentiator.

Build versus buy, and when buying is right

Buy, or rather stay disciplined with what you have, if you carry fewer than about ten active projects in a single utility territory. A shared workspace with a strict naming convention and one person who owns the calendar will outperform a half-adopted custom tool, and the development budget is better spent on land agents and consultants.

Build when two or more of these are true. You carry more than twenty active projects across two or more utility territories. The pipeline is rebuilt manually before every investment committee. You have forfeited or nearly forfeited a queue position or an option because a date passed unnoticed. Your underwriting logic is a genuine differentiator and you refuse to standardise it to a vendor's stage model. Or you have taken outside capital and your investor wants a defensible, current view of capital at risk per project rather than a quarterly deck.

The tipping point is not project count on its own, it is whether the developer can answer the capital allocation question without a week of preparation. When the answer to which project should get the next dollar requires assembling information rather than reading it, the assembly work has become the constraint on how fast the business can move.

How to choose a developer for renewable pipeline software

Ask them to model site control on a whiteboard. You want to see an instrument with parties, a term, extension options, escalating payments and a recorded status, and you want them to ask whether an option and a lease behave differently in your process. A developer who models it as a checkbox called land secured has not spoken to a land agent.

Ask how they would handle four utilities with four different interconnection processes. The right answer is a configurable process definition per territory, not four hard-coded workflows and not one generic one. Interconnection is where this category of software either fits your business or quietly stops being used.

Ask what they would extract from a lease and what they would refuse to extract. A good answer draws the line at dates and money, with human review before anything becomes a binding obligation in the system. A firm that promises full automated abstraction of legal documents is selling you a risk you do not want.

Ask who owns the code, the repository and the cloud accounts, and settle it in writing before kickoff. Your pipeline data is your competitive position and it should never sit somewhere you cannot reach without a vendor's cooperation. At Digital Heroes the client owns it from the first commit. A practical first step: take your current pipeline spreadsheet and mark every cell whose value you cannot immediately prove with a document or a portal screenshot. That count is the business case.