Building a side project with a friend sounds like the best version of nights and weekends. You get someone to split the boring work with, someone who notices when you go quiet for two weeks, and someone to celebrate the first paying customer with. It can be exactly that. It can also turn into a slow, awkward mess where nobody says what they think, one person carries the work, and a friendship you had for ten years ends over a shared domain name.
The difference is rarely talent. It is whether the two of you talked about the uncomfortable stuff while you still liked each other and nothing was at stake. This guide is the practical version of that conversation: how to pick the right partner, what to write on one page before you build, how to make decisions and run a weekly rhythm when you both have day jobs, how to handle uneven effort, how to set up shared accounts, and how to part ways cleanly if it comes to that.
One note before we start. Some of this touches ownership, contracts and company structure. I am not a lawyer and this is not legal advice. Use it to get your thinking straight, then spend an hour with a lawyer in your country before real money or real equity is involved.
Should you build a side project with a friend at all?
Yes, if you would still want to work with this person after a bad month, and you can name what each of you brings that the other does not. A friend is a great partner when the friendship survives honest feedback. A friend is a risky partner when the friendship depends on never disagreeing.
Ask yourself three plain questions before you say yes:
Have we ever worked on something hard together? A group project, a move, a wedding, a hackathon. You learn more from one stressful weekend than from years of dinners.
Do our skills overlap or complement? Two backend developers will both want to refactor and neither will want to talk to users. One builder plus one person who likes selling, writing or design usually works better.
Do we want the same outcome? One of you may want a fun hobby that pays for itself. The other may secretly want to quit their job in a year. Both are fine goals. Mixing them without saying so is where the resentment starts.
How do you pick the right partner for a side project?
Pick for reliability and honesty first, skills second, and friendship third. That order feels cold, but it protects the friendship. A brilliant friend who disappears for a month without a word will hurt the project and the relationship more than an average friend who always shows up when they said they would.
Before you commit, run a small trial. Pick a tiny piece of the project you can finish in two weeks, like a landing page with a signup form or a rough prototype of the core feature. Agree on who does what and when you'll check in. Then watch for a few things:
Did they do what they said, roughly when they said?
When something slipped, did they tell you early or did you have to ask?
When you disagreed, did you talk it through or did someone go quiet?
Did you both enjoy it, or did it already feel like a chore?
What should go in a one-page partnership agreement?
A one-page agreement should cover roles, time, ownership, money, and what happens if someone leaves. It does not need to be a legal contract on day one. It needs to be written down, dated, and agreed by both of you, so that six months from now nobody has to rely on memory.
Open a shared doc and write short answers under these headings.
Roles
Write who owns what. Not who helps with what, who owns it. "Sam owns the product and code. Priya owns users, marketing and support." Owning means that person makes the final call in that area after listening to the other. Shared ownership of everything sounds fair and usually means nothing gets decided.
Hours per week
Write a realistic number for each of you, and write what happens in busy weeks. "We each aim for 6 to 8 hours a week. If one of us has a crunch at work, we say so in the weekly update and skip without guilt." Agreeing on the number early is what lets you talk about uneven effort later without it feeling personal.
Ownership and equity split
Write how you'll split ownership and why. An even split is common between friends and is fine when the commitment really is even. If one of you came up with the idea, already built a working version, or will put in twice the hours, say so and adjust. Have that talk now, before there is revenue.
Then add vesting, even informally. Vesting means each person earns their share over time instead of getting it all on day one. The usual startup pattern is a four-year schedule with a one-year cliff, which Carta's guide to vesting schedules and cliffs describes as the standard for venture-backed companies. A cliff means nobody earns anything until the first year is done, then a chunk vests at once and the rest vests month by month.
Four years is long for a side project. Plenty of friends pick something shorter, like two years with a six-month cliff. The exact numbers matter less than the idea behind them: if one of you walks away in month three, they shouldn't keep half of something the other person spent the next two years building.
Who owns the code, designs and name
Write that everything either of you creates for the project belongs to the project, not to the person who made it. This is often called IP assignment. Without it, the person who wrote the code or drew the logo can, in theory, take it with them.
Also check your day jobs. Many employment contracts claim ownership of things you build, sometimes even in your own time. Each of you should read your own contract before you start, not after you launch. We covered how to read those clauses in starting to charge for a side project while you have a day job.
Money and costs
Write how you'll split costs and revenue. "We split hosting and tools 50/50 through a shared account. Revenue stays in the project until it covers costs for six months, then we split profit by ownership." Also write a spending limit: "Anything over a set amount a month needs both of us to agree."
What happens if someone leaves
Write the exit plan now, while it is hypothetical. Who keeps the project? What does the leaving person get? Do they keep their vested share, sell it back, or give it up? Who keeps the domain and the user list? The section on parting ways below has a simple default you can copy.
When the page is done, both of you read it out loud, change anything that feels off, and date it. If the project starts making real money or you form a company, take this page to a lawyer and turn it into proper documents. A clear one-pager makes that meeting faster and cheaper.
Do you need a company for a side project with two people?
Not on day one, but probably before real money comes in. In many countries, two people running a business together without forming a company can be treated as an informal partnership, and that can make each of you personally responsible for the project's debts and problems. A company like an LLC can separate the project from your personal finances.
The US Small Business Administration has a clear overview of the options in its guide to choosing a business structure, including how partnerships and LLCs differ on liability and taxes. Rules vary a lot by country, so treat it as a primer and check your local equivalent.
A sensible trigger: form the company when you take your first payment or sign anything with a customer. Until then, the one-pager plus shared accounts is enough.
How should two friends make decisions without fighting?
Use simple rules agreed in advance, so that each disagreement is about the decision and not about who gets to decide. Most fights between partners aren't about the feature. They're about one person feeling overruled.
Here are four rules that work well for two people:
Owner decides in their area. If it is code, the code owner decides. If it is pricing copy, the marketing owner decides. The other person gets to make their case once, clearly, and then lets it go.
Big decisions need both. Write a short list of what counts as big: pricing changes, spending over your limit, adding a third person, pivoting, shutting down, anything involving ownership. Those need two yeses.
Disagree and test. When you can't agree on something small, pick the option that is cheapest to undo, try it for two weeks, and look at what happened. Data ends a lot of arguments that opinions can't.
When you're deciding what to build next, it helps to use the same scoring method every time so it feels fair. The scoring approach in picking what ships in early access versus what waits gives you both a shared way to rank features instead of trading favors.
What weekly cadence works for two people with day jobs?
A short written update early in the week and one 30-minute call at the end of it is enough for most pairs. You don't need daily standups. You need to always know what the other person is doing and whether they're stuck.
A rhythm that holds up well:
Monday: written update, five minutes each. Post in your shared chat or doc: what I did last week, what I plan this week, how many hours I realistically have, and anything I'm blocked on. Keep it short. Three lines is fine.
During the week: async only. Leave comments, questions and screenshots in one place. Agree that nobody expects a reply within the same day. You both have jobs.
Weekend: one 30-minute call. Look at what shipped, look at any numbers you track, make the one or two decisions that need both of you, and pick next week's focus. End on time.
Once a month: a 15-minute "how is this going for us" check. Not about the product. About the partnership. Is the split still feeling fair? Is anyone burning out? Does anyone want to change roles?
When user feedback starts coming in, decide who reads it and how it turns into work. A light routine like turning support tickets into product priorities keeps the two of you from each building whatever the last user said.
How do you handle uneven effort between partners?
Name it early, using the hours you both agreed to, and treat it as a planning problem before it becomes a fairness problem. Uneven effort is normal. Someone gets promoted, has a baby, moves cities, or just loses steam for a while. The damage comes from pretending it isn't happening.
A good way to raise it:
Use facts, not feelings. "We agreed on about 6 hours each. The last month I've been doing around 10 and you've been doing about 2." Not "you don't care about this."
Ask what changed. There is usually a reason, and it is usually not laziness. Listen to it fully before suggesting anything.
Pick one of three paths. Shrink the plan so both of you can keep up. Pause the project for a set time. Or change the split to reflect the new reality, using the vesting idea from your one-pager.
Write down what you agreed and add it to the doc with a date.
If it's you who has fallen behind, say so first. "I've been at about 2 hours a week and I don't see that changing before spring" is one of the kindest messages you can send a partner. It lets them plan instead of guess.
How should you set up shared accounts so nobody holds the keys?
Make sure every important account is owned by the project, or has both of you as full admins, from the first day. The most common breakup mess is not about money. It is one person having the only login to the domain, the code, or the payment account.
A simple setup:
A shared project email address. Create one inbox for the project and sign up for every service with it. Both of you have access. Personal emails never own project accounts.
Code in an organization, not a personal account. Most code hosts let you create a free organization. Put the repository there and make both of you owners.
Domain in the project account. Register the domain with the shared email, turn on auto-renew, and make sure both of you can log in.
Payments in the company's name once you have one, with both of you able to see the dashboard. Before that, agree in writing whose name it is in and how money moves out.
A shared password manager vault. Every project login lives there, including recovery codes for two-factor authentication. Nobody keeps a project password only in their head or their personal manager.
A one-page account list. Service, what it's for, who pays, who has admin. Update it whenever you sign up for something new.
When should you part ways, and how do you do it well?
Part ways when one of you no longer wants to do the work and a pause won't fix it, or when you keep disagreeing about where the project should go and neither of you is willing to change. Ending a partnership is not a failure. Ending it badly is.
Signs it's time to have the talk:
The monthly check has felt tense three months in a row.
One person has done almost nothing for two months and doesn't plan to change.
You want different things from the project and keep circling the same argument.
When it's time, follow your one-pager. If you wrote an exit plan, the hard decisions are already made, and the conversation is about doing what you both agreed to when you were calm. A simple default many pairs use:
The person who wants to keep going keeps the project. If both want to keep it, talk it through. If neither does, you can shut it down together.
The leaving person keeps what they had earned by that date, based on your vesting terms, or the person staying buys it back at a price you agree on. Unearned shares go back to the project.
Costs are settled to the end of the month. Anyone who prepaid gets their share back.
Accounts are cleaned up within a week. The leaving person's admin access is removed after the shared logins are confirmed working for the person staying.
Write a short, signed note saying what you agreed and that the leaving person has no further claim, then have a lawyer look at it if real money or a company is involved.
What does this look like in practice? (Illustrative example)
This is an illustrative example, not a real project. Sam is a developer at a bank. Priya runs marketing at a small agency. They've been friends since university and want to build a tool that helps small yoga studios send class reminders by text.
Before writing any code, they spend one evening on the one-pager. Sam owns product and code. Priya owns users, marketing and support. They each commit to about 6 hours a week. They split ownership 50/50 with a two-year vesting schedule and a six-month cliff. Everything they make belongs to the project. They check their job contracts that week. Sam's has a clause about side work, so he asks his manager in writing and gets a yes. Costs are split evenly through a shared card, with a rule that anything above a small monthly amount needs both of them. If someone leaves, the person staying keeps the project and the leaver keeps their vested share.
That same night they create a shared project inbox, a code organization with both as owners, and a shared password vault. They register the domain with the project inbox and turn on auto-renew.
Their rhythm is a Monday update in a shared chat channel and a Sunday call at 11 a.m. In month four, Priya's agency loses two staff and her hours drop to about 2 a week. She says so in her Monday update before Sam notices. They agree to pause new features for six weeks and focus only on keeping their first eight studios happy. In week seven, Priya is back to normal and the project picks up again. No fight, because they planned for this in month zero.
FAQ
Is a 50/50 split a bad idea for friends?
No. A 50/50 split is fine when both of you really are putting in similar time, skill and risk. It becomes a problem when it's chosen to avoid an awkward talk. Pair it with vesting and a clear tie-break rule for decisions, such as "the area owner decides," so an even split doesn't mean endless deadlock.
How do we handle it if one of us wants to quit their job and go full time?
Treat it as a big decision that needs both of you, and revisit the one-pager. Going full time often justifies a change in roles, pay or ownership. Agree on what changes before the resignation letter, not after.
What is the single most important thing to do first?
Write the one-page agreement and set up shared accounts in the same evening. Those two things prevent most of the painful breakups between friends who build together.
If you and your friend ship something together, you can launch it on SideHunt and get it in front of other people who build on nights and weekends. Start with the one-pager, though. The product can wait a week. The friendship is the part you can't rebuild.