What an Ended Partnership Taught Me About Owning Your Work

I want to be careful with this one, because it is the easiest of these posts to get wrong. This is a lesson about how to structure work. It is not a story about a person, and I am going to keep it that way.

For a stretch, I was a partner in a venture, a fifty-fifty split with a collaborator, in the fantasy sports space. It produced real work and a few real sites. And in early 2026, it wound down.

Here is the part that actually matters, and the reason this is a lesson worth writing down: it ended well, because it ended on paper. There was an operating agreement. There was a formal amendment that assigned the domains and digital assets to the company explicitly. And there was a documented withdrawal, where I assigned my interest and stepped away, with my unrelated projects carved out and preserved in writing. Nobody had to guess who owned what, because all of it was written down before anyone needed the answer. That paperwork is the entire reason it was a clean separation and not a dispute.

Before that, ownership was something I genuinely never thought about. A domain was just a domain. A repository was just a repository. When you are building alone, that casualness costs you nothing, because the answer to “whose is this” is always “mine.” There is no question to get wrong.

The moment a partner and real money enter, every loose asset becomes a question. Whose domain is that. Whose repository. Whose API key. Whose deployment credentials. Whose user data. Whose brand name. If those questions do not have answers written down somewhere, you are not actually partners in a clean business. You are two people standing near a pile of valuable things with no agreement about which things are whose.

And it is not only a partnership problem. The same looseness shows up in solo work in quieter ways. Infrastructure spread across accounts you do not fully control. A project depending on someone else’s hosting login. A brand running on a domain registered to the wrong place. None of that is a crisis while everything is fine. All of it becomes one the moment something needs to move.

So here is what I do now, on every project, by default. Every project gets a clear ownership answer from day one. Separate legal entities where the situation calls for it. Separate repositories, separate brands, separate infrastructure, and no shared code between things that have no business being tied together. When I later started a new project in an adjacent space, I built it from scratch, new repository, new brand, new everything, specifically so there could never be a question about what came from where. That was not wasted effort. That was the lesson being applied.

I want to be clear that this is not paranoia, and it is not expecting people to behave badly. It is hygiene. Clear ownership is not a prediction that something will go wrong. It is making sure that if circumstances change, for any reason, good or bad, the answer is already on paper. The cost of doing it up front is an afternoon of being deliberate. The cost of not doing it is the worst kind of argument, the one where both people are partly right and nothing is documented.

The shortest version of the lesson is this. Build every piece of your work as though you might one day need to cleanly hand it to someone else, or cleanly keep it. You usually will not have to do either. But the day you do, you will be very glad the answer was written down long before you needed it.