Reading an Acqui-Hire Before You Sign: People, IP, or the Company
A platform-backed exit can hand over people and a license while leaving the entity behind, so founders should price the deal around what the buyer can actually take.
Your term sheet says the buyer can make job offers to selected staff and take a non-exclusive IP license. It does not say it bought the company. The Huxe-Apple paperwork shows the difference in a form a founder can read before signing.
The Huxe filing is a people deal
Huxe started in December 2024 when Raiza Martin, a former Google NotebookLM project lead, joined designer Jason Spielman and engineer Stephen Hughes. It opened to invited users in June 2025, went public in September 2025, and announced $4.6 million in funding at the same time. It announced a shutdown in May 2026 and stopped serving users on May 28, 2026.
A June 9, 2026 EU disclosure gave Apple job-offer and hiring rights for selected Huxe AI staff and a non-exclusive license to its intellectual property. Apple told the European Commission that it acquired Huxe in June for an undisclosed amount, in an arrangement described as an acqui-hire. The EU filing characterized the June 9 Huxe-Apple deal as a staff-hire and IP-license arrangement, not an outright purchase of the company.
Four terms decide what you are selling
- Entity versus people. Decide whether the buyer purchases equity or the company, or only gets hiring rights. When it gives rights to offer jobs to selected staff and a license, price the team, not the company. The usual mistake is to price the company as if the entity is being bought, then discover the buyer only wants a few people.
- Exclusive versus non-exclusive IP. Answer who owns the code, who can use it, and who can stop others from using it. A non-exclusive license lets the platform use the work without giving it exclusive control. Without exclusivity, do not price it as if you sold the only copy.
- User data and service obligations. List what transfers, what is deleted, and who must keep the service running for how long. Keeping the product working for the platform is a service obligation, not just a license.
- Roadmap dependency. Name the platform features your product depends on and the date you would stop if those features changed. Heavy dependence makes the people terms the center of the deal.
Pricing the team, not the entity
Start with the team the buyer can actually take. When the document only gives hiring rights for selected staff, your valuation should be built from offers, bonuses, and retention terms, not from a multiple on revenue. A revenue multiple assumes the company keeps selling. A people deal pays for the team. A useful spreadsheet has one row per person: expected offer, probability of acceptance, signing bonus, and the date the person can start. Where the buyer cannot force employment, the probability column is the deal.
Keep the entity alive long enough to pay the team. A service that ends before offers are accepted can leave the team with no claim against the buyer. Put a deadline in the agreement for the buyer to make offers. The agreement should name a date, a list of eligible people, and a payment trigger if the buyer misses the window. The window is the deal's real clock.
In March, the FTC and Justice Department started examining possible updates to premerger reporting rules that would capture hiring-focused transactions and nonexclusive intellectual property licenses. The paperwork matters, not just the headline.
Roadmap risk changes the team value
Ask what the platform roadmap does to your product. When your app exists because a big platform exposes a model, an API, or a distribution channel, the exit may depend on that platform continuing to behave the same way. A short memo should list the platform features you rely on, the alternatives if they change, and the date you would stop building. An empty memo means you are pricing a dependency you have not named.
Price the roadmap risk into the team value. A platform that can change the rules makes your team's value higher when it can move and lower when it is tied to one platform. Keep a standalone path, even a small one. A data export, an architecture note that does not depend on one model, and a customer list that does not rely on the platform are the proof that the team can move.
