Hoag Law.ai

Tag: intellectual property

  • How to convert your Apple Developer Account from an Individual Account to a Business Account

    How to convert your Apple Developer Account from an Individual Account to a Business Account

    This is educational material and does not constitute legal advice nor is any attorney/client relationship created with this article, hence you should contact and engage an attorney if you have any legal questions.

    You just vibe coded your first (or several) iOS apps and finally set up your LLC (and remembered to assign your IP from yourself to your new LLC).

    Unfortunately, all your apps still list your full name as the “Developer” instead of YourCompany, LLC.

    The Apple Developer Program has two flavors

    The Apple Developer Program comes in two account types. Individual accounts are for people building apps as themselves — your legal name appears as the developer on every app you publish. Organization accounts are for businesses, with the company name appearing as the developer.

    If you started solo (as most indie devs do), you have an Individual account. Which means every app you’ve ever shipped is publicly attributed to you, the human, regardless of what entity legally owns it.

    This is a mismatch problem. Legally, your LLC owns the app’s IP (if you properly assigned the IP), the contracts with users, and the revenue stream. But Apple’s public-facing listing says you, personally, are the publisher.

    Why this mismatch matters

    For most indie devs, this isn’t catastrophic. Your apps still work. Customers still pay. The world keeps spinning. But the mismatch creates real friction in three places:

    Customer trust. A user looking at your app and seeing your personal name as the developer might wonder why the privacy policy and TOS reference a different entity. It’s a small inconsistency, but inconsistencies erode trust.

    Tax and accounting. Apple issues 1099s and processes payouts based on the developer account. If your account is in your personal name but your business is in your LLC’s name, your bookkeeping has to constantly reconcile the two. Easier to just have everything flow through the LLC.

    Due diligence and acquisitions. If you ever sell the app, an acquirer’s lawyer will notice immediately that the App Store listing doesn’t match the entity that owns the IP. Now you’re explaining a paper trail and producing migration documents at the worst possible moment.

    Brand consistency. “Made by Acme, LLC” looks more legitimate than “Made by John Q. Founder” — especially as your business grows.

    The fix: migrate from individual to organization

    Apple actually has a dedicated process for this. It’s called migrating from an individual to an organization membership, and it preserves everything that matters: your apps stay live, your reviews stay attached, your ratings carry over, your in-app purchases keep working. The only thing that changes is the developer name on every listing.

    What you’ll need:

    A D-U-N-S number for your business. D-U-N-S is a unique identifier issued by Dun & Bradstreet that Apple uses to verify organizations. If your LLC doesn’t already have one, you can request it for free through Apple’s lookup tool at developer.apple.com/enroll/duns-lookup. Apple has a partnership with D&B that gets new D-U-N-S numbers issued in 5 business days or less — even just minutes or hours — versus weeks if you go directly through D&B.

    A business website. Apple wants to verify your organization is real. A simple holding company landing page is enough — it doesn’t need to be elaborate. Just something at yourcompany.com that confirms your entity exists.

    A business email address. [email protected] works much better for verification than [email protected]. Cloudflare Email Routing handles this for free if you don’t want to pay for a separate Workspace seat. Or, just set up a domain alias in your Google Workspace account for free.

    Your EIN and basic business info. Legal entity name, principal address, phone number, contact details.

    The actual process

    Once you have those four things:

    1. Go to developer.apple.com → Account → Membership → Update your information
    2. Select “Switch to organization membership”
    3. Provide your D-U-N-S number, EIN, business address, and authorized contact
    4. Submit and wait

    Apple’s stated turnaround is one business day. In practice, it can take longer — especially if your D-U-N-S record is brand new and they want to verify it independently. Some submissions get lost in the queue and need a follow-up. Don’t panic if you don’t hear back immediately, but do follow up after 3-5 business days if there’s silence.

    What changes (and what doesn’t) after migration

    Changes:

    • Developer name on every App Store listing updates to your LLC
    • Your previous individual account becomes deprecated
    • New paid agreement and tax forms (W-9) need to be executed under the LLC
    • Banking information needs to be updated to your business account
    • All future payouts go to the LLC

    Does NOT change:

    • Your apps stay live throughout the migration
    • Reviews and ratings carry over
    • In-app purchases continue to work
    • Customers don’t need to do anything
    • Your Apple ID (the login) stays personal — you log in as you, typically via your iCloud account, but you manage the LLC’s account

    That last point trips people up. Your Apple ID is your personal authentication. The team/organization you manage with that login is the LLC. Same way you might log into a corporate bank account with your personal credentials but manage the company’s funds.

    A note on timing

    Don’t migrate the day you form the LLC. Wait until:

    • Your LLC is fully approved by your state
    • You have your EIN
    • You’ve signed the IP assignment transferring your apps to the LLC
    • You’ve set up business email, a basic company website, and your bank account (probably just use Mercury for speed, simplicity, and startup-friendliness)

    These prerequisites take maybe a week if you’re focused. Trying to migrate before they’re in place will get your application bounced.

    The bottom line

    If you’re an indie iOS developer who started as an Individual on the Apple Developer Program and later formed an LLC, your App Store listings are out of sync with reality. The fix is a free D-U-N-S number and a one-time migration that takes about an hour of your time and a week of waiting on Apple. Pair this with a properly executed IP assignment and your indie app business actually matches the legal structure you formed.

    Hoag Law.ai provides flat-rate fractional general counsel services for AI-native startups, SaaS companies, and founders. If you need help with entity formation, IP assignment, or developer account migrations, get in touch.

  • You formed an LLC for your vibe coded app. Now what?

    You formed an LLC for your vibe coded app. Now what?

    This is educational material and does not constitute legal advice nor is any attorney/client relationship created with this article, hence you should contact and engage an attorney if you have any legal questions.

    You’ve just vibe coded your first (or second, or third, …, or nth) app, and you did what every responsible founder does: you formed an LLC.

    Then you updated your website footer to say “© 2026 YourApp LLC,” perhaps even updated your TOS/Privacy policies accordingly, and even opened a business bank account; probably with Mercury.

    You breathe a sigh of relief. You feel protected. You’re confident that if your Stripe API key is hacked for your new SaaS, you’ll be just fine.

    And you’d be completely, catastrophically wrong.

    Your LLC is an empty safe

    The thing that nobody seems to tell you is that forming an LLC does not transfer your intellectual property into it.

    Your app, your source code, your domains, your brand, your content, it all still belongs to you, the individual human who created it. Not your LLC. Your LLC is a legal entity that currently owns nothing. It’s a basically an empty safe with nothing inside it.

    Think of it like buying a house. You can create a trust to hold real estate, but until you actually deed the property to the trust, the trust owns nothing and the house is still in your personal name. The same principle applies to intellectual property and LLCs.

    Why this matters

    If you’re thinking “okay, but it’s my LLC, I’m the only member, what’s the difference?” The difference is the entire point of having an LLC in the first place.

    Liability protection only works for assets the LLC actually owns.

    If someone sues your LLC, only the LLC’s assets are at risk. Your personal assets are protected. That’s the whole point. But if your app’s IP isn’t in the LLC, then it’s not an LLC asset; it’s still just a personal asset. And that means it’s still exposed to personal liability. You created the LLC to build a wall between your personal life and your business, but then left your most valuable assets on the wrong side of the wall.

    Also, due diligence will catch this.

    If you ever raise funding, bring on a co-founder, or sell your company, the very first thing a lawyer will check is the chain of title to your IP. “Does the company actually own what it claims to own?” If the answer is “well, the founder formed an LLC and updated the copyright notice on the website,” that’s a failed diligence check. Deals die over this. Purchase prices get cratered over this.

    You can’t assert rights you don’t have.

    Even worse, if someone infringes your app’s IP, your LLC can’t enforce those rights because it doesn’t own them. You’d have to sue personally, which defeats the entire purpose of the entity structure in the first place.

    Fortunately, the fix is (relatively) simple

    What you need is an Intellectual Property Assignment Agreement, a document where you, the individual, formally assign (transfer) all right, title, and interest in your pre-existing IP to your LLC.

    By the way, now is a good time to learn about migrating your Apple Developer Account from an Individual Account to an Organization Account.

    This isn’t a 50-page contract. It’s a straightforward document that says, in essence: “I, [Your Name], hereby assign to [Your LLC] all intellectual property associated with [Your App], including source code, domains, trademarks, content, and associated accounts.”

    The key elements of this Agreement include things like:

    Present-tense operative language. 

    The document must say you “hereby assign” — not “agree to assign.” This distinction actually matters in court. “Hereby assign” creates an immediate transfer. “Agree to assign” creates only a promise to transfer later, which can fail if you never follow through. A federal circuit court has ruled on exactly this distinction.

    A specific list of what’s being assigned.

     Domains, repositories, app store listings, social media accounts, content, subscriber lists — everything. Use schedules and be thorough.

    Representations that you own what you’re assigning.

     You warrant that you’re the sole owner, that there are no liens or encumbrances, and that you’re not bound by any prior agreement (like an employer’s invention assignment clause) that would conflict.

    A catch-all provision.

     “And all other intellectual property related to the foregoing not specifically listed herein.” This sweeps in anything you forgot.

    Signatures. Twice. 

    Yes, you sign the document twice. Once as yourself (the assignor) and once as the sole member of your LLC (the assignee). It looks absurd. It is what it is.

    If you’ve worked at a startup, you’ve already done this

    If you’ve ever been employed at a startup — or any tech company, really — you almost certainly signed something called a PIIA (Proprietary Information and Inventions Agreement) or CIIAA (Confidential Information and Invention Assignment Agreement) on your first day.

    That PIIA contained, among other things, an IP assignment clause. It said that any inventions you create during your employment belong to the company. That clause is doing the exact same thing as the standalone IP assignment I’m describing here — transferring IP from an individual to an entity.

    The difference is that a PIIA bundles five things into one document: the IP assignment, a confidentiality agreement, a non-solicitation clause, a non-compete, and a return-of-property obligation. All of those extra sections exist because the PIIA governs a relationship between an employee and a company the employee doesn’t own. The company needs to protect itself from the employee.

    When you’re a solo founder assigning IP to your own LLC, you don’t need any of that. You can’t steal trade secrets from yourself. You can’t poach your own employees. You can’t compete with yourself. Strip away the employment protections and what’s left is the IP assignment, exactly the document you need.

    Same legal mechanism. The PIIA just has a bigger wrapper around it because it’s governing a more complex relationship. Your situation is simpler, so your document is simpler. But the core engine — “I hereby assign all right, title, and interest” — is identical.

    What you do NOT need

    You do not need to register in all 50 states because your app is available on the internet nationwide. This is a common panic. “Doing business in” a state has a specific legal meaning that does not include “has customers who access a website.” If you’re a solo operator in California selling software on the internet, you register in California. That’s it.

    You do not need a registered agent if you’re comfortable using your home address for your LLC filing. A registered agent is a privacy convenience, not a legal necessity (you can serve as your own).

    You do not need to file the IP assignment agreement with any government agency. It’s an internal corporate document. Sign it, date it, file it in a folder. It only needs to see the light of day if someone asks — and if they ask, you’ll be very glad you have it.

    What about IP you create AFTER forming the LLC?

    This is the question most people don’t think to ask: once your LLC exists, who owns the things you build going forward?

    The answer is: it depends on your operating agreement. If your operating agreement includes a clause stating that all IP created by members in connection with the company’s business belongs to the company, you’re covered prospectively. If it doesn’t — or if you don’t have an operating agreement at all (which is its own problem) — there’s still a gap.

    The IP assignment covers the past. The operating agreement covers the future. You need both.

    And the moment you bring on anyone — a contractor, an employee, a co-founder, even a freelance designer who makes you a logo — you’ll need a Proprietary Information and Inventions Agreement (PIIA) or Confidential Information and Invention Assignment Agreement (CIIAA) to ensure their work product belongs to the company. But that’s a topic for another post.

    The bottom line

    If you vibe coded an app, formed an LLC, and updated your website footer, you’re roughly one-third of the way to actually being protected. The LLC is the container. The IP assignment is what puts your stuff inside it. Without both, you have a business entity that owns nothing and personal assets that aren’t shielded.

    The good news: Hoag Law.ai can help you do this, so come say hi.

  • Why AI breaks traditional indemnification (and what founders need to know)

    Why AI breaks traditional indemnification (and what founders need to know)

    This is educational material and does not constitute legal advice nor is any attorney/client relationship created with this article, hence you should contact and engage an attorney if you have any legal questions.

    The entire legal architecture of indemnification was built for a world where you could control your product’s outputs. But AI breaks this assumption.When a traditional SaaS company indemnifies a customer against, say, patent infringement claims, that SaaS company can actually prevent infringement by controlling exactly what their software does. The code is deterministic. If version 2.3.1 doesn’t infringe, it won’t suddenly start infringing tomorrow.

    But an AI system? It might generate infringing content on Monday that it didn’t generate on Sunday, using the exact same model weights. You can’t “fix” this with a patch. The non-deterministic nature of generative AI means you’re being asked to indemnify against outcomes you cannot fully control or predict. This is a fundamentally different risk profile, and most MSAs haven’t caught up.

    The Three Pillars: Defend, Indemnify, Hold Harmless

    Before diving deeper into AI-specific issues, let’s clarify what these terms actually mean, because even sophisticated founders conflate them:

    Defend means you’re paying for the lawyers and managing the litigation. This is an active, immediate obligation. The moment a claim lands, you’re on the hook for legal fees, win or lose. This is often the most expensive component.

    Indemnify means you reimburse for losses and damages after the fact. This kicks in once a judgment is rendered or a settlement is reached. You’re covering the bill, but you weren’t necessarily driving the defense.

    Hold Harmless is the broadest obligation, and means you’re preventing the indemnified party from suffering any loss whatsoever. This can include things like reputational harm, business disruption, and other consequential damages that might not be covered under pure indemnification.

    The distinction matters because many contracts use these terms together (“shall defend, indemnify, and hold harmless…”) when the parties haven’t actually thought through what each entails. When something goes wrong, that ambiguity becomes very expensive very quickly.

    Why Symmetry Is Usually Right (But Not Always)

    In a typical SaaS MSA, indemnification should generally be mutual and symmetrical. You indemnify the customer for claims arising from your product; they indemnify you for claims arising from their data or misuse of your service. This makes intuitive sense because each party is best positioned to control and insure against their own risks.

    But here’s where it gets nuanced: certain asymmetries are not only acceptable but necessary.

    Carve-outs that make sense:

    • Material unlawful acts: You shouldn’t indemnify someone for their own illegal conduct. If your customer uploads stolen data to your AI tool and gets sued, that’s on them.
    • Gross negligence or willful misconduct: Standard carve-out. If one party acts recklessly or intentionally causes harm, they shouldn’t be shielded by the other party’s indemnification.
    • Modifications or combinations: If the customer modifies your software or combines it with something that creates the infringement, that’s outside your control and shouldn’t be your liability.
    • Continued use after notice: If you notify the customer of a potential infringement issue and they keep using the product anyway, the indemnification should cease.

    Asymmetries to watch for:

    Enterprise customers often hand startups contracts with wildly one-sided indemnification. Red flags include:

    • Indemnification obligations carved out of your liability cap (meaning your exposure is unlimited)
    • “Arising from” or “relating to” language that’s so broad it captures things you can’t control
    • No reciprocal indemnification from them for their data or misuse
    • Defense obligations triggered by mere allegations rather than actual claims

    The AI-Specific Problem: What Exactly Are You Warranting?

    This is where it gets genuinely difficult for companies leveraging generative AI services.

    Traditional IP indemnification works because the human is fully in the loop: You can warrant that your software doesn’t infringe third-party IP. You wrote the code. You know what’s in it. You can control it.

    With generative AI, the calculus changes because the human is, by definition, no longer in the loop end-to-end. Consider:

    Output IP risk: Your AI might generate text that infringes a third party’s copyright. Not because your model was trained on that text (though that’s a separate issue), but because the model probabilistically produced something substantially similar to protected work. You didn’t intend this. You couldn’t predict it. But under a broad indemnification clause, you might be on the hook.

    Hallucinated defamation: Your AI generates false statements about a real person or company. The customer’s end-user sees this output, relies on it, shares it. Someone sues for defamation. Who’s liable? The answer depends heavily on how your indemnification clause is drafted.

    Data privacy exposure: Your AI processes customer data in ways that arguably violate GDPR or other privacy laws—perhaps through unexpected data retention in model weights, or outputs that reveal PII from training data. The customer gets hit with a regulatory fine. Are you indemnifying that?

    The honest answer is that nobody knows how courts will ultimately allocate these risks (not to mention insurance providers). The case law is embryonic. Which means your MSA is doing heavy lifting that it probably wasn’t designed to bear.

    But here’s the uncomfortable part: none of these risks are actually unknown anymore, three years into this post-ChatGPT world.

    Output IP risk, hallucinations, data privacy leakage aren’t speculative edge cases. They’re thoroughly documented, widely discussed, and entirely foreseeable. Every AI company knows this. Every sophisticated customer knows this. The courts will certainly know this.

    Which changes the legal calculus considerably. You can’t later argue you didn’t appreciate the risk you were assuming. Foreseeability cuts against you. If you signed a broad indemnification clause covering AI outputs, you did so with eyes open. That’s assumption of risk, not surprise.

    What is genuinely unsettled is how courts will ultimately allocate liability, whether Section 230 protections apply to AI outputs, how copyright’s substantial similarity analysis works for probabilistic generation, whether GDPR fines can be contractually shifted. The minefield is clearly mapped. We just don’t know which mines are live.

    This is why precise contract drafting matters so much right now. You’re not protecting yourself against the unforeseeable. You’re negotiating the allocation of known risks before the case law catches up.

    Practical Implications for Founders

    If you’re an AI startup founder, here’s what this means for your contract negotiations:

    1. Read the indemnification clause. Actually read it. I know this sounds obvious, but most founders skim contracts looking for the price and payment terms. The indemnification section is often where the real risk lives. If you’re signing enterprise paper (their contract, not yours), this is where they’ve hidden the landmines.

    2. Push back on “arising from” or “relating to” language. These phrases are dangerously broad. “Arising from” can capture claims that have only a tangential connection to your product. “Relating to” is even worse. Negotiate for “directly resulting from” or “caused by” language that creates a tighter causal nexus.

    3. Insist on liability caps that apply to indemnification. Many enterprise contracts carve indemnification out of the overall liability cap. This means your maximum exposure isn’t 12 months of fees — it’s potentially unlimited. For an AI company facing unpredictable output liability, this is existential risk.

    4. Add AI-specific carve-outs. Consider language that limits your indemnification obligation for claims arising from: (a) outputs generated by the AI that you couldn’t reasonably prevent or predict, (b) customer’s failure to implement recommended guardrails or content filters, or (c) customer’s use of outputs without human review in contexts where review was warranted.

    5. Understand your insurance coverage. Most E&O and cyber policies weren’t written with AI output liability in mind. Before you sign a broad indemnification clause, confirm with your broker that you actually have coverage for the risks you’re assuming. You might be surprised.

    6. Consider warranty disclaimers carefully. Traditional SaaS companies warrant that their software will perform as documented. Can you warrant that about AI outputs? Probably not. Consider express disclaimers that AI outputs are probabilistic, may contain errors, and should be verified by humans before reliance.

    Don’t Indemnify Against the Unknown

    When you sign a broad indemnification clause for AI outputs, you’re agreeing to cover risks that neither party fully understands. The legal landscape is evolving. Courts haven’t weighed in on most of the novel issues AI presents. Regulatory frameworks like the EU AI Act are still being implemented.

    So you need to be clear-eyed about what you’re agreeing to, negotiate where you can, and price the risk appropriately where you can’t.

    The founders who get this right will be the ones who treat indemnification not as boilerplate to skim past, but as a core business risk that deserves the same attention as product-market fit or unit economics.

    For further questions on AI contract negotiation, MSAs, or indemnification structuring, feel free to reach out.