Cofounder trial project: a brief and decision log

01. Decide what you need to learn about working together.

A cofounder trial project is a limited collaboration used to learn how a prospective founding team works in practice. It should leave you with an observable piece of work and evidence about your working relationship. The project is useful only if both people understand the question it is meant to answer. Agreeing that an idea sounds exciting does not explain who will do the difficult parts.

Y Combinator recommends discussing important expectations and doing a trial project before committing. Its questionnaire also warns that written answers cannot replace time spent together. Use the conversation to identify an uncertainty you can observe: can we make a decision when customer evidence conflicts with our preferred design? Can we explain a delay early enough for the other person to adjust?

Our editorial view is that a narrow trial with a candid review is more useful than a polished demonstration that avoids every uncomfortable decision. This is a way to structure learning, not a validated test of founder compatibility. Do not manufacture conflict to see how someone reacts. Ordinary work provides enough opportunities to discuss priorities and revise a plan.

Sources: Y Combinator: 10 Questions to Discuss with a Potential Co-founder ↗

02. Choose work that requires both people to contribute.

Pick a task with a clear stopping point and a reason for both founders to participate. For example, you could prepare a paper prototype of a booking flow and review what it helps a potential user understand. One person might shape the interaction while the other prepares the questions. Both should take part in interpreting what they learn and deciding what to change.

A task that one person can complete alone while the other watches tells you little about collaboration. Equally, a whole product launch may bury the relationship question beneath too much unfinished work. Choose the smallest useful deliverable that includes a handoff, a shared decision and a review. Those are suggested design features of this exercise, not requirements for every startup.

Before starting, discuss any unresolved questions about use of existing work, access, expenses or ownership. This brief records operating expectations; it does not settle rights in code, designs or a business. If you cannot establish the arrangements needed for the proposed work, narrow the activity or pause it rather than letting the trial silently create commitments.

03. Write the trial brief before the first work session.

Complete the brief together and make the scope specific enough that either person could describe the same finish line. An availability statement should describe the time you can actually protect. It should not be an aspirational promise that requires the other person to guess what will happen when existing work or family responsibilities intervene.

The template below is our own planning aid. Replace the bracketed fields and discuss differences before treating it as a shared plan. Keep a copy that both people can read. When circumstances change, record the change and its effect on the deliverable instead of comparing the outcome with an agreement nobody could still meet.

TRIAL BRIEF

Learning question: Can we [specific collaborative uncertainty]?
Deliverable: We will produce [bounded output] for [audience].
Start and review: [dates both people accept].
Availability: [name and realistic work blocks] / [name and realistic work blocks].
Responsibilities: [person and outcome they will lead].
Shared decision: We will decide [specific trade-off] using [evidence].
Communication: Updates in [channel]; flag a changed commitment by [agreed method].
Boundaries: [materials, access and spending explicitly agreed].
Unresolved arrangements: [questions to resolve before starting].
Stopping point: Either person can request a pause; we will record the work and discuss the next step.
Review: Each person writes a reflection before we compare notes.

04. Record a few decisions while the work is fresh.

A decision log keeps the review anchored to events rather than the strongest impression at the end. Record the original expectation, what changed, how you discussed it and what happened next. You do not need a diary of every message. Choose moments that reveal a handoff, a trade-off or an adjustment to a commitment.

Separate observation from interpretation. “The prototype arrived after the agreed review time” describes an event. “You do not care about the project” guesses at motivation. Ask for the missing context before deciding what the event means. The same outcome can arise from an unrealistic plan, an unexpected constraint or an avoidable communication failure.

Include your own actions in the record. If you changed the scope without checking capacity, that belongs beside the missed date. If the other person challenged your proposal and their alternative made the task clearer, record that too. A log designed to prosecute the other founder will not help you assess a mutual working relationship.

DECISION LOG ENTRY

Situation: [specific event or decision].
Our prior agreement: [what both people understood].
What we observed: [facts, including our own actions].
Context still missing: [questions to ask].
Options considered: [real alternatives].
Decision and reason: [what we chose and why].
Effect: [what changed in scope, timing or responsibilities].
Review question: [what this taught us, or what remains untested].

05. Compare two responses to the same missed commitment.

Consider a fictional trial between Maya and Sam, who are exploring a scheduling tool for independent tutors. Their deliverable is a paper booking flow and a written account of what remains confusing. Maya prepares the flow; Sam organizes feedback. Both agree to review the flow before showing it to anyone. This is an invented teaching example, not a Solution member story or a report of customer results.

The flow is not ready for the agreed review. In one version, Maya explains the blocker before the session and proposes dropping an optional rescheduling screen. Sam points out that this changes what the feedback can establish. They agree to test the simpler booking path and explicitly leave rescheduling unresolved. Their log records a reduced deliverable and an early, workable adjustment.

In another version, the review passes without an update. Sam discovers the missing work while preparing the feedback session. Maya assumes the deadline was flexible; Sam assumed it was fixed. Instead of deciding immediately that the partnership is wrong, they compare their original brief. If the expectation was ambiguous, they can clarify it. If it was clear, they need to discuss why the change was not communicated.

The useful distinction is how the pair handles the gap between the plan and reality. Neither version proves they should become cofounders. The first gives evidence of a particular repair; the second exposes a question that remains open. Write down that question rather than hiding it behind an overall score.

06. Finish with a decision that names the remaining uncertainty.

Write reflections separately before the joint review. YC recommends independent answers for its cofounder discussion questionnaire; here, use that separation to preserve each person’s account of the work. Start with an event you can both locate in the log. Explain what helped or hindered you, ask how the other person experienced it and discuss what you would change.

Choose a next action you can explain: stop exploring the partnership, run a different bounded trial to answer a remaining question, or continue discussions about a longer collaboration. More work is useful when it tests something new. Repeating the same comfortable task can consume time without reducing the uncertainty that matters.

A short exercise cannot establish how you will handle years of pressure, personal change or responsibility for a team. Avoid treating a good review as proof of a permanent fit. Similarly, an honest decision to stop can be a useful outcome. It has answered a question before either person made a larger commitment.

• What commitment was clear, and how did we handle a change to it?
• Which decision improved after we challenged each other’s reasoning?
• Where did one person lack context, time or authority to do the work?
• What evidence would we need before taking the next step?

Sources: Y Combinator: 10 Questions to Discuss with a Potential Co-founder ↗

07. If you are still looking for someone to build with.

This guide assumes you already have a potential collaborator. If you are still searching, describe the problem you want to explore, what you can contribute and what kind of work you want to try together. YC’s cofounder-matching service is one dedicated route for meeting people; its own process separates a connection from the conversation that follows.

Solution is a social network for the startup ecosystem, including founders and cofounders. Exploring relevant people in the app may be useful at the meeting stage. It does not replace your own conversations, a shared working trial or the arrangements needed before committing to a company. The practical next step is to establish mutual interest in one bounded piece of work, wherever you first meet.

Sources: Y Combinator: Co-Founder Matching ↗ Solution: The Hub For Startups ↗