Do I Need to Set up a Company to Build a Mobile App?

Founders ask us about company formation before they ask about screens, features or launch dates. The idea is there, a rough budget is there, and then someone at a dinner mentions Companies House and the whole project pauses for a month while they work out whether setting up an app company is something they have to do before anything else happens.

By default the name on the risk is yours, which is fine until it isn't.

The short answer is that you don't need a company to publish an app. Apple and Google will both accept an app registered to a person. You can build it, launch it and take money through it with nothing more than your own name and a bank account.

The longer answer is that the structure you pick decides who owns the developer account, who signs the build contract, who the payment processor will deal with, and who carries the risk if something goes wrong. We've watched all four of those become live issues on real projects, usually at the worst possible moment, which is why we'd rather talk about it early than halfway through a build. This piece walks through what the stores actually ask for, what starting an app business in the UK involves, and the points where the decision stops being administrative and starts shaping the product.

The Short Answer: What the App Stores Actually Require

Apple's developer programme has two routes in. You can enrol as an individual or sole trader using your own legal name, or you can enrol as an organisation, which asks for a registered legal entity and a D-U-N-S number attached to it. Google Play works in a similar way, with a personal account or an organisation account, and the organisation route asks for company details it can check against public records.

Both stores charge a fee to join, Apple's billed yearly and Google's as a one-off. Neither asks to see a business plan. Neither has an opinion on whether you've incorporated, so long as the paperwork matches a real person or a real company.

What founders miss is the public part. An individual account publishes under your own legal name, and that name sits on the listing underneath the app title where anyone can read it. On a gifting and wishlist platform we worked on, the client was hesitant to spend anything on the store listing because the product was social and they assumed referral would carry it. Our view was that the icon, the copy, the category and the first screenshot all have to say what this is, so people rule themselves in or out before they download. The developer name is part of that first read.

Decide what name you want showing on your listing before you enrol, because changing it afterwards means proving the change to both stores and waiting on their review teams.

Individual vs Company Developer Accounts on Apple and Google

An individual account is quicker. You sign up, you verify yourself, you're in, often the same week. A company account asks for more upfront, and Apple in particular will check that the person enrolling has the authority to bind the company, which means a bit of back and forth before you get access.

The differences that matter after launch are the ones nobody reads about in advance.

• The developer name on your listing is your own name on an individual account, and the company name on an organisation account.
• Roles and team access are far better on an organisation account, so designers, developers and testers can be given what they need and nothing more.
• New personal accounts on Google Play have to run a closed test with a group of real testers over a couple of weeks before they can apply for production access.
• Moving an app from a personal account to a company one later is possible, and it's a process with its own rules, waiting time and chances to get stuck.

If you already know you're going to raise money, hire, or bring in an agency, start on the company account. Doing it twice costs more than doing it once, and the second time always lands in a week when you're trying to ship.

Who Owns the Developer Account, and Why It Matters Later

On a social football product we worked on, the client set up the App Store Connect account themselves, so the Account Holder role sat with them. They gave us admin access to most of the account, and we built three testing groups, one for our team, one for the client, and an external beta group for their own QA testers. That structure let us control which build went to which group during deployment, which is how you keep a release calm.

As launch got close, the client started going into the account and sending builds that were already uploaded to whoever they wanted in the groups. It caused problems. Because the account was registered to them, they had full access, and we had very little in the way of practical ability to stop it.

Whoever holds the Account Holder role holds the product, and everyone else works at their invitation.

That story isn't an argument against clients holding their own account. It's the opposite. The account should sit with the business that owns the product, and when that business is a company rather than a person, the role can move with the job instead of with the individual. A co-founder leaving, a phone being lost, a recovery email going dead, any of those can lock you out of your own listing when the account is tied to a person.

Sole Trader, Partnership or Limited Company

Three structures cover almost everyone starting an app business in the UK. The choice usually comes down to how much risk the product carries, whether anyone else owns a piece of it, and whether outside money is in the plan.

When a founder asks us which one to pick, our answer is nearly always the limited company, and the reason is practical rather than tax driven. A company can own the account, sign the contract, hold the intellectual property, open a payment account and issue shares. A sole trader does all of that as themselves, which works right up until a user complains, a processor asks for documents, or an investor asks what exactly they're buying a slice of.

How to Set Up a Limited Company in the UK

What setting up an app company involves

The filing itself is dull and fast. Done online with Companies House, it's usually approved within a day, and the fee is small next to anything else you'll spend on the product.

1. Check your company name is free and that the matching app name isn't already taken on both stores.
2. Name your directors and shareholders, and agree the share split in writing before you file rather than after.
3. Give a registered office address, which can be an accountant's address if you don't want your home address public.
4. Pick a SIC code that describes what you do, usually one of the computer programming or information service codes.
5. File with Companies House, then register for Corporation Tax with HMRC within three months of starting to trade.
6. Open a business bank account in the company name, and apply for your free D-U-N-S number so Apple can verify you.

The share split is the step worth slowing down on. We've seen founders file a fifty-fifty split with a friend in an afternoon and spend the next year working out what happens if one of them stops turning up. Vesting, roles and what counts as a contribution are all easier to agree while everyone's still excited.

Running Costs, Tax and Admin Once You Are Incorporated

A company brings a yearly rhythm. There's a confirmation statement, annual accounts, a Corporation Tax return, payroll if you pay yourself a salary, and VAT registration once your turnover passes the threshold. An accountant handles most of it for a monthly fee, and that fee is part of your product budget whether you've written it down or not.

Then there's the money the stores take out of every sale before it reaches you, which catches founders who've modelled revenue off the sticker price. Add hosting, domains, design tools, a support inbox and whatever you spend getting people to the listing in the first place.

We worked on a football-focused social media app where the client wanted a streamlined first release, and the budget they'd set was nowhere near the premium experience they were picturing. A lower budget means less flexibility and a tight focus on getting something launchable into the market. This client wanted the low budget without the limits that come with it. We had several conversations trying to line the expectation up with the money. The product did get finished, with compromises on features, because they chose to spend in areas we rated as lower priority.

When Your App Idea Forces the Decision: Payments, Data and Regulated Categories

Some products decide this for you. If you're holding money, moving money or handling sensitive personal data, a company stops being optional in any practical sense. Payment processors want a legal entity, a registered address and company documents before they'll onboard you, and handling personal data in the UK means registering with the ICO and having someone answerable for it.

We worked on a peer-to-peer currency exchange product where travellers could swap leftover foreign currency at interbank rates and skip the commission. The transfer mechanism was good. What we hadn't factored in was anti-money laundering. Apple flagged the product as a possible vehicle for laundering because transfers were unlimited, so we went back and retrofitted stricter KYC checks, extra transfer security and hard caps on how many transfers any two people could make.

Compliance built in afterwards is always more expensive than compliance built in at the start.

On the same family of product we found partway through that direct peer-to-peer transfers weren't allowed, legally or under Apple's rules, so the whole thing had to become location-based and in person. A later version kept being rejected. Each time we answered one objection, a new one arrived. We capped transactions at €150, which should have settled the money laundering concern, and it was rejected again. The client ran out of budget and walked away. Apple Pay launched shortly afterwards, and we believe the two were connected.

Contracts, IP and Protecting the Work You Pay For

The contract decides who owns the code, the designs, the brand and the data. A well-written agreement assigns all of it to the company that paid for it on completion, and that only works cleanly if there's a company to assign it to. Where a sole trader commissions a build, the IP lands with the individual, and untangling that at investment stage is slow and expensive.

The other half of protection is being specific about what you're buying. On a dating app project built around verified profiles and keeping bots out, the client wanted to skip discovery on the messaging side and put everything into onboarding. What got built was a generic messaging feature that let automated and fake messages straight through, which undid the verification work the product was named for. The whole messaging section had to be rewritten, around £15,000 of extra budget and two more months.

Everything we produce goes out under our own name, and the product IP goes to the client's company. Keep the paperwork pointing at the same entity throughout, including the smaller things, because those are the ones nobody checks until due diligence.

Put the company name, not your own, on every account you open for the product, including domains, hosting, analytics, design tools and the store accounts themselves.

Funding, Investors and Looking Like a Real Business

Investors buy shares, and only a limited company has them. UK schemes like SEIS and EIS, which make early cheques far more attractive to angels, need a company too. If raising is anywhere in the plan, incorporate before you start the conversations rather than during them.

What gets you the meeting is something people can hold. We saw this with a trading card platform client who was getting nowhere with pitch decks. He got as far as he could with a vibe-coded version of the product, and that put him in a much stronger position, because he had something demonstrable he could put in front of people and walk them through.

The appetite for consumer products is still there. Pew Research Center, 2026 found that 41% of American adults say they're online almost constantly, which is the behaviour every phone-first product is built on.

Money in the bank solves less than founders expect. On a well-funded sports club app project, built to handle finances, games, schedules and players across different sports, the client pushed back on incremental release the whole way through. No single sport first, no single platform first, no MVP. They wanted everything ready before anything launched, and that set the conditions for scope creep that never stopped.

Getting the Structure Right Before You Commit Budget

The structure conversation and the product conversation belong in the same room, and a clear app planning and strategy process is what brings them together, because both answer the same question, which is what this thing actually is. Simon's version of that question is the one we put to founders early. Are you solving a real problem that people will pay for, or are you in love with the solution?

We worked with a property developer building a concierge app for high-rise properties. They arrived with a budget already set and a clear picture of what they wanted, looking for us to validate it rather than scope it. We persuaded them to run a proper discovery phase first, with focus groups and user workshops. What came out was that the product needed to be far simpler than they'd imagined. A lot of the planned features were dropped, and the focus moved to creating a human connection with the product instead of replacing systems the building already had. Better product, lower cost.

Worth remembering who you're building for. Pew Research Center, 2026 reports that 16% of U.S. adults are smartphone-dependent, owning a phone without home broadband, so for a real slice of your audience the app is the whole route in.

Conclusion

You don't need a company to publish an app, and most founders we work with end up with one anyway, usually within a few months of launch. The trigger is rarely the store. It's a payment processor asking for documents, or an investor asking who owns the code, or a co-founder conversation that needs a share certificate behind it.

Our advice is to incorporate before you commission the build. Register the developer accounts to the company, sign the contract as the company, and keep every account pointing at the same entity from day one. It costs very little at the start and saves a lot of unpicking later, as the social football product's account access taught us, and as the currency exchange work taught us about compliance arriving late.

Treat the whole thing as a long-term investment. The structure, the discovery, the listing and the first release all compound or all drag, and the founders who do best are the ones who sort the boring parts while there's still time to be patient about them.

If you're weighing up the structure before you spend anything on design or development, let's talk about how to set your app business up properly.

Frequently Asked Questions