Your LLC Doesn't Own Your Code (Until You Do This)

The worst time to learn that your company doesn't own its own code is in the middle of a deal. A founder I talked to found out exactly then. He was three weeks from closing a small acquisition, the buyer's lawyer sent over a diligence checklist, and item one asked him to confirm the LLC owned all the intellectual property it used to make money. He'd formed the LLC two years earlier. He'd written most of the codebase the year before that. Nobody had ever moved the code from him to the company. On paper, he was selling something his company didn't own.

This is one of the most common gaps I see, and it stays invisible until it suddenly isn't. Forming an LLC does not automatically hand your existing code to the LLC. The company owns what gets formally transferred to it, and not one line more. If you wrote your software before the company existed, you still own it personally until you sign it over.

Why the code doesn't come along for free

An LLC is a separate legal person. When you form it, you create that person, but you don't empty your own pockets into it. The bank account starts at zero until you fund it. The company owns no property until property is assigned to it. Code is property, specifically copyright, and copyright belongs to whoever wrote it unless a document moves it somewhere else.

So the day your LLC is born, here's the real ownership picture. The software you built beforehand belongs to you, the individual. The domain you registered belongs to whatever name sits on the registrar account. The logo the freelancer designed belongs, and this one surprises people, to the freelancer. The LLC owns none of it yet. It's an empty shell with your company name on it.

Closing that gap is not hard. It just has to actually happen, on purpose, in writing.

The two buckets of IP you need to handle

Split your intellectual property into what came before the company and what comes after. They get solved differently.

Everything created before formation needs a one-time assignment. This is a document, usually called a contribution or IP assignment agreement, where you as an individual assign your existing work to the LLC. It names you as the assignor, the LLC as the assignee, describes what's being transferred (the codebase, the domains, the designs, the brand), and states that you are assigning it now, in the present tense. That last detail matters more than it looks. Language that says you "hereby assign" transfers ownership on signing. Language that says you "agree to assign" is only a promise to do it later, and courts have treated those two phrasings very differently. Use the present tense.

Everything created after formation should be covered by your operating agreement. A good operating agreement for a software company includes an IP assignment clause saying that work a member creates for the business belongs to the business, automatically, going forward. That way you aren't signing a fresh assignment every time you push code. I've written separately about why generic operating agreements miss this, because most of them do.

Get both buckets right and the ownership question has a clean answer. Miss the first one and you're the founder in the diligence meeting.

The contributors you forgot about

Here's where software founders get bitten in a way that restaurant owners never do. Your codebase probably has more than one author.

Think about everyone who has touched your product. The contractor you found on Upwork who built the billing integration. The designer who did your landing page. The friend who wrote your original auth flow in exchange for beer and a vague promise. Under US copyright law, an independent contractor owns what they create by default. Not you, and not your company, even though you paid them.

People assume that paying for work means owning it. For employees, that's roughly true, because work an employee does within their job is a "work made for hire" that belongs to the employer. For contractors, it is not true. Commissioned software almost never qualifies as work made for hire, because the law reserves that label for a short list of specific work types and software isn't on it. The only thing that reliably moves a contractor's code to your company is a signed assignment. If your contractor agreement didn't include one, that person still owns their contribution, and they can be very hard to track down two years later when a buyer's lawyer wants their signature.

So the assignment step isn't only about your own pre-formation code. It's about everyone who ever committed to your repo. Each of them needs to have assigned their work to the company, in writing, ideally back when you paid them and everyone still liked each other.

The specific things to actually move

Code is the headline, but a software company's IP is a longer list, and the pieces live in different places with different owners.

Your domains sit in a registrar account, and ownership follows the account and the registrant contact, so put them under the company. Your source code lives on GitHub or somewhere like it, and repo ownership follows whatever account or organization holds it. If your repos live under your personal GitHub handle, the company doesn't control them in any real sense, so move them into an organization the LLC owns. Your product name and logo are their own category of IP and may deserve a separate assignment and eventually a trademark registration. Your cloud accounts, API keys, and third-party logins are more about access than copyright, but a departing co-founder holding the only AWS root credentials is its own kind of ownership problem, so treat those as company assets too.

None of these move automatically when you file your formation paperwork. Each one is a small, deliberate step, and they're easy to knock out in an afternoon if you do them before the list grows.

When to bring in a lawyer

I'm a founder who has been through this, not your attorney, and the line for professional help is genuinely worth knowing. If your codebase has real value, if a raise or a sale is even plausible, or if more than one person has contributed to the product, a few hundred dollars for a lawyer to paper the assignments correctly is one of the better deals in early-stage business. The cost of getting it wrong isn't the legal fee. It's a deal that stalls or dies because ownership is a mess and the people who need to sign have scattered.

If you're a true solo founder who wrote every line yourself, the pre-formation assignment is simpler, and it's mostly about doing it at all rather than doing it perfectly. Sign the document, date it, and keep it with your company records next to your operating agreement and your EIN letter.

Where QuickBiz fits

Part of the reason I built formation the way I did is that this step gets skipped constantly. Every QuickBiz formation generates an IP Assignment Agreement as part of the process, so the pre-formation transfer from you to the company is handled at the start instead of discovered during diligence. The operating agreement is written for software businesses, with the going-forward IP assignment clause built in, so work you create for the company after formation belongs to the company without a new signature every time.

What formation can't do for you is chase down the contractor who built your billing flow in 2024. That part is on you, and the time to handle it is now, while everyone still remembers each other fondly. If you're forming a company and you want the ownership chain solid from the first day, that's the entire point of it. The code you've already written is worth protecting properly, and protecting it mostly means making sure your company actually owns it.