When Co-Founders Fall Out: A Solo Dev’s Breakup Playbook

When Co-Founders Fall Out: A Solo Dev’s Breakup Playbook

Two years ago, a friend and I co-founded a language learning app. He handled product and marketing; I wrote code. We rarely met in person but worked well remotely. The app hit a few thousand MAU—not profitable, but sustainable.

Then it fell apart.

The reason was cliché: we disagreed on direction. He wanted to add an AI conversation feature to boost conversion rates; I insisted on fixing existing retention problems first. After several tense remote calls, disagreement turned into silent war. Each of us started pushing changes to the repo without telling the other. Then one day he typed “I’m out”, quit the group, shut down the servers, and revoked my access to the App Store developer account.

The next few weeks I spent restoring services and thinking: if we had a clear breakup playbook, could we have parted with dignity? This article is what I learned—a practical framework for dissolving a technical partnership.

Layer 1: Settle – Turn “Ours” into “Yours” and “Mine”

When things break, don’t assign blame first. Settle the accounts. Feelings are already bruised; the books must be clean.

1.1 Static Asset Inventory

List every shared asset by type:

Example: I wrote all the code myself, but the app relied on the co-founder’s Firebase account. He demanded I migrate everything off his Firestore instance. It took two weeks, and the app was down during the transition.

1.2 Dynamic Value Assessment

Tangibles are easy; intangibles (user base, brand equity, future revenue) are not. My rule: only count sunk costs + reasonable profit, never future value.

• Sunk costs: server fees, design outsourcing, App Store fees, API costs.
• Reasonable profit: if revenue existed, split by contribution ratio. If not, compensate by time invested.

Both parties can accept this. If someone insists on “future value,” you’ll need a third-party valuation—expensive and slow.

Layer 2: Cut – Make Each Side Operable Alone

Asset splitting is step one. The real task is making sure both sides can continue independently.

2.1 Code & Infrastructure Separation

Golden rule: You can take your code, but you must not break mine.

• Fork shared repositories so each keeps full history.
• Unbind from services owned solely by the other (databases, CDNs, payment gateways).
• Replace shared API keys with your own.
• Domains: negotiate ownership. Loser registers a similar domain (if brand matters).

// Example: Migrate from Firebase project to your own
// 1. Create new project in Firebase Console
// 2. Export old Firestore data via gcloud CLI
// gcloud firestore export gs://my-bucket/backup
// 3. Import data into new project
// gcloud firestore import gs://my-bucket/backup
// 4. Update client configuration
const firebaseConfig = {
  apiKey: "YOUR_NEW_API_KEY",
  authDomain: "your-new-project.firebaseapp.com",
  projectId: "your-new-project"
};

2.2 User & Brand Separation

• Send a clear, neutral email to core users (if both agree).
• In-app notice about ownership change and data migration.
• Social media & website: coordinated statements or silent removal of the other’s info.

The hardest part here is emotional. Don’t air dirty laundry. Users don’t care who was right; they just want the app to work.

Layer 3: Rebuild – Replace the Shared Desk with a Wall

After the split, the worst thing you can do is dwell on “what if.” Launch a new product line or feature immediately. Shift focus to creation.

• Redesign the architecture to avoid future locked-in dependencies. For example, I moved critical services from third-party managed to my own small VPS to reduce single points of failure.
• Document a “Co-Founder Breakup Checklist” and use it for every future partnership.

Here’s the checklist I now run before and during any collaboration:

Co-Founder Breakup Checklist (Actionable)

Before starting (prevention)

• Sign a written agreement covering equity split, responsibilities, and exit terms.
• Agree on a dispute resolution mechanism: who mediates? Who makes the final call if technical vs business divergence?
• Document asset ownership: code, domains, accounts, data.
• Include “breakup clause”: fixed formula for buyback (e.g., based on sunk cost or 3× last 6 months net profit).

When things break (crisis response)

• Freeze shared accounts and API keys immediately to prevent unilateral damage.
• Run static asset inventory and dynamic valuation.
• Agree on a 3-day cooling-off period; exchange written proposals only.
• Appoint a trusted third party as mediator (not a lawyer—too expensive; a respected peer who knows both sides).

After separation (rebuilding)

• Restore core services within 24 hours (at least for existing users).
• User notification: honest, brief, no blame.
• Fully decouple technically—ensure the other side can no longer access your systems.
• Mental reset: take a week off, then start a tiny new project immediately.

Honest Reflections (Not Perfect, But True)

1. Don’t partner with someone who has fundamentally different values. Skills can complement; beliefs on “profit vs product” must align. Our disagreement looked like a feature prioritization fight, but it was really about our tolerance for business models.

2. Paperwork beats brotherhood. Spend a few hundred on a lawyer to draft a shareholder agreement and exit terms. It’s cheaper than thousands in litigation later.

3. Breaking up is a required course in entrepreneurship. Next time, I’ll open with “how we break up” in my first email. It’s not cold; it respects both parties’ time.

4. Don’t mix personal and professional. We used to have dinners together. Now we don’t even like each other’s posts. It’s sad, but maybe that’s normal.

If this article helps one team avoid a messy breakup—or helps you recover from one—then it was worth writing.

PaxLee