Before You Ship an App: The Boring Stuff Nobody Warns You About

I went into building an app with a very simple mental model: write the code, hit publish, done. The App Store was the finish line. Everything hard was going to be in the code.

That turned out to be backwards. The code was the part I understood. What I didn't understand was that before a single customer can hand you a dollar, you're standing up a small business, taking on real liability, and making privacy decisions that are a lot harder to unwind later than they are to get right up front. Privacy, as I've come to see it, is an architecture problem, not a checkbox you tick at the end, and that's exactly why the decisions you make now are the ones you'll be living with.

None of that is in the "build your first app" tutorials. So here's the stuff I wish someone had laid out for me before I started, framed as food for thought rather than a to-do list you follow blindly.

The mindset shift: an app is a business before it's a product

The single most useful reframe: you're not publishing an app, you're launching a business that happens to distribute software through an app store. The moment money or customer data is involved, you inherit the obligations of a business, whether or not you've set one up like one.

Once that clicked, the rest of the list stopped feeling like bureaucratic busywork and started looking like what it actually is: the foundation the product sits on. Skip it and you're not moving faster, you're just accruing risk you can't see yet.

The legal foundation (and the trap that catches everyone)

The first real fork in the road isn't code, it's how you enroll. Apple gives you two kinds of developer account, and the one you pick shapes everything after it:

• Individual account. This is you as a sole proprietor. Your own legal name shows up as the seller on the store, there's no D-U-N-S requirement, and enrollment is quick. It's the least paperwork by a mile.
• Organization account. This is a registered legal entity (an LLC, an S-Corp, whatever you've formed). Your business name shows as the seller, you get team roles, and Apple requires a D-U-N-S number to prove the entity actually exists.

The trade-off is basically speed versus separation:

That last row is why I went the organization route (and why the rest of this section assumes you did too). Going individual is faster and totally fine for a hobby app, but it publishes under your personal name and puts nothing between you and a customer who says your app cost them money. The organization route at least sets a legal entity in that gap, though (as the next section gets into) even that entity has limits on what it actually protects you from.

Most solo builders who go the organization route land on an LLC. It's the common starting point because it creates a separate legal entity between "the business" and "you personally." (Whether it's right for you, versus an S-Corp or just staying a sole proprietor, is exactly the kind of thing to ask a professional.)

The part that surprised me is how much everything downstream depends on one thing: your exact legal entity name. Lock it in early, because it has to match, character for character, in a bunch of places that don't talk to each other:

1. The LLC filing itself.
2. Your EIN (the federal tax ID). Once the LLC is approved, this is close to instant through the IRS site.
3. Your D-U-N-S number. This is the one nobody sees coming. It's a business identifier from Dun & Bradstreet, and Apple requires it to enroll as an organization. Here's the gotcha: getting one (or having Apple pull it from D&B) can take anywhere from a few business days to a couple of weeks. It's the longest-lead-time item on the whole list, and it blocks your developer enrollment. Check the lookup tool first, because your state business filing may have already triggered a D&B record without you knowing.

That name-matching requirement isn't a formality. A mismatch between your legal entity name and your D-U-N-S record is one of the most common reasons organization enrollment gets rejected. Get the name right once, use it everywhere.

The liability gap your LLC may not cover

This is the part I most want people to sit with, because it's a genuine misconception.

An LLC is generally meant to shield your personal assets from your business's debts. If the business owes money, creditors typically can't come after your house (though how well that holds up varies by state and country, and depends on you actually running the LLC like a real, separate entity). Good. But even where it works as intended, an LLC on its own generally doesn't address the risk that your software causes someone a real financial loss. If a bug in your app produces a wrong number and a customer relies on it, that's not a "business debt." That's a claim that you built something that hurt them.

Think about who actually uses these apps. If a solo business owner runs their livelihood on your app (tracking income and expenses, generating records they lean on at tax time), and a calculation is wrong or data goes missing, the harm is concrete and traceable to your product. Your LLC likely doesn't touch that exposure.

The thing that does is Errors and Omissions insurance, specifically Tech E&O. It's built for exactly this gap: professional mistakes in the thing you built. And given that apps tend to touch personal or location data, it's worth looking at a Tech E&O + Cyber Liability bundle rather than E&O alone, because cyber covers you if customer data gets exposed. That second risk grows the moment you go from one trusted tester to actual strangers.

Timing matters here, and you don't need it on day one:

Put simply: get it before real customer data or real money touches the app, whichever comes first. And get an actual quote comparison from brokers who do tech-focused small business coverage (Vouch and Hiscox both do these bundles) once you're a month or two from launch. Don't guess at your own coverage limits.

Privacy is a design constraint, not a page you generate

If your app collects anything personal (customer details, financial-adjacent data, location), your privacy policy is not a checkbox you satisfy with a generated template. It's a description of what your system actually does, and it needs real content because it's a promise you're making and a document a regulator could hold you to.

This is where that architecture-not-a-checkbox framing gets very concrete very fast. The cleanest way to keep your privacy policy honest is to collect less. Every field you don't gather is a field you can't leak, can't misuse, and don't have to explain. Data minimization isn't just good privacy hygiene, it shrinks the surface area of everything else on this list, including your insurance exposure.

Decide what you collect and why before you write the policy, because the policy has to match the code. Getting that order backwards is how people end up publishing a promise their app doesn't keep.

The money plumbing

Payments are their own little maze, and a couple of things aren't obvious:

• Business banking. You'll want a business bank account separate from your personal one (services like Novo are aimed at exactly this small-business case). It typically only needs your LLC documents and EIN, so you can open it as soon as the EIN lands. It does not depend on your Apple account being approved.
• Accounting and a chart of accounts. Set up bookkeeping early (something like Wave, linked to your bank) so the business's money is clean from the first transaction. One nuance worth catching: with modern in-app purchase (StoreKit 2), the app store is your payment processor. Apple's cut isn't a "merchant fee" line the way a card processor would be, so categorize it as something like App Store Commission. Small thing, but it keeps your books accurate from the start.
• The store's tax and banking section. This is separate from your developer enrollment and easy to overlook. App Store Connect has an Agreements, Tax, and Banking section where you enter your tax info (EIN/W-9) and your payout bank details. If you skip it, your payouts get blocked later even though everything else looks fine.

The insight that actually saves you weeks: parallel tracks

Here's what I got wrong on my first pass, and the reason I'm writing this. I assumed all of this was sequential. Do step one, then step two, then step three. It's not. The dependencies form a tree, not a line, and once you see which things gate which, a lot of it runs in parallel.

Almost everything hangs off your approved LLC name. The instant you have that:

• Your EIN and your D-U-N-S lookup can start the same day. They both only need the approved name, so there's no reason to do them one after the other. (Start the D-U-N-S first, since it's the slow one.)
• Your website, support page, and privacy policy also only need the name, so that work runs alongside the paperwork instead of after it.
• Your bank account only needs the LLC docs and EIN, not an approved Apple account, so it opens well before you touch the developer program.

By the time you get to actually enrolling in the developer program, if you've done the above, it's close to a formality: name, tax ID, business identifier, and website are all already in place.

Here's the whole thing as an ordered checklist, with the parallel tracks called out:

1. File your LLC. Lock the exact legal name now. Everything downstream has to match it.
2. Get your EIN and start the D-U-N-S lookup, same day. Both only need the approved name. EIN is near-instant; D-U-N-S is the long pole, so kick it off first.
3. Build your app website (domain, support page, real privacy policy). Also only needs the LLC name, so run it alongside step 2.
4. Open your business bank account. Needs LLC docs plus EIN, not Apple approval. Do it as soon as the EIN lands.
5. Enroll in the Apple Developer Program as an organization. With LLC, EIN, D-U-N-S, and website in place, this is mostly a formality. Triple-check the entity name matches your D-U-N-S record exactly before submitting.
6. Set up accounting, link your bank, build a chart of accounts (remember the App Store Commission line).
7. Complete App Store Connect's Agreements, Tax, and Banking section. Separate from enrollment. Enter your tax info and payout account here so nothing blocks your money later.
8. Get E&O insurance before real customer data or real money touches the app.
9. Create the app listing and publish.

The part I was least worried about

Notice that writing the app doesn't even appear in that list. It runs in parallel with all of it, and it was the part I was least worried about the whole time.

That's the real lesson. If you're going into app development thinking it's write-the-code-and-publish, the code is not where the surprises live. The surprises live in the business you didn't realize you were starting: the entity, the liability you thought your LLC covered but may not, the privacy promises baked into your data model, and a couple of long-lead-time items that will stall you for weeks if you find out about them too late.

None of it is hard. But almost none of it is fast if you start it the day you're ready to ship. Start it the day you decide to build.

Comments welcome!