Climate co-founder trial: a four-stage vetting project

What happens when the person who can build your climate technology is also the person you may need to trust with equity, intellectual property, technical decisions, and eighteen months of hard work before the market gives you a clear answer?

That question is not a sign that you are being overly cautious. In ClimateTech, it is part of the work. Hardware manufacturing can take 18–24 months, field testing may run for 12 months or more, and regulatory approval can add another 6–12 months. If founder misalignment appears only after those commitments are underway, the cost is much higher than an uncomfortable conversation at the beginning.

A ClimateTech co-founder trial project gives you a structured way to observe the partnership before formalizing it. The goal is not to create a miniature version of certainty. No trial can guarantee that conflict will never appear after equity is assigned. What it can do is replace assumptions with evidence: how you make decisions together, how you handle incomplete information, how you communicate under pressure, and whether your technical and commercial instincts can move in the same direction.

The high cost of misalignment: why ClimateTech needs early vetting

Co-founder conflict is not a minor operational inconvenience. Research by Harvard Business School professor Noam Wasserman attributes 65% of high-potential startup failures to conflict among co-founders. In a software startup, a mismatch may become visible after a few sprints. In ClimateTech, the same mismatch can remain hidden while you are working through laboratory validation, manufacturing constraints, permitting, safety requirements, or procurement cycles.

That longer feedback loop changes what we need from a co-founder matching process.

You are not only asking whether someone is intelligent, experienced, or enthusiastic about climate entrepreneurship. You are trying to understand whether they can work with you through a sequence where:

• the scientific hypothesis may change after testing;
• the first prototype may be too expensive to manufacture;
• the customer may need a different deployment model than the one you imagined;
• regulatory requirements may reshape the product;
• technical progress may be real while commercial progress remains uncertain;
• the company may need to pause one path without abandoning the broader climate mission.

A strong technical candidate can still be the wrong co-founder. They may prefer research to product decisions, avoid customer conversations, or expect the business to wait until the technology is perfect. A commercially capable founder can also be the wrong partner if they push for scale before the system is safe, validated, or ready for field conditions.

The trial is designed to surface those differences while the relationship is still flexible.

The purpose of a co-founder trial is not to prove that a candidate is impressive. It is to learn whether the two of you can do difficult, consequential work in alignment.

This distinction matters. An interview rewards polished answers. A trial shows working behavior.

Stage 1: Define the technical archetype your climate mission needs now

The first step in finding a cofounder for a ClimateTech startup is not searching for a person. It is defining the technical role the company needs at its current stage.

That sounds straightforward until we look closely at the word “technical.” A startup developing a grid-monitoring platform may need a machine-learning engineer, an energy-systems specialist, or someone who understands utility procurement and deployment. A company building a new material may need expertise in chemistry, process engineering, manufacturing scale-up, or regulatory testing. Those are not interchangeable profiles, even if all of them appear under a broad engineering label.

Start with the next technical bottleneck, not the most prestigious background.

Ask:

1. What must become true in the next six to twelve months?

Is the priority a laboratory proof of concept, a field test, a manufacturable prototype, a software integration, or regulatory readiness?

2. Which decisions are currently blocked without this person?

A co-founder should close a meaningful capability gap. If the company only needs occasional specialist advice, a contractor, advisor, or research collaboration may be a better fit.

3. Which technical constraints are specific to the climate application?

Climate products operate in physical, regulated, or infrastructure-heavy environments. A candidate may be excellent at building software but unfamiliar with reliability requirements, installation conditions, energy economics, or the pace of industrial sales.

4. What kind of technical ownership will the role require?

Are you looking for someone to build the first system, lead a research program, manage external laboratories, translate customer requirements into product decisions, or eventually build an engineering team?

5. What does “good enough for the next stage” mean?

A research-stage company needs a different technical archetype from a startup preparing for manufacturing or field deployment.

It helps to write the archetype in three layers:

The third layer is where many early-stage teams become vague. They describe the ideal co-founder as “passionate,” “mission-driven,” or “a great problem solver,” but those words do not tell you what to observe.

Try translating values into actions. If scientific integrity matters, the candidate should be willing to report an inconvenient result rather than protect the original narrative. If speed matters, they should be able to make a reversible decision with incomplete data. If safety matters, they should know when a faster experiment is not an acceptable experiment.

This is also the moment to be honest about your own role. A technical co-founder does not exist to carry every technical responsibility while the other founder handles everything else. Climate products cross disciplines by nature. You need a working agreement about where ownership begins, where collaboration is required, and which decisions cannot be made by one person alone.

Stage 2: Design a 30-day operational trial

Once the technical archetype is clear, design a trial around a real, bounded deliverable. The project should be substantial enough to reveal how you work together, but narrow enough to finish within a defined period.

A standard operational trial framework uses 30 days and at least 120 hours of shared execution. That is not a magic number, and it should not become a rigid test that every startup copies without thought. The value comes from concentrated collaboration: enough time to move beyond introductions, but not so much time that the relationship becomes difficult to exit.

Before the trial begins, agree on three foundational parameters:

• Names and intentions: who is participating, what each person believes the trial may lead to, and whether the goal is to explore a potential co-founder relationship;
• Timeline and workload: the start date, end date, expected hours, availability, and how the work will fit alongside existing commitments;
• Project details: the deliverable, decision boundaries, access to information, tools, customers, laboratories, or datasets.

The project should answer an important question for the company. Examples might include:

• producing a technical architecture and risk map for an early product;
• designing a test plan for a climate hardware prototype;
• evaluating whether a component can meet the expected operating conditions;
• building a narrow software prototype around a validated customer workflow;
• preparing a field-pilot plan with technical, commercial, and regulatory dependencies;
• interviewing users and translating their constraints into product requirements.

Avoid projects that are mostly presentation. A polished slide deck can show communication skills, but it may not reveal how a candidate works through uncertainty. A stronger trial combines analysis with execution. The candidate might need to make a technical recommendation, test part of it, document the result, and explain what should happen next.

The project also needs a clear boundary. You should know what information can be shared, which materials are confidential, and which parts of the work are exploratory rather than production-ready. If the company has not yet been incorporated, do not assume that intellectual property automatically belongs to the company or to one founder. IP ownership and permitted use need to be addressed explicitly in a written pre-trial agreement or trial contract appropriate to your situation.

The agreement does not need to turn the trial into a hostile legal exercise. It does need to make the basic expectations visible before anyone contributes substantial work.

Build the trial around observable moments

A useful trial includes several moments where working behavior becomes visible:

1. Initial alignment: Can you agree on the problem, the scope, and what success means without spending the entire month debating the definition of the project?

2. First decision under uncertainty: When the data is incomplete, does the candidate make assumptions explicit and choose a sensible next step?

3. A changed assumption: What happens when a test, customer conversation, or technical review challenges the original plan?

4. A difficult trade-off: Can you discuss cost, performance, safety, timeline, and user value without reducing the decision to a single metric?

5. A handoff or review: Does the candidate document their reasoning so another person can understand and build on it?

6. Final recommendation: Can they distinguish what the evidence shows, what remains uncertain, and what the team should do next?

These moments are more informative than a general feeling that the collaboration was pleasant. Pleasant matters. It is simply not enough.

Stage 3: Execute the 120-hour shared deliverable

The operational trial begins when the project becomes real: calendars fill up, the first approach fails, and the team has to decide what deserves attention next.

For the trial to produce useful evidence, the work should be shared. Do not delegate the entire project to the candidate and then evaluate the finished result from a distance. You are testing the partnership, not commissioning a technical report.

Create a simple operating rhythm. A weekly structure might include:

• a short planning session to agree on the highest-value work;
• independent execution between meetings;
• a review of evidence, decisions, and open risks;
• one conversation focused specifically on collaboration and workload.

Keep the process lightweight enough that it does not become its own management project. A shared document can track decisions, assumptions, experiments, unresolved questions, and owners. The point is not to create a perfect system. It is to make the partnership legible.

Pay particular attention to how the candidate connects technical work to the climate problem and the business model. A prototype is not automatically a product. A lower-emissions process is not automatically a viable company. The partner needs to engage with questions such as:

• Who experiences the problem directly?
• Who pays for the solution?
• What existing workflow must change?
• What evidence would make a customer willing to run a pilot?
• Which performance threshold matters commercially?
• What costs appear when the idea moves from laboratory conditions to deployment?
• Which regulatory or infrastructure constraints could delay adoption?

This is where technical and non-technical founders can become unusually strong together. Y Combinator’s co-founder matching data indicates that 68% of matches combine a technical and non-technical founder, while 73% pair someone focused on a specific idea with someone more open-minded. Those combinations are not prescriptions, but they point toward a useful principle: complementary perspectives work best when both founders can respect the other person’s form of evidence.

The technical founder may see a materials constraint that changes the product. The commercial founder may see a customer constraint that changes the technical requirement. Neither perspective should automatically outrank the other. The partnership needs a way to bring both into the decision.

What to observe during the trial

You are looking for patterns, not isolated awkward moments. Early collaboration is rarely smooth every day. The more revealing question is how the two of you recover.

Observe whether the candidate:

• raises risks before they become emergencies;
• distinguishes a failed experiment from a failed mission;
• changes direction when evidence warrants it;
• can explain technical trade-offs without using complexity as a shield;
• respects constraints they do not personally own;
• follows through on agreed work;
• asks for help early enough for the team to respond;
• gives and receives direct feedback;
• treats documentation as part of the work rather than administrative overhead;
• stays connected to users, deployment conditions, and commercial reality.

You should also notice your own behavior. Do you make room for disagreement, or do you defend the original idea too quickly? Do you quietly override technical judgment because you are anxious about time? Do you expect the candidate to infer priorities that you have never stated?

A trial is mutual due diligence. The candidate is evaluating your clarity, reliability, and decision-making as closely as you are evaluating theirs.

The most valuable output of the trial may not be the prototype. It may be a shared understanding of how this team makes decisions when the prototype is wrong.

Stage 4: Formalize equity, IP, and decision rights after evidence

If the trial is productive, resist the urge to treat enthusiasm as a substitute for structure. This is the point to discuss the climate tech co-founder equity arrangement, intellectual property, responsibilities, and decision rights while the evidence is still fresh.

Equity should reflect the actual relationship you are entering, not simply reward the person for completing a short project. The relevant questions include:

• Is this person joining as a true co-founder or continuing as an employee, advisor, or contractor?
• What level of time commitment will they make?
• Which responsibilities will they own over the next stage?
• What has each founder already contributed?
• What risks will each person carry from this point forward?
• How will equity vest, and what happens if someone leaves?
• How will future financing and hiring affect the ownership structure?

There is no universal equity formula that works equally well for a software validation stage, a hardware prototyping stage, and a regulated product moving toward field deployment. The trial gives you better information, but it does not eliminate the need for thoughtful negotiation and professional advice.

Intellectual property deserves the same care. Before the trial, document what each person brings into the project: prior code, designs, research, inventions, datasets, methods, and third-party materials. Then define how new work created during the trial may be used and what happens if you do not proceed together.

Do not rely on informal statements such as “we will sort it out later.” Later is often when the work has become more valuable and the relationship has become more complicated. A written agreement should match the legal realities of your jurisdiction and company status. The key is clarity, not unnecessary intimidation.

Decision rights are equally important. Founders often discuss equity in detail and leave decision-making vague. That creates a quiet source of conflict. Define:

• which founder owns day-to-day decisions in each area;
• which decisions require both founders;
• how technical safety or regulatory concerns can pause a launch;
• how the team will resolve a disagreement;
• what happens when a decision must be made before both founders have complete information;
• how strategic changes will be documented and revisited.

A practical agreement can be simple in language while still being precise. We should be able to answer, without reading between the lines, who decides what, how disagreement is handled, and what each person has committed to doing.

Make the post-trial decision explicit

At the end of the 30 days, schedule a dedicated conversation rather than allowing the relationship to drift into an undefined partnership.

Review the project together:

• What did we set out to learn?
• What evidence did we gather?
• Which assumptions changed?
• Where did our working styles complement each other?
• Where did friction appear?
• Did we address friction directly?
• What would each of us need to feel aligned for the next stage?
• Are we choosing to continue as co-founders, continue in another form, or stop here?

A respectful “not yet” or “not together” is a useful outcome. It protects the work, the relationship, and the climate mission from a premature commitment.

The next step is smaller than the decision

A ClimateTech co-founder trial project is not a ceremony before the real company begins. It is one of the first pieces of company-building. By defining the technical archetype, setting a 30-day scope, sharing at least 120 hours of meaningful work, and formalizing the relationship only after evidence, you create room for alignment before the stakes become harder to move.

Start with one page. Write down the current technical bottleneck, the deliverable that would reduce uncertainty, the time each person can contribute, and the decisions that must be clarified before work begins. Then invite the candidate to challenge the plan.

That conversation will tell you more than another round of impressive biographies. It is the first small test of whether you can build the larger thing together.