The Co-Founder Agreement Nobody Actually Reads Until It’s Too Late

Wealthness Business Development Series — Part Three

When the Contract Is Already Signed

Most articles about co-founder agreements are written by lawyers or accelerator coaches who have never had one blow up in their face. They talk about equity vesting schedules and dispute resolution clauses with the calm authority of people who have never sat across a table from someone who just told them they’ve taken a job elsewhere and by the way, good luck with the product.

I have sat at that table.

So this article is not written from theory. It is written from the specific, expensive experience of a founder who had agreements in place, watched them mean nothing in practice, and then spent a long time thinking about what would have actually changed the outcome.

Some of it would have. Some of it, honestly, would not have. And knowing the difference matters.

The Illusion of the Signed Document

There is a psychological comfort that comes with a signed agreement. It feels like you’ve done the responsible thing. You’ve been professional. You’ve protected yourself. You can move forward with confidence now.

That comfort is real. The protection it implies is much more fragile than it feels.

A contract between co-founders is, at its core, a record of intentions at a specific moment in time. It does not account for the moment six months later when one party decides their priorities have shifted. It does not prevent someone from taking a full-time job elsewhere and quietly reducing their commitment to nothing. It does not rebuild your runway or restore your audience’s trust after a missed launch. It just sits there, accurate and useless, while you try to figure out what to do next.

This is not an argument against having a contract. It is an argument for understanding what a contract actually is, so you stop relying on it for things it cannot provide.

How This Played Out at GAUK

When I joined the Ministry of Awesome startup cohort in New Zealand, the goal was straightforward: sharpen the investor pitch for Government Auctions UK, refine the approach, and get the platform over the finish line properly. It was during that programme that I met Josh Trebilco, co-founder and CTO of CodingNZ, a New Zealand coding education company.

On paper and in conversation, the credentials were there. His own running business. Technical depth. Genuine enthusiasm for what GAUK was doing. He assured me he had the bandwidth and residual income from CodingNZ to commit properly to a partnership.

We had a contract. We had agreed scope. We had a shared understanding of what the deliverable looked like and when it would arrive. The timeline was six months. In that time I delivered on my side: millions of views across social media, a warm audience, real momentum. I even ran a countdown to launch email sequence based on his projected timeline.

The platform never materialised.

Seven months in, Trebilco announced he had taken a position with Road Ninja, a Taupo-based transport technology startup that connects businesses with contract commercial drivers. He suggested he could still contribute one day a week. That did not happen in any meaningful way. Shortly after, he messaged to say he was stepping away from GAUK entirely.

The contract that documented all of our agreements? It did not bring him back. It did not rebuild the lost runway. It did not explain to my audience why the launch countdown had led nowhere.

What Most Co-Founder Agreements Leave Out

The standard co-founder agreement template you find online, or the one a startup-friendly lawyer draws up without much customisation, tends to cover the things that matter in a successful partnership. Equity splits. Roles and responsibilities. Intellectual property ownership. What happens if someone wants to sell their stake.

What it rarely covers with any real teeth is failure modes. The messy, undramatic, thoroughly ordinary way that co-founder relationships actually fall apart.

Not the dramatic falling out. Not the scandal or the fraud. Just… someone deciding they have somewhere better to be.

Here are the things I wish had been in every agreement I have ever signed with a technical partner, written plainly rather than in the language of legal documents.

Milestone Gates With Real Consequences

Agreed timelines mean almost nothing without agreed consequences for missing them. A timeline is a statement of intent. A milestone gate with a consequence attached is a structural mechanism.

What does that look like in practice? It looks like equity that does not transfer until working software is demonstrated. It looks like a defined process for what happens when a deadline passes without delivery, not a vague intention to “discuss it” but an actual written protocol. It looks like the right to bring in a third party to assess the state of the codebase at any milestone point, at the co-founder’s cost if they have missed the agreed deliverable.

None of this feels comfortable to put in writing when you are in the optimistic early days of a partnership. That discomfort is exactly why most people do not do it. And that discomfort is precisely what the other party is counting on, consciously or not.

IP Ownership and the Code You Cannot Touch

This one is critical and chronically underestimated by non-technical founders. When a developer writes code for your product, who owns it? If the answer is not written down with absolute clarity, the answer is probably not you.

In my situation, years of development work sat in repositories that I had no meaningful access to and no ability to evaluate. I could not look at the code and tell you whether it was good, whether it was complete, or whether it was structured in a way that another developer could pick up and continue. I was entirely dependent on the word of the person who wrote it.

That is an enormous amount of power to hand to someone with no structural safeguard around it.

A co-founder agreement needs to specify, in plain terms, that all code written in the course of the partnership is owned by the company, not the individual. It needs to require that code is committed regularly to a shared repository that the non-technical founder has access to, even if they cannot read it. It needs to establish that an independent technical review can be commissioned at any time, and that the technical co-founder is obligated to cooperate with that review fully.

And it needs to address what happens to that code if the partnership ends. Not in vague terms. In specific ones. Who has access. Who controls deployment. What the handover process looks like. How long the departing partner is obligated to support the transition.

The Moonlighting and Commitment Clause

Nothing in our agreement prevented my co-founder from taking outside employment. He had his own business already when we partnered, which I understood and accepted. What I did not have in writing was any clear standard for what “committed to GAUK” actually meant in measurable terms.

How many hours per week? Across which activities? What was the minimum viable contribution that kept the partnership alive, and what fell below that threshold?

A co-founder agreement should define commitment in terms that can actually be observed. Not “full-time equivalent” if you are not paying a salary. But something real. Hours logged. Deliverables produced. Communication standards. A defined notice period, not just for leaving the partnership but for a material reduction in commitment.

If a co-founder wants to take outside work, that is a conversation. But it should trigger a formal review of the partnership terms, not just continue silently until the outside work becomes the priority and the startup becomes the afterthought.

Clawback Provisions

This is the clause almost nobody puts in place early enough.

If equity vests over time, what happens to equity already vested if the co-founder leaves before the product is built? Standard vesting schedules protect against someone leaving in month two with a quarter of your company. They do not protect you as cleanly from someone leaving in month eight having delivered forty percent of what was agreed.

A performance-linked clawback provision says: if you leave before these specific milestones are reached, a portion of your equity reverts. Full stop. It is not punitive. It is proportionate. It reflects the reality that equity in a startup is not a wage for time spent. It is a share of something that only has value when the work is done.

Getting a developer to agree to this upfront is harder than getting them to agree to a standard vesting schedule. That difficulty is useful information. Someone who will not commit to performance accountability in the agreement is telling you something about how they view accountability in general.

What None of This Can Actually Fix

I want to be honest here, because this series is about real experience and not a checklist for false confidence.

Even with every clause described above in place, the fundamental problem of being a non-technical founder does not go away. You still cannot evaluate the work yourself. You still cannot replace a departed developer overnight. You still face the reality that legal mechanisms, even when they work, take time and money that early-stage founders rarely have in surplus.

When a technical co-founder walks away mid-build, the legal options available to you are almost entirely theoretical. Pursuing breach of contract through the courts costs money you do not have, largely because the situation they left you in is what drained those resources in the first place. Meanwhile they move on to their next opportunity without consequence. That asymmetry is real, it is common, and it needs to be part of every honest conversation about what co-founder agreements can and cannot do.

The contract provisions matter. They create friction that slows a departure down and sometimes stops it altogether. They establish grounds for meaningful recourse. They change the psychological dynamic at the table when things get difficult. All of that is real value.

But the deeper protection is not legal. It is structural. It is the decisions you make before you partner with anyone about how to build the product, where the code lives, what the milestone checkpoints are, and how you maintain enough visibility into the technical progress that you are never again in the position of simply taking someone’s word for it.

That is the lesson that cost the most to learn. And it is where this series is heading next.

Next in the series: The structural safeguards non-technical founders need before they write a single line of code with anyone.