To be or not to be a project developer?

Every climate project requires development - with all the talent, expertise, and resources that entails. You can either build this capability in-house, partner with an external developer or customer, or outsource project development entirely. But how do you figure out which path is right for your business model? 

This is the second of a series of Insights with Hannah Friedman, of Mark1 and Planeteer Capital, about what it takes to incorporate best in class development principles within early-stage technology companies. Here, we look at what external vs internal development looks like, and whether early-stage climate companies should approach development externally or internally, based on your deployment type and business model.

Forms of external development 

While you might have your sights set on building and owning everything yourself, doing so can be hugely expensive and requires specialized expertise. Enlisting a partner – a customer, developer, or EPC (engineering, procurement, construction) firm – to handle building, owning, and operating the project could leave you more free to focus on your technology and other aspects of growing your business. If your tech is proven, its economics and performance are predictable, allowing external developers to simply copy and paste can be a very efficient way to scale. How to get there? Ay, there’s the rub. 

When your tech is new (read: risky) and you don’t have a track record of repeatedly building it in the real world, the less likely you are to find an external, third-party developer willing to go on the journey with you. An external developer will typically want a playbook, which you won’t have if this is your first time. This is where players like Mark1 can come in and co-create the playbook with you. 

Plus, even if you can find external developers, they can sometimes be hard to incentivize and even harder to manage. If you don’t know what you don’t know about all the ways it could go wrong, how can you convince someone outside the family to care for this project like it’s their own baby? 

How in-house development might look 

While objectively harder, building and owning development yourself may be the right option for your company. Building these development capabilities will take time, no matter your business model or deployment type. Start with looking at who you already have on the team, and what talent you’re missing. By having project development talent on your roster, you’ll internalize lessons faster and eventually either earn out or make those lessons part of your secret sauce. The watchout early on is culture differences; developers are risk mitigators and technology innovators are often risk takers. Each is important, but ensuring that decision making structures and communication are clear will be mission critical.

Sometimes you can supplement early on with advisors, who may transition to a fractional role. But be wary of consultants only – development is a long process and you want someone who can execute quickly, isn’t incentivized to take their time and can be in an at-risk position with you in the project. 

There’s no wrong answers, but there’s a time and monetary opportunity cost if you don’t recognize how to dial the development lever. Below, we parse considerations within your development type and business model that should inform your decision to develop internally or externally and when. 

How your tech type plays a role in this decision

The answer to the question - to develop alone or not to develop - will start to emerge by first looking at your deployment type.

1. Greenfield facilities 
These large, centralized facilities start off as a piece of land with no power, no permitting, and no history of development – everything has to be built from scratch. There are thousand-row spreadsheet checklists you must use to develop your own greenfield facility alone.  It’s a big lift.

2. Bolt-on, modular facilities
Sometimes called a brownfield site, perhaps you’re working with an existing facility with power, permits, documentation, etc. While it might need modification or a handful of extra integrations, much of the groundwork has already been laid. 

3. Distributed deployment of assets 
Many technologies are delivered as-a-service and spread out across a wide geography, like EV chargers. These models often carry far less tech risk and the development involved is less intensive – maybe you only need one signed piece of paper from the city and you can then deploy anywhere within the municipality, freeing your focus to stay on building a pipeline of customers or sites, qualification, and executing at scale. 

4. Manufacturing facility
Sometimes in addition to the deployment types above, you may also have to build a manufacturing facility. If you’re a direct air capture (DAC) company, in theory, you could deploy your system anywhere like a distributed asset, but you’ll need a manufacturing facility to print the novel component parts of that DAC system. 

How your business model plays a role

Your deployment type often – but not always – determines your business model. 

For example, you might license a new production technique. That business model is asset light if you own the IP and just want licensing royalties. However, because the production technique enables a product to reach new markets, perhaps the deployment model is greenfield facilities. Someone has to go develop the site, work with local communities and build the factory that will put your licensed production technique inside. If no one’s willing to develop that greenfield for the first time, you might have to show the production technique works in a brownfield deployment first and attract customers to start licensing it for greenfields. This has different implications for with whom and how you consider your role in development over time: leveraging a customer or brownfield JV partnership first, then equipping external developers with your playbook when they develop greenfields. 

If you need a manufacturing facility to produce your DAC units, you might find that your best business case emerges when you decide to own and develop this facility yourself and be the original equipment manufacturer (OEM) at scale. But your business model is also influenced by your customer adoption, and it can change over time - especially as risk goes down. If your customers don’t want to buy your equipment off the shelf before it’s proven, you might have to deploy a number of units as distributed assets that you own and maintain, selling their output only, so you can earn the right to be an OEM down the line.

Often, one of the biggest challenges is when a company wants to sell a component part or feedstock - like a membrane or a sorbent or an input chemical - but has to demonstrate the full, greenfield facility themselves before others will consider partnering up to develop and build more.

So, the questions you’ll need to ask yourself around this decision will cover where you are in the process; your near-term business model versus your long-term business model; how you want to capitalize the business; plus, the market timing overall when capital markets may have different risk appetites. 

Three questions to ask

When you’re thinking about the long-term expectations of your business model, you can ask yourself these questions: 

1. What is your executive team going to be “best in the world” at? 
If you don’t already have project development experience on deck, take note that you’re in for a ride of meaningfully expanding your executive capabilities and work culture. 

2. Where does the business and your technology afford you the best margin? 
Mapping your deployment type and business model in the near-term and the long-term is one of the easiest ways to help make development decisions and align your team and investors to the vision of transition.

3. What are the expectations of your current and future investors? 
Your VC investors who get you started will not have the same expectations as your  credit or off-balance sheet investors, and watching this early will help prevent things from getting incredibly thorny down the line. You’d never want to be in a position where your VC board member is veto-ing your decision to hire an in-house project development team because they don’t appreciate the complexities of building your project in the real world. Set expectations and have a strategy conversation about tradeoffs early.

Indicators that you should develop in-house

1. You want to be on the ground
If you develop your project yourself, rather than leaving it to a partner, you can tighten the feedback loops on technical and product development.  This is most important when technology development is still ongoing with high ROI to boosting process efficiency or output yield, creating more favorable long-term economics. It certainly  risks cost overruns and mistakes, but could be faster than educating and negotiating with project partners.

2. You want to be the long-term developer, owner, & operator
If this is your goal for your long-term business model, and what you’re telling investors, you may want to build that muscle as early and as robustly as possible. In theory you can be the long-term owner / operator, but not the developer, though this is typically more rare. 

3. Nobody else will do it
This is true surprisingly often, and it’s especially true for riskier technologies. Because external developers love repeatability and certainty, not many are willing to take a swing at something very high risk without a pipeline they can continue to execute the same playbook for. If that’s the case, you’re on the hook for the development, and many companies end up in this position without realizing it. 

When to go external with development

1. You can move straight to your asset-light, long-term business model
Maybe you can move straight into licensing without ever having to develop because of the risk profile of your technology. Especially if you're very clear about that with customers, it may be worth the upfront education and investment of time with external project partners to develop it. 

2. Your customer or brownfield partner can do it
Another reason is if customers in your market segment have a history of development. Oil and gas, geothermal, and many of the renewables players fall under this umbrella, with robust development muscles and internal development “genetics” (read: processes, battle scars, EPC relationships, etc). You may be able to sell more quickly in your long-term business model as an OEM, for example.

3. You’re spreading projects across different regions
Development is local. Aspects in project development like community benefit engagement can mean live or die in projects. If your technology will be deployed across disparate geographies, it could make more sense to look for local development partners, perhaps led by your own in-house project managers.

Hannah Friedman is a climate investor and operator. She's deployed 10s of millions of dollars into early-stage companies and has directly supported more than $100M+ of fresh capital raised to invest in climate specifically. She spends an embarrassing amount of time with CFOs perseverating on capital stack strategies. Most recently, Hannah helped launch Planeteer Capital from scratch, a Pre-Seed climate tech VC fund looking for the next generation of hardware-enabled software. Grateful alum of Closed Loop Partners and Columbia University.