Al and Early De-Risking: The Future of Solar Development

In this episode, James sits down with Paces colleagues Kyle Baranko and Tony Wagler to discuss their new white paper, “Pre-Development at Scale: Modeling Risk in Early-Stage Solar Development”. They dive into how AI, probabilistic methods, and standardized development workflows can dramatically reduce soft costs and increase project success rates.

Kyle shares how Monte Carlo simulations were used to model development risks and timelines, while Tony outlines the four key archetypes—environmental, permitting, design, and interconnection—that shape project outcomes. They explain how early de-risking leads to faster decisions, improved IRRs, and better positioning in incentive programs.

Other topics include:

• Why 70–90% of post-site control projects fail
• The power of failing fast and cutting development timelines by up to 50%
• How automation preserves data integrity while saving time
• Real-world feedback from developers and IPPs
• A new interactive tool to explore portfolio-level risks

Whether you’re a solar developer, investor, or curious about energy infrastructure, this conversation offers practical insights into the future of clean energy project planning.

Paces helps developers find and evaluate the sites most suitable for renewable development. Interested in a call with James, CEO @ Paces?

Transcript

00:02.48

James McWalter

Hello, today I'm joined with two of my PACE's colleagues, Kyle Baranko and Tony Wagler. um They lead... ah

00:08.75

Kyle

Thanks,

00:09.18

Tony

us.

00:09.37

James McWalter

like Today I'm joined by two of my PACE's colleagues, Kyle Baranko and Tony Wagler. They led the development of our latest white paper on early stage solar risk modeling. We're going to go deep on some pre-development strategy, probabilistic modeling, whatever that means, and how AI can reshape stage solar development.

00:27.83

James McWalter

Welcome the podcast, Kyle and Tony.

00:30.14

Tony

thanks for having us

00:31.43

Kyle

thanks james

00:33.30

James McWalter

Brilliant. So i think you've both been on the podcast in the past. um guess it would be great to hear from Bodhi your roles and paces and how this project came together, starting with you, Kyle.

00:44.77

Kyle

Absolutely. um Thanks, James. so yeah, i my background has in always been at the intersection of energy and data science. So I currently lead product at Paces and have been here for about two and a half years and and really focused a lot on modeling unstructured data, particularly around permitting and other aspects of you know grid behavior and  Q dynamics. um A lot of my work prior to joining Paces was related to understanding how different human behavior and adoption of different technologies impact the energy system. um So specifically doing lots of distribution planning work. So thinking through how can we shape human behavior, you know discharging ah batteries and electric vehicles to minimize grid upgrades and then um going through forecasting demand response into um you know understanding

01:31.78

Kyle

human behavior and in ensuring that lots of distributed energy resources are integrated effectively into the grid. um So a lot of the genesis of this white paper um was collaborating with Tony and thinking through, you know, from first principles, what does it take to develop ah a new and energy infrastructure project? and And what are a lot of the messy data problems and inherent randomness randomness of humans that that go into that process? And how can we better um you know provide ah ethereical a theoretical and an empirical lens into understanding that dynamic?

02:01.72

James McWalter

And how about you, Tony?

02:03.40

Tony

Thanks for having us, James. I come to Paces, I've been here about six months, but came from a renewable energy development background. I did two years of full origination through to NTP on both battery storage as well as some Solar Plus co-located battery storage projects.

02:21.62

Tony

And prior to that, did full development on some industrial and commercial solar projects, as well as some some ground-mounted front the meter renewable projects.

02:32.23

Tony

I've always had an interest um in renewables and development, but I've also had an equal interest in software. So joining Paces has been a joy to look at all the issues that happen in development,

02:45.46

Tony

outside of the built environment and more on the software side and looking how we can um accelerate the development, pick up on risk earlier on and bring more of that hands-on experience to the software world.

02:58.15

James McWalter

Amazing. So, you know, some folks who are listening, they might have seen our previous big white paper around behind-the-meter data centers. um That was our first time trying to write, you know, some piece of research that we thought ah would be interesting for the industry, for you know, and as well as tied to a lot of the work that we do day-to-day at Paces.

03:16.25

James McWalter

think one of the kind of interesting things we've always talked about at Paces is this idea of, can you, ah you know, de-risk faster, earlier in the development process? And if you can do that, what is the actual impact?

03:27.90

James McWalter

And so, you know, that's been something we've been working with our customers on. That's how we build our product. But I think one of the struggles we've had is, um you know, there was no kind of like in-depth, like empirical like basis for that kind of underlining it.

03:41.31

James McWalter

um And so, Just with that in mind, um you know Kyle, can you could speak to that kind of early genesis for why we did this white paper?

03:49.50

Kyle

Yeah, absolutely. So it really started with um a hypothetical. So like given, given, you know, what we know about the development process. So thinking through what it takes um to bring a project to fruition and get to notice to proceed, it requires a lot of messy desktop work. So basically thinking through a prospect of candidate parcels of land um and going through and vetting those parcels according to their, their different you know, risk factors or likelihood of coming to fruition. So right is it suitable for permitting? Is it suitable for the grid?

04:20.85

Kyle

Can actually design a solar farm to fit on this piece of land, given wetlands and environmental layers and other other constraints? So git just getting to a quick answer, a yes or no answer, or, you know, a likely answer requires mucking through tons of desktop data.

04:34.32

Kyle

um And so what we're seeing from, you know, advances in in AI and a lot of like the work we've done to clean up geospatial data and reason through it in a more automated way. We thought like, what would the impact be on the development industry and project you know ah ROI if the marginal cost of doing that de-risking work continued to plummet and go down to zero? Like where would you see those those benefits show up in the process?

04:58.00

Kyle

um And I think like, you know what we embarked on was really trying to to answer that question to the best of our ability.

05:05.34

James McWalter

I guess for you, Tony, right so we always like talk about this, you know X percent, 80%, 70% to 90% of projects at our post-site control end up failing. um yeah This failure rate is obviously very, very high.

05:18.09

James McWalter

um i guess you know with your developer background and experience, i guess can you speak to ah you know your experience of you know the underlying reasons for why projects fail or the associated risks?

05:29.53

James McWalter

And then I guess start to touch upon why those risks happen suboptimally too late in the process.

05:35.96

Tony

Yeah, absolutely. ah So as Kyle mentioned, historically, uncovering these risks has been a longer process. It can be done from a desktop perspective. um But a lot of of these tools are often fragmented.

05:48.53

Tony

ah Some of the the data is unreliable. You can't really rely on one source of truth. So ah depending on the development strategy, you try to get an understanding of what could fail.

06:00.34

Tony

earlier on, but again, there hasn't been historically one source of truth for each of these different um risk categories, as Kyle mentioned. Permitting, interconnection, land use, those different types of of resources you have to go to different sources to get an understanding.

06:18.59

Tony

um And often, that is quite time consuming. And because development ah is a time-capped objective, you want to get products built as quickly as possible, you often forego that desktop diligence and, ah for example, move straight to site control.

06:34.44

Tony

Getting engaged an engaged landowner is a huge part of site control, and you may target that first before uncovering any interconnection risks or permitting risks or a wetland going through that parcel that you may not have picked up on earlier on. So a lot of those risks can come up later in in deeper diligence, um but there hasn't historically been an easy way to pick up on all those risks earlier on. And then discovering that later down the development process so is often what leads to a project failing.

07:03.88

Kyle

Yeah, and I think um building off of that, I think like what that comes down to and and a term that we hear a lot in industry is like soft costs. Like it takes time in terms of development hours to get to those answers that that Tony's mentioning by going through those, you know, um procedures that you have to go through to essentially determine the viability of a given site. And so that materializes as lots of time spent and money spent per site getting to an answer. And then also, you know, if you like broaden this out to the full development pipeline, lots of time spent on developing projects that have no shot from the get-go, but it takes too long to get to the now, right? So thinking through like, what is the impact or the how how how can you quantify the impact of these soft costs in a development pipeline um to ah ROI in the broader industry? that That's kind of like the the essence of the problem.

07:51.19

James McWalter

I guess one of the difficulties with that, right, is there's so much variance on an individual project basis across soft costs, right? And a lot of that variance is due to where the site is, where the project is happening.

08:03.23

James McWalter

You know, you have all these authority having jurisdictions, you have the counties, you have different utilities, you have different ISOs, you know, you have just like a kind of wealth of like differentiation. um And so I think one of the reasons as, you know, we started having this early conversations and you guys were like picking through what this white paper could be, you know that kind of came up as that standardization piece. like How do we look at standardization?

08:25.26

James McWalter

And so I guess like when you were talking to some developers, you know you ended up deciding to focus on an archetypal town, it the town of Arcadia in a New York State.

08:38.04

James McWalter

um I guess what made that ah like a useful test case and why was that the kind of ideal idealized methodology to move forward with?

08:47.25

Kyle

Yeah, I think it really stems from the complexity of development, right? So we wanted something that's empirical and like whenever you're doing science, you want to be able to really um go deep and make comparisons between, you know, different different attributes, ah or basically do a comparison between two things, right? You want to be able to control for variables and you also want to want to be able to measure the impact um of of what you're testing for. And so, you know, I think where we landed on Arcadia primarily because or primarily because we wanted to like really go deep in a specific area to show that like between different types of sites within a common market, you can still have so much variance between, you know, the types of risks that you're looking into. um So this is what kind of led to, on the paper, the idea of a um a project archetype.

09:33.40

Kyle

um So thinking through like, okay, even within a, the same township, given that the permitting process as outlined by, you know, at the planning board of the town,

09:44.14

Kyle

depending on those attributes of the given site, you could have like a ah development process that looks different based on the characteristics of that site. So whether it's close to a given wetland, you may want to front load wetland and do de-risking earlier, or like the the relative weight of like the risk factors of what could kill the site actually vary even drastically within a town.

10:02.24

Kyle

um and so Showing that, though, and understanding you know the development process within one given town very well, allowed us to like lay out exactly what those milestones are to get to NTP and understand the guts of an ordinance.

10:14.88

Kyle

um That is like ah a zoning ordinance for one town very well. So we could take a step back and be like, what are the the general principles and how do these milestones you know within one town, how could they possibly carry over to to different towns as well? And so you know this town was particularly representative of some other ones we've seen in New York. And so we thought it was like kind of the most generalizable sample we could go deep on.

10:34.59

James McWalter

I guess, Tony, you know, archetypes and like models, you know, right, they're only as good as how they map to the real world. As you were kind of like working through these project archetypes, I guess, could you speak to, know, Kyle mentioned a couple of them, but like what all those archetypes were and how well, in your view, they mapped to the actual like lived experience of being a project developer working on these projects?

10:41.94

Tony

Thank you.

10:54.76

Tony

Absolutely. um In my experience, actually getting these projects built in the ground, um these archetypes really map truly to which type of risk you want to pursue first.

11:05.71

Tony

um Learning that something might fail later on in the process is has large financial implications. um So getting an understanding of these archetypes and then pursuing that risk category first ah to get an understanding of whether it's a a go or no go,

11:21.17

Tony

um is equally as important as getting ah project across the line. So the archetypes that we laid out are in four categories. You have environmental constraints, um permitting complexity, and that comes with sentiment, design feasibility, and capacityibility capacity viability.

11:32.99

Kyle

you

11:37.34

Tony

On the environmental constraints, that would be looking early on from a desktop perspective if there would be any environmental red flags like floodplains or wetlands that would be worth taking a deeper look at.

11:49.77

Tony

A big part of this is understanding how much development spend or upfront de-risking do I want to do to pursue ah this potential risk without foregoing the others.

12:02.13

Tony

Permitting complexity, it can be all the way from getting an understanding of the ordinance of how hard it would be to get a special use permit, for example, as well as just the placement of the site site if you have residential abutters who could potentially um put up a disagreement when it comes to the town hall.

12:20.87

Kyle

Thank you.

12:21.57

Tony

Design feasibility is just looking at the site from a pure layout perspective. Maybe the site looks great on all archetype perspectives, but there are there's a slope that could affect your design or the point of interconnection is further back than you may have expected just initially looking at it, and you have to get several easements to get to that to that point of interconnection.

12:45.24

Tony

And finally, looking at the capacity viability, which is really the interconnection component, getting an understanding of What capacity ah for injection is there on that line as well as on that circuit tying into the substation?

12:59.77

Tony

Is that substation going to support the type of project I want to deliver? Are there other developers in the queue ahead of me? And getting an understanding of those four different legs early on really helps you decide which you want to pursue to de-risk and spend more development spend to get an understanding of whether the project is viable or not.

13:20.39

James McWalter

And I guess like on that kind of financial piece, Kyle, so, you know, one of the kind of core, I guess, data science approaches was to run lots and lots of versions, right, of the, you know, of the of the model, um what's called Monte Carlo simulation um to kind of show how, you know, risk evolves, how it affects ah that potential spend.

13:40.87

James McWalter

I guess, can you speak to, I guess, the you know, the financial implication piece as well as a little bit more in the methodology for like how, you know, why that Monte Carlo use case or approach makes sense in this particular example.

13:53.49

Kyle

Yeah. So basically, when we set out to quantify these soft costs, um, we realized like there's no data set that exists that can perfectly tell you like, okay, you know, it costs this much to develop X project that failed. Like there's no massive data set where you can do ah a traditional modeling problem and, um, basically do, a typical, like supervised learning predictive problem where you have map inputs, maps to outputs directly. Right. So in the absence of this data, we basically had to do is take Tony's brain and the brains of lots of other intelligent developers who are customers of ours and go through and say, okay, from first principles, what are the specific milestones and things I need to do to get a project built?

14:34.30

Kyle

And then also talk to them about what are the typically the most expensive steps and what are the their budget ranges of these steps and what are the typical timelines of these steps um in order to get this project built for or from what you've seen, right? So you know a typical study may cost between and you know X and Y one thousand dollars and may take between 30 and 60 days, right? So across the risk factors that Tony laid out, um we have budget ranges and we also have timeline ranges.

15:01.33

Kyle

And so based on that development experience, what you can do is take a step back and be like, okay, I know I need to sequence it in order to get um to this answer, or need to sequence and achieve these milestones by doing these steps in order to get to this outcome.

15:15.12

Kyle

And because there's randomness involved, you can basically take a step back and say, I'm going to just run this model a thousand times. and get to an answer that really tells this representative picture um of you know what is the most likely development outcome if I were to to build a project in the town of Arcadia, New York, based on um you know the modeling steps that we identified based on those milestones, but also the empirical data that we were able to gather through speaking with developers and and civil engineering firms in the community to get a sense of of what these steps typically cost and how how long they typically take.

15:48.18

James McWalter

I guess like from the the ah longest time period and the most costs to the shortest time period, right? And the ideal, you know, the ideal is Scott. How big of a differential was that?

15:59.38

James McWalter

but You know, how how much of variance was that? Tony. Tony.

16:04.46

Tony

So what Kyle laid out here is the financial risk that, yeah as as you mentioned, you have a lower end of the range to a higher end of the range. There isn't a standardized range across the board, but there is kind of within each risk category.

16:19.93

Tony

So interconnection, for example, um if you submit an application for a CSER in the state of New York, ah you could ah get a result where the upgrade costs are on the lower end between $100,000 all the way up to potentially $1.5 million. and That is a massive range that effectively could would be a go or no-go on your project, depending on how it pencils and what your IRR is after absorbing that cost.

16:45.42

Tony

um For the environmental archetype, the range of ah items you could look for was larger, but the range of cost was much smaller. So you could do a wetland delineation where the variance would be potentially um 50% of the the cost to to mitigate that wetland, but that comes nowhere close to the interconnection archetype where the upgrade costs are much higher.

17:08.77

Tony

So depending on the archetype, you did have ah quite a bit of range, but each of the archetypes had a specific range that would yeah would even would either be a pass or fail depending on the the cost.

17:26.38

James McWalter

I would like you, Kyle, to jump in. what like if I think of this blue and red, for the editor, this is me just talking, and we'll reconnect in a second.

17:33.97

Tony

Yeah.

17:35.06

James McWalter

and So you think of that blue and red. that That was helpful, Tony, but I'm also talking about like...

17:39.38

Tony

That's great.

17:39.44

James McWalter

um

17:39.93

Tony

Hmm. ah

17:40.82

James McWalter

Yeah, yeah. So that as you're moving um from right to left, like what is the, you know, are we like halving the time? so like the money costs the same, right?

17:50.61

Tony

um

17:51.69

James McWalter

Like, but it's like, oh, you're better you know, if all the things go well, you can get your projects done, you know, 30, 40% faster. um And then also you can fail faster, right?

18:01.83

James McWalter

It's that kind of combination. So that that's more I was getting to, like if they saw this this graphic.

18:04.45

Tony

Yeah.

18:06.25

Kyle

Yeah, I was literally looking at the graphic, trying to do um the mental math of exactly what that that shows. Sure.

18:13.31

James McWalter

Yeah, so i think I think you can just say 30 to 50% faster. um The cost will be pretty similar just because in the end it's development costs, but yeah um from a portfolio perspective. So yeah, if you just want to touch upon that, Kyle.

18:23.40

Tony

yeah

18:24.15

Kyle

sure Yeah, so basically what we found you know in the best case scenario is that you can reduce the development timelines by 30% to 50% when you lay out all of these milestones that you have to achieve. So the budget will remain relatively similar because there are certain expenses you have to incur along the development process.

18:41.61

Kyle

But I think the the key lesson here is that the compression of the timelines provides very, very tangible benefits for developers and then also the ability to fail faster for the projects that ultimately don't get built.

18:53.23

Kyle

um So if you if you were to expand kind of the returns of the the project or your pipeline over the course of like looking at portfolio IRR, so you're basically looking at, you know, the two types of risk, the risk that a project will actually get approved or denied at a given stage gate or milestone, very common in permitting to just be denied the ability to build the project.

19:13.00

Kyle

um But also, you know, the costs incurred as you, it's it's kind of like a death of a you know, death from a million cuts where you're, you know, oh, well, the POI needs to go around this bush in order to protect this type of animal and like your development expenses continue to rise per project.

19:28.29

Kyle

Overall, if you're looking at like the total portfolio picture, basically um breaking it and breaking that down, um you're you're able to realize like, you know, very, very strong cost savings by removing the dead weight from from your pipeline by adopting a strategy that really allows you to to fail faster and realize those savings.

19:47.80

Tony

And just following on that, one of the the fun exercises that we looked at, um as Kyle mentioned, was the financial risk as well as the approval risk. um So the financial risk really was just a metric to see the probability of increased devx throughout the development process.

20:05.17

Tony

And the approval risk was the likelihood of project failure at a specific development stage. um And that was really interesting to see in permanent, for example, where ah the risk is really binary. Either you get a project approved or you don't through the board.

20:19.79

Tony

But the financial risk with increased CapEx, or DevEx rather, was interesting to to layer over time, as Kyle mentioned. As you uncover more throughout the interconnection process, what does that then do to your project IRR?

20:35.47

Kyle

Yeah, and I think at the the very end of the white paper, we just you know make that very, very clear. What does a pipeline look where you get all your projects built, but you have very, very high development costs incurred?

20:43.63

Tony

Thank you.

20:45.15

Kyle

And then what does a pipeline look where you have all of your you have fewer projects built with low development expenses for those projects built, but you had a lot of projects fail or but lot of projects that you spent lots of money on developing that ultimately didn't make it.

20:58.11

Kyle

So there's kind of two ways that you can kind of um approach that how you modulate portfolio IRR.

21:11.86

James McWalter

One of the areas I know as you're kind of writing this that I think was very interesting is you talked to a lot of developers and particularly folks across the finance side as as you've been kind of chatting through. um I guess like, you know, as you had folks who were giving comments on early drafts as well as, you know, since the white papers come out, um what's some feedback, anything that kind of folks have kind of given you feedback on that were surprising or areas where, you know, you know brought to surface things that you didn't expect?

21:37.62

Tony

Yeah, it was a really interesting process to go through because the development world isn't just one type of shop. You have quite a few different types of players all trying to reach the end set the end goal of getting megawatts built.

21:51.69

Tony

um We surveyed a number of these development shops as well as IPPs, and I think a big takeaway for me was um developers who are taking a project from origination through to NTP saw much more impact on saving time as well as upfront development spend on this process.

22:11.28

Tony

And what we learned was this was less of an impact for IPPs or independent power producers who develop and then own and operate the system through 20, 30 years.

22:22.38

Tony

The way that their financial models worked was you could absorb and bit more of that development spend upfront and then your returns over 30 years can amortize over a longer period.

22:33.83

Tony

But if your development strategy is then to to sell the project or kick it up to an IPP at NTP, all of a sudden that condensed timeline and time and money saved in the early development stage had much higher impact long term.

22:50.52

Kyle

Yeah, absolutely. Yeah, building off of that, I think like exploring this, like the different transactions that occur throughout the development process was incredibly helpful to understanding how different parties in the transaction evaluate risk. So to Tony's point, an IPP that's taking everything from Greenfield through owning and operating.

23:08.99

Kyle

um Everything is tightly bound within an internal process. can therefore move a bit quickly because what happens when you begin selling a project or going for outside financing, um when you're developing a project and and looking for ah you loan or an investment to basically take on big development expense such as like an interconnection deposit there's an element of trust required to bring your financier or your new partner up to speed here or what we're kind of like basically pinpointed as transaction costs and so exploring and talking to a lot of the you know the early develop the capital providers in the early development process really helped us understand how they look at risk and how multi-faceted it is in particular so basically like if if you're

23:29.18

Tony

Thank you.

23:51.94

Kyle

you know, loaning, ah you know, investing in a project or working with the developer to give them, you know, capital for an interconnection deposit, you also have to, your underwriting methodology also has to account for all the other risk factors because the ability to get a return on your investment is dictated not just by your interconnection,

24:07.94

Kyle

risk, but about whether your developer can go and get permitting, right? So I think like, you know, exploring how transactions occur up and down the development process really allowed us to open the box a bit and understand these milestones better.

24:19.84

Kyle

um Not that these milestones in the risking methodology does not occur within IPPs, but you're just going to internal ICs. And I think the process is a little bit more bundled up and tighter than when you have to really demonstrate your risks or speak a common language to um new partners, bring them up to speed on your portfolio, bring them up to speed on, on, you know, a program that you've entered, that sort of thing.

24:42.88

James McWalter

you know i think the so you know I love the fact that we kind of got in and i encourage everybody who is listening to to this to check out the links and kind of go, you know you see financial models.

24:55.87

James McWalter

um And you know we've we've had a a couple of folks that that also kind reached out to me after we published it and had some kind of really interesting commentary and thought it was like a really kind of compelling vision for how this stuff can work.

25:06.79

James McWalter

I guess like what argument is why it doesn't work or couldn't work and or historically hasn't worked is because it is very, very difficult to do a lot of these de-risking steps in a cost-effective way. Our kind of thesis of basis is that as software, machine learning, various types of automation tools get better, there is this opportunity to basically automate pretty manual, difficult de-risking steps in a lower cost way than historically been done.

25:34.06

James McWalter

you know way that have historically been done I guess, you know, starting with you, um Tony, you know, presuming, right, and again, everyone should read the white paper and and and and listen to, the you know, to you two today and to make of their own mind, but presuming, like, the findings of the white paper are correct and are valid, you know,

25:44.72

Tony

Thank you.

25:44.80

Kyle

Thank you.

25:51.70

James McWalter

Talk to me how this can basically be applied to the industry. The industry has been, yeah I think, reasonably circumspect and a bit um careful about adopting too many automation tools.

26:03.65

James McWalter

um And you know because in the end, we're trying to get steel and ground like out of the project. is going to move forward it or not. And there's a lot of risk elements to that. um From your perspective, what needs to be true about the types of automation tools that Pacer or other you know companies in the space need to build and the quality of those tools, what they need to be in order to actually be adopted and you know put into action in the actual findings in this white paper?

26:25.68

Tony

Yeah, that was, i think for me personally, the the most fun part or the interesting most interesting finding was coming from this world and having done this myself, but then speaking to a number of developers who are also trying to accomplish the same goal.

26:39.78

Tony

We're all going through the same stages, but we're all looking at kind of different stage gates and we have different matrices and the with the same end goal.

26:50.84

Tony

ah So what was really interesting was putting together ah step by step what exactly is happening based on my experience, based on the many developers that we spoke to, and literally putting them down ah step by step.

27:03.30

Tony

How long does it take? um What happens at this point to get to the next stage gate? So really modeling that and kind of shedding some light on maybe what's historically been a bit of a black box was a really interesting finding because we're all working towards the same thing with different languages, but the steps are effectively the same.

27:21.06

Tony

um So I think on the automation piece, ah one of my biggest joys having been at Paces is uncovering ah from a first principles perspective, why why do we have to do this in a manual way?

27:36.24

Tony

If we can maintain the same integrity of the end result, why do we have to subcontract this ah this specific task that would take potentially a month to turn around and use a bunch of development spend?

27:48.60

Tony

um If applications by the utility are being accepted in the same way, why do we all have different ways of submitting them? So going through and... doing the manual work that all these developers have been doing historically and looking from a software perspective and having the the team of brilliant engineers here really just shadow us piece by piece, looking at the workflow as from a desktop perspective, what am I clicking on next?

28:05.84

Kyle

Thank you.

28:16.73

Tony

What is being generated in this report? Can this portion be automated while maintaining the same data integrity has been ah Quite an interesting and fun process for, I think, all of us at Paces.

28:29.11

Tony

ah But the end result is we can cut down, at least from our findings, we can cut down the time significantly spent without ah losing any of the data integrity of the end result.

28:40.73

Tony

And that leads back into the point of if this is taking four to six weeks being subcontracted or being done by multiple fatigueque people on a team while they wait on results, why can't we do this in a faster way and then front load that risk?

28:55.07

Tony

And that's ultimately the the the thesis that we're trying to prove with this paper and what we're trying to do at PASES.

29:01.32

James McWalter

Yeah, and i think, you know, building on that, the, you know, i think the standardization point is like so interesting because historically with straight up, you know, business to business software solutions, things have to be 100% standardized to do anything because software has been kind of what they call deterministic, right?

29:15.48

Tony

Thank

29:20.52

James McWalter

You click on a button, action occurs, and it's always the exact same action every single time. And because there's so much kind of variance on the development plan, you have to do a certain amount of standardization to build any sort of software. and think what's kind of interesting, Kyle, and I know this is like a lot of the the work you do to Paces, is that, you know, combining some of this deterministic elements through standardization with a bit more, ah you know, probabilistic functionality that are enabled by things like large-angle models and like associated elements.

29:50.43

James McWalter

You know, basically, how do we retain the deterministic pieces, right? If the floodplain is there, it's there. um You know, you you don't want to like ah a model or something guessing at that.

30:01.72

James McWalter

um But while taking the advantage of, hey, look, there is certain areas of like where standard perfect standardization not going to be possible. There's going to be a lot of variance on an individual project or site basis. How can we kind of balance like this set of tools like classic software automation that use deterministic structures versus something that's a bit more probabilistic like some of the more recent models? And I guess like, how do you think about that?

30:22.85

Kyle

Yeah, I think that's, um you know, it's it's the ultimate question. And and and that's what really, i think, allows this direction to occur at this given time, given the advances we've seen in LLM's ability to reason at scale. So basically taking advantage of a lot of the deterministic identification around, you know, sensitivity to wetlands or capacity,

30:44.85

Kyle

metrics, um those things that developers are going through and finding and are fairly black and white helping them paint the picture. But I think, you know, the case where you're finding more unstructured data or you're doing some basic reasoning through that data allows us to take that desktop component much more farther, much more, you know, but further than than what typical software has been able us to do and really create this composite picture of like what it gets down to is the financial bill of the first cut of the financial viability of a given site, right? So it's like, if if you were to take the desktop diligence that's being done and compress it to the marginal cost of zero, given deterministic software and given advances in in LLM's ability to to reason through that data,

31:28.95

Kyle

You can get a basically an 80-20 development plan um that essentially gives you a first cut of of what is the what are the major risk factors and what is you know my forecasted IRR with some degree of of viability there.

31:43.48

Kyle

um And I think if you blow that up and you're able to say, okay, well, this not only allows the developer to move move faster um and basically maintain these loose financial models across a portfolio and and basically avoid a lot of this time consuming task, it also allows us to like look at markets differently. I think so much of um a lot of what we talked about in terms of development strategy is is chasing a lot of like the revenue side of the equation. So chasing new tariff structures, um you know juicy new incentive blocks in different states and everything like that.

32:15.63

Kyle

But if but you're looking at like a lot of the supply side of the equation or the difficulty of developing ah developing developing those projects, because it's such an unstructured data set, you know, we often talk about like the supply side difficulties of developing those projects in generalities, like permitting is tough in market X. Whereas if you're able to do this reasoning at scale and get to that picture more quickly, suddenly we have this ability to look into like the supply side of a given market in ah in a way that's approaching our level of, you know, fidelity and into the demand side or the revenue side of the equation. And i think that would really allow us um to to paint a ah better picture of you know what's possible or allow development strategy to kind of shift based on like how difficult it really is to build in difficult permitting environments or or go through the interconnection process in a highly congested area.

33:03.45

James McWalter

i was yeah I think somebody once said to me the joke of like, um where when are we going to see DG solar in Oklahoma? Right? Well, there's no community solar law in Oklahoma. It's like very far away, but like permitting is super easy. Land is very cheap.

33:16.82

James McWalter

um You know, you actually could potentially de-risk all the other aspects. Now, again, I'm not saying that that's the strategy that folks listening should should actually target, but I think it kind of gets at this idea that, you know, to do like a proper risk return profile on any individual development strategy,

33:30.42

James McWalter

um You need both inputs, the but the the the revenue as well as the the costs, both you actual costs as well as um yeah some of the costs we already talked about. you know one One of the kind of common things that that comes up a lot for us at Paces is is you know we have yeah a customer and then maybe some couple of developers spin off and start their own one to two person shop.

33:51.52

James McWalter

um And then you know they they they'll work with us. we We love getting those kind of folks, those entrepreneurial folks kind of up and running um as they you know form their development shops around a specific strategy. guess, Tony, you've been kind of that world.

34:06.53

James McWalter

you know were to talk to a kind of new developer starting out, right? And they read this white paper and wanted to kind of like leverage this framework.

34:10.31

Tony

Mm-hmm.

34:14.59

James McWalter

to save time, you know, reduce some of their dead ends and and improve outcomes. I guess like, you what would your kind of advice be to for the first couple of months? Like what should they do? What should they actually, I mean, besides of course working with faces, but what are some of the ways that they could get up and running fast and kind of like start leveraging this kind of thing?

34:30.85

Tony

I think it'd be an incredibly exciting time to to start a development shop. um One key piece is what we discussed quite a bit, but just speed to getting to a site that is viable. ah There are very large implications, aside from just the financial implications and of less dev spend upfront. But speed to a market ah really affects what trend you could bid into an incentive program, for example.

34:54.87

Tony

If you've targeted a market, and you know what incentive pool ah you are trying to to bid into, they often work in tranches where the highest dollar per kilowatt is at the top. And once that tranche is fully ah saturated or taken by another developer, then you move to the second tranche, which is still a great option, but less attractive than the first.

35:16.90

Tony

And in most incentive blocks and in different states that have these programs, you have up to five tranches.

35:21.47

Kyle

Thank you.

35:23.80

Tony

So speed to getting to a viable site can then lock you into a higher tranche, which then has ah immediate impact on your IRR based on how your project pencil once it's built.

35:35.35

Tony

um So if I were starting a shop, I would leverage tools like these. I would look at de-risking as early as possible once I know what market I'm in. and try to bid into these programs as quickly as possible. And that time that you ah could be de-risking later on or finding out that there's a critical flaw post-landowner engagement, post-interconnection application, ah because you hadn't fully vetted one of the archetypes like ah the the environmental layers, that to me is extremely powerful because I don't want to be ah entering a new state, entering into a block, and then all of a sudden

36:11.57

Tony

finding out that my project's no longer viable. And then once I do find a project that's viable, bidding into the third tranche as opposed to the first.

36:19.67

James McWalter

And I guess for you, Kyle, just as we're kind of close to ending up here, you know, what's one insight from the white paper or, you know, or the work that you did to kind of put all this together that you think just more people in the industry need to understand or like act on fast?

36:32.78

James McWalter

um And I guess like how do you see the industry evolving with the implications of the white paper and and the other work you're doing?

36:40.34

Kyle

Yeah, I think it, um

36:45.17

Kyle

what it really comes down to is, is you know, what i touched on previously, it's like, I think we, Tony and I actually only looked at, you know, several risk factors. There were others that we were including and or talking about early that that we neglected just because we needed to, um basically we wanted to do a a few things well. So for example, like to Tony's point, um market program risk, like getting into different market incentive programs more quickly. And then another one that was very big that came up through our conversations was a procurement risk of basically being able to

37:17.48

Kyle

you know, given the supply chain constraints we're we're seeing, um you you know, how does the the timing and kind of like the safe harboring rules allow you to sequence, ah you know, the different aspects of the development project of the process across like interconnection environments or with like ordering equipment and ah and ah and ah in ah in the right moment in the right um order of operations, right?

37:37.80

Kyle

So I think um the big thing i think I'm left with is like, you know, when you just the I keep saying like the word marginal, like lower marginal cost, but really what that means, to the essence essence is is building a financial picture as as early as possible across all of these risk factors um to take into account like, OK, to the best of my ability, what can I what can I create or how much information do I have from desktop alone?

38:05.34

Kyle

And then Leighbam, Ph.D.: sequencing work to basically say what do I need to de risk first in order to get that highest quantity of information right so going back to the archetypes concept. Matt Leighbam, Risk is risk is relative across any given project right like what's going to kill one project may not kill the other.

38:21.44

Kyle

Leighbam, Ph.D.: you use that deterministic high quality data, as well as a lot of that you know pre development work, you can go in. with a picture of what do I need to achieve with my man hours, is the stuff that can't be automated, what relationships do I need to form to get to the most important answer most quickly.

38:38.13

Kyle

um And I think that how that shifts over the course of like, you know, what type of a project or what type of like even site within the same type of projects, ah and how that varies i think that was like the the biggest insight is you know we human human time is now going to be the biggest bottleneck here how can we use human time and relationship and the human element of relationships as effectively as possible to continue that de-risking and and fail fast

39:03.08

James McWalter

Fully aligned with that. Tony, this has been great. I guess before I finish off, there anything I should have asked you about but did not?

39:09.28

Tony

Yes, so obviously this has been a joy working with Kyle and and gathering all this data and talking to all these different developers. And ah since we built this 80-20 development matrix, as well as gathered a bunch of the the financial pieces, what we wanted to give the reader or an ultimate customer the opportunity to do was to play with these different levers. So we built a very simple probabilistic financial model um just to talk about the different archetypes and actually give the user an ability to to play with the sensitivities, to look at the implications on both project IRR as well as portfolio IRR,

39:48.40

Tony

and get an understanding of the analysis of if I have a portfolio of five megawatts ah in New York State, if five of them have a high environmental archetype risk and then a lower financial risk on the interconnection front, what does that actually look like? So wanted to just give the readers a fun, a little interactive tool to actually ah play with the data that we've modeled.

40:12.22

James McWalter

ah you Thank you, Tony. And is there anything I should have asked you about, Kyle, that did not?

40:16.40

Kyle

Um, yeah, just basically wanted to flow for anyone listening to this, who's gotten this far. Um, we, the product team at Paces loves talking about, um, these development challenges and a deep level of detail. we're really interesting, ah interested in hearing, hearing from you, what resonates and what does not. And, and, and as we take steps to actively build a lot of the, um, standardized development plan into the product and, and, um,

40:38.69

Kyle

move this along, really thinking through um exactly you know how to how to go about that and how to work with you um to accelerate your your timelines is is something where we're always open to exploring.

40:49.03

Kyle

um So yeah, looking forward to to hearing from the audience and and you know advancing this future as fast as we can.

40:55.88

James McWalter

Absolutely. Definitely underline on both of those kind of sentiments. Yeah, really appreciate the work you put in and then all the other kind of folks who added their comments, customers who gave us their time to kind of speak through what became this white paper.

41:09.56

James McWalter

um I think there's a lot of like really interesting directions to kind of continue this work and, you know, build on ah the work that we do, the work that, you know, the best developers in the industry who, you know, we're grateful to call our customers, um give us kind of continuous insights.

41:22.59

James McWalter

um Thank you so much, Tony and Carl.

41:26.19

Kyle

Thank James.

41:26.28

Tony

Thank you, James.