How to Structure Equity and Ownership When You’re Building Software With a Co-Founder Who Can’t Code

Most co-founder breakdowns aren’t about personality. They’re about a deal that was never clearly made. A non-technical founder brings the idea, the customers, and the capital. A technical co-founder brings the build. Somewhere between the first Figma wireframe and the first paying customer, someone starts doing the mental arithmetic – and the numbers don’t add up the same way for both people. The result is either a difficult conversation that should have happened six months earlier, or a silent resentment that quietly poisons every product decision.

We see this regularly. A founder comes to us after a co-founder split, wanting to rebuild something that already exists in a codebase they can’t access, owned by a person who’s now hostile. Sometimes the software is held informally – no agreement, no IP assignment, just a GitHub repo in someone else’s name. That’s not a technical problem. That’s an expensive legal problem wearing a technical costume.

If you’re about to start a build with a co-founder – or you’re mid-build and haven’t sorted this yet – here’s how to think through it properly.

The Core Tension Nobody Talks About Honestly

A non-technical co-founder often brings more to the business than they get credit for in the equity conversation. They’ve usually done the customer discovery, built early relationships, and put in real money or time before a single line of code was written. The technical co-founder, meanwhile, is doing work that has a visible, tangible output – you can see the product. You can demo it. You can’t demo “I convinced three enterprise customers to stay on a waitlist for four months.”

The mistake is treating the equity split as a reflection of effort so far, rather than a bet on future contribution. Equity is a forward-looking instrument. It’s about who’s going to be essential to the business in two years, not who did more last month.

So the first question isn’t “what’s fair given what we’ve each done?” It’s “what does this business actually need to succeed, and who’s carrying which part of that?”

Vesting: The Only Protection That Actually Works

If you take nothing else from this, take this: a co-founder agreement without a vesting schedule is not a co-founder agreement. It’s a lottery ticket you’ve handed to someone who might leave in eight months.

Standard vesting in Australia follows a four-year schedule with a one-year cliff. That means:

• Nothing vests in the first twelve months – if someone leaves before the cliff, they walk away with zero equity
• At the one-year mark, 25% vests in one hit
• The remaining 75% vests monthly or quarterly over the following three years

This isn’t punitive. It’s honest. You’re both betting on each other. The vesting schedule just means neither of you is trapped holding equity for someone who stopped contributing two years ago.

One thing we’ve seen cause friction: technical co-founders who argue the software they’ve already built should vest immediately, because the IP exists. That’s a reasonable position, but it’s a negotiation, not a given. If you’re the non-technical founder in that conversation, the counter is straightforward – the software is worth almost nothing without someone maintaining, evolving, and selling it. The vesting schedule is about the ongoing commitment, not the artefact already built.

IP Assignment: The Step Most Founders Skip

Here’s a scenario we’ve cleaned up more than once. A technical co-founder writes code before the company is incorporated. The company eventually gets set up, shares are issued, a shareholders agreement is signed – but nobody formally assigns the IP from the individual to the company. The code sits in a personal GitHub account. The domain is registered under a personal email. The AWS account is in one person’s name.

Two years later, there’s a dispute. Or worse, there’s an acquisition conversation, and the buyer’s lawyers do their diligence and find a chain-of-title problem that kills the deal or cuts the valuation by 30%.

The fix is simple and cheap if you do it early: a properly drafted IP assignment agreement, signed at incorporation or co-founder agreement stage, that transfers all relevant IP created during the company’s formation period into the company’s ownership. Your startup lawyer can draft this for a few hundred dollars. Not doing it can cost you multiples of your entire early revenue.

Practically, this also means:

• The company’s GitHub organisation owns all repositories – not personal accounts
• Domain registrations, cloud accounts, and API keys are under company credentials
• Any third-party tools or licences are contracted to the company, not individuals

We build this into our own handover process when we ship – the client owns the infrastructure from day one. Co-founders should hold themselves to the same standard.

How to Actually Split the Equity

There’s no formula that works for every situation, but there are a few principles worth applying.

Equal splits – 50/50 – are common and often sensible when both co-founders are full-time, have comparable risk exposure, and expect to contribute equally over the life of the business. The problem with 50/50 isn’t the number. It’s the deadlock risk if you ever fundamentally disagree on direction. Make sure your shareholders agreement has a clear deadlock resolution mechanism, whether that’s a casting vote for the CEO, a buyout right, or a drag-along provision.

Unequal splits work when one co-founder has contributed material capital, owns pre-existing IP being brought into the venture, or is taking on significantly more personal financial risk. If one person is working full-time and the other is still employed elsewhere, that asymmetry should show up in the split – or at least in the vesting schedule.

What doesn’t work well is splitting equity based on the current value of each person’s skill set in the market. “Senior developers are expensive therefore I should have more equity” is a market-rate argument, not a co-founder argument. If you’re being compensated at market rate, that’s a salary. Equity is about ownership of upside that neither of you can currently price.

When the Technical Co-Founder Is Actually a Contractor

This is worth being honest about. Sometimes a person who calls themselves a technical co-founder is functionally a deferred-payment contractor. They’re building something to a spec, they’re not shaping the product vision, they’re not doing customer conversations, they’re not losing sleep over whether the business model works. They want equity instead of cash because the company can’t afford cash yet.

That’s a legitimate arrangement, but it should be structured differently – as an advisor agreement with a small equity allocation (typically 0.5-2% over two to four years with a cliff), not a co-founder split of 20-50%. The distinction matters enormously at Series A, when investors will look at your cap table and want to understand why someone who contributed three months of code in 2024 owns a third of the company.

Ask yourself: does this person have an opinion on who the customer is? Do they care whether we’re building the right thing, or just whether it works? Are they here if we pivot? If the answers are mostly no, you probably have a contractor with equity, not a co-founder. Neither is wrong, but the structure should match the reality. If you’re trying to work out whether your arrangement warrants a full build engagement or something smaller, talk to Amora about your build – we’ve helped founders work through this before committing to a structure they later regret.

The Documents You Actually Need Before You Write a Line of Code

Founders routinely over-invest in product and under-invest in legal foundations. Getting the paperwork right early costs between $2,000 and $6,000 AUD with a decent startup lawyer. Fixing it later – especially if there’s a dispute involved – can run $30,000 to $150,000 or more, before you even get to a resolution.

The minimum viable legal stack for a co-founded software startup:

1. Co-founder agreement – roles, decision-making authority, what happens if someone leaves, how disputes get resolved
2. Shareholders agreement – vesting schedules, drag-along and tag-along rights, pre-emptive rights on new shares, deadlock mechanism
3. IP assignment deed – transfers all pre-existing and formation-period IP into the company
4. Employee or contractor agreements – even if you’re both “founders”, your relationship to the company should be documented
5. Company constitution – if you’re using a replaceable rules default, understand what it says about director decisions and share transfers

None of this is exciting. None of it shows up in your product. But it’s the infrastructure the business runs on, and the same logic applies here as in software architecture: decisions you don’t make explicitly get made for you by default, and the defaults are rarely what you’d have chosen.

Sort the structure before you start the build. The cost of doing it right is trivial compared to the cost of doing it wrong – and you’ll both show up to the product with clearer heads when the ownership question is settled.