Ownership gaps that stop a software deal

A buyer of a software company is not buying a product demo. It is buying the right to run, change and sell that product on the day after closing. That right rests on a list of things the company must control and be able to hand over: repositories, cloud accounts, domains, app store listings, licenses, and the paper that says the people who wrote the code gave their work to the company.

Most sellers believe they have all of it. Often they do, in practice. The trouble is that a deal does not run on practice. It runs on evidence. A repository the founder opened on a personal account years ago works fine every day. In a purchase agreement it is an asset the company does not hold.

This article is for sellers getting ready, and for buyers and their counsel reading a target. It covers which ownership gaps stop or delay a deal, which become conditions before closing, how a reviewer checks control, and what has to move between signing and closing.

What the buyer is actually paying for

Ownership in a software deal has two parts. Control means the company, not a person or a vendor, holds the account, the right or the contract today. Transferability means that control can pass to the buyer, either by buying the company itself or by assigning each asset to a new entity. A gap in either part is a gap in what the price assumes.

The deal structure changes the work, not the question. In a stock purchase the legal entity stays the same, so anything already held by the company carries over, and anything held by a founder, an employee or an agency does not. In an asset purchase every asset and contract has to be assigned one by one, and contracts that forbid assignment without consent need that consent. Counsel decides what the documents require. The technical review supplies the facts counsel works from.

The everyday version of this problem is familiar to anyone who runs a website or an app. Our engineering partner PERETZ covers it from the operator's side in Most Companies Don't Own Their Website. They Own a Collection of Dependencies.: how a business ends up depending on accounts, licenses and people it never formally controlled. In a deal the same dependencies stop being an operational risk and become items in a disclosure schedule.

In our method this is the first of the six layers, Ownership & IP, and it comes first for a reason. Most problems in the other layers change the price. A problem here can change whether there is a deal.

Where control usually leaks

Ownership gaps are rarely the result of bad faith. They come from speed. A product starts as a side project, a contractor sets up the hosting, a developer registers the app store account with the card on hand. Years later the company is worth buying, and the scaffolding is still in the names of the people who put it up.

• Code repositories under a founder's or early developer's personal account, or in an agency's organization where the company is only a guest.
• Cloud root accounts opened by a contractor, paid with a personal card, or recoverable only through the email of someone who left.
• Domains and DNS registered to a former agency, an employee or the founder personally, sometimes with renewal running on a card nobody watches.
• App store developer accounts enrolled as an individual rather than as the company, so the listing, reviews and update path belong to a person.
• Third-party services such as payment processors, email delivery, analytics, maps or AI APIs signed up in personal names, with keys in production.
• Licenses for commercial components, fonts, themes or SDKs that are personal, seat-based or not transferable, or that end on a change of control.
• IP assignments missing for early contributors, contractors paid by invoice only, or agencies whose contract says nothing about who owns the work.
• Open-source obligations from copyleft components, such as GPL in software that is distributed or AGPL in a hosted service, that nobody has mapped.
• Shared assets with another business of the same owner: one cloud account, one repository, one codebase serving two companies.

Which gaps stop a deal, and which do not

Not every gap is a crisis. The question a buyer asks is simple: can this be fixed before closing, at a known cost, with the cooperation of people who are willing to cooperate? The answer sets the severity and, usually, the treatment in the deal.

Gaps that stop or reshape a deal

The hardest gap is title to the code itself. If someone who wrote a central part of the product never assigned their work and will not do so now, the company may not own what it is selling. Buyers rarely accept that risk at any price. Sometimes it can be settled with a late assignment, sometimes with a payment to the person, sometimes only by rewriting the affected part. Each path takes time that a deal timeline may not have.

Gaps that become closing conditions

Most account-level gaps fall here. A cloud account, repository or domain in the wrong name is a fact with a clear fix, provided the current holder cooperates. Buyers typically write the move into the conditions to closing and ask to see it done, not promised.

Gaps that move the price or the terms

Where a gap cannot be closed in time but its cost can be estimated, it tends to show up as a specific indemnity, an escrow or holdback, or a lower price. Representations and warranties insurance often excludes risks the buyer already knows about, so a known ownership gap usually has to be dealt with directly in the agreement. Those choices belong to the parties and their counsel; the review gives them the facts and a cost to fix.

Evidence, not statements

A seller's answer to an ownership question is almost always "yes, we own it." That answer is honest and nearly useless. A reviewer's job is to see the control directly, under the access protocol: read-only, named accounts created by the company, for the period of the review.

Two checks find more than any others. The first is comparing the commit history with the signed agreements. Every author in the repository history, including old email aliases and agency staff, should map to an employee or contractor with a signed assignment, or to an agency whose contract assigns the work. The gaps in that list are the questions for counsel.

The second is following the money and the recovery path. Whose card pays for the cloud, the domain and the app store? Whose email receives the password reset? An account the company uses but cannot recover without a former contractor is not under the company's control, whatever the login screen says.

Tool output counts as evidence, not as a finding. A license scanner lists components; a person reads how each one is used. A copyleft library linked into a distributed desktop app raises different questions than the same library running in a build script. We write the fact and the context, and counsel decides what it means.

Contractors, agencies and the early code

The most common paper gap sits in the first year of a product. Founders write code before the company exists. Friends help on weekends. A freelancer builds the first version against an invoice. An offshore agency brings in subcontractors the client never met.

Each of these needs a written answer. Code written before incorporation needs a founder assignment to the company. Contractor work needs an assignment, since paying for work does not by itself transfer copyright in most cases. Agency work needs a contract that assigns the deliverables and covers the agency's own subcontractors, and that does not keep reusable parts for the agency without a license to the client.

Two edge cases come up often enough to name. A founder or engineer who built part of the product while employed elsewhere may face a claim from that employer, depending on their old contract. And an agency may own a framework it reuses across clients, licensing it into the product instead of assigning it. Neither is fatal when known early. Both are much harder when found during exclusivity.

Signing to closing: the transfer checklist

Once the purchase agreement is signed, the work turns from proving control to moving it. Some steps take days, some take weeks, and some depend on third parties with their own procedures. A practical sequence:

1. Agree the asset list at signing: every repository, cloud account, domain, app listing, license and service the product needs, each with its current holder.
2. Obtain missing IP assignments and confirmatory assignments from founders, contractors and agencies. Counsel drafts them; the commit-to-agreement list shows who is needed.
3. Move repositories into a company organization and confirm the buyer's named owners can see them.
4. Move cloud root or top-level accounts to company emails and a company payment method; reset root credentials and MFA, and store recovery codes with the company.
5. Change domain registrants to the company and check renewal settings. Some registrars restrict transfers for a period after owner details change, so begin early.
6. Start app store transfers or entity conversions early. Each store has its own rules, and some app features can block a transfer.
7. Collect vendor consents for contracts that require them on assignment or change of control.
8. Move third-party services out of personal names, or open company accounts and switch keys, with a tested cutover.
9. Remove open-source license problems that the parties agreed to fix before closing, and record what remains.
10. At closing, rotate shared secrets and API keys, remove access for people leaving with the seller, and confirm the buyer holds admin rights everywhere.
11. Keep a signed record of what moved, when, and to whom. It closes the condition and starts the transition plan.

Payment processors deserve their own line in the plan. They usually require the new owner to pass their own verification, and payouts can pause during the change. A failed cutover there is felt by customers, not just by lawyers.

For sellers: close the gaps before anyone asks

Almost every gap above is cheaper to fix before a buyer arrives. Without a deadline, moving a repository is an afternoon and getting a former contractor to sign an assignment is a polite email. Inside exclusivity, the same tasks carry the buyer's attention, the clock and a former contractor who knows the deal now depends on one signature.

A seller who starts early can run the same checks a buyer would: the asset list, the commit-to-agreement match, the recovery path for every account, the license scan. What cannot be fixed in time can be disclosed plainly with a plan, which reads very differently from a gap the buyer finds on its own. That is the purpose of exit readiness six to eighteen months before a sale, and of vendor due diligence once a process is starting.

What to do next

If you are selling, build the asset list now and test it against evidence, not memory. If you are buying, ask for the evidence above early in exclusivity, and make the account moves conditions with a named owner and a date. In both cases, give counsel facts they can work from, not assurances.

Our technical due diligence reads ownership and the five other layers in full for a buyer. A red-flag memo answers the narrower question quickly: is there anything here that stops the deal? Every finding comes in the report with its evidence, severity and a cost to fix.

Questions