For custom mobile app development, whose name should the domain, server, and developer account be under?

Accounts that require real-name verification or long-term holding should be registered under the client's name; the developer may assist with registration and configuration but must not become the account owner. In custom mobile app development, the domain, server, and developer accounts are often called "basic supporting items," yet they determine who controls the brand entrance, data storage, and listing credentials. Based on 2026 project delivery experience, placing such accounts under the development company or individual developer may seem convenient at first, but later it can get stuck at app store entity review, payment setup, data migration, and outsourcing handover. Unclear account ownership typically causes launch delays of one to two weeks; if combined with ICP filing and supplementary software copyright registration, delays of over a month are not uncommon.

Why account ownership matters more than you think

Whoever holds the domain controls renewals and DNS resolution; whoever owns the server account controls backups and code; whoever's entity is used to register the developer account is bound to the app's release and signing. UI and feature code can be redone later, but once account ownership gets tangled up with contract termination or staff turnover, the resolution cycle is measured in weeks.

App stores are increasingly strict about entity consistency. In 2026, major Android marketplaces and Apple's review backend will check whether the developer account entity, software copyright owner, and payment merchant account belong to the same entity. If you list the app under the developer's enterprise account but register the software copyright under your own company, the review will be rejected due to mismatched materials, and resubmission requires queuing again. These issues should be checked before development starts, not after testing passes.

In delivery practice, there was a project where the client, to save the first-year server fee, asked the developer to purchase a cloud host on their behalf; during the ICP filing process, they discovered an entity mismatch and had to refund and repurchase. Before coding even started, the total timeline had already grown by two to four weeks. Our approach is to spend two to three days sorting out account entities before moving into the development schedule. This slows the early pace slightly but avoids a later one-to-two-week review rejection. In the 2026 delivery environment, sorting out such accounts takes three to five working days, a recurring experience range.

Some projects do not expose account issues during development because testing uses the developer's own certificates. Only when switching to the formal account before submission do they find that the software copyright has not been granted, the payment merchant account has not been approved, and the server ICP filing entity is wrong. All development work has to stop and wait. Instead of pushing these steps to the end, write account preparation into the first milestone of the project plan.

Which domains, servers, and accounts should the client handle itself?

The criterion is not who pays, but who bears the real-name requirement under platform rules. Where a business license, legal representative ID, corporate bank account, or face recognition is required, the developer cannot pass verification on your behalf. Based on 2026 outsourcing delivery practice, the following checklist can be used for item-by-item verification:

• Domain: Register with the client's business license or legal representative ID; the registration email and DNS admin password should be kept by the client.
• Server: Purchase under the client's cloud account, with the ICP filing entity consistent with the client; the developer uses only a sub-account for operations.
• App developer account: Apple Developer accounts require enterprise information to be bound, and Android marketplace developer accounts are also recommended to be registered by the client.
• Payment merchant account: WeChat Pay and Alipay merchant accounts should be applied for under the client's entity, so settlement and reconciliation do not route through the developer.
• Third-party open platforms: Keys for map, push, SMS, and similar services should be applied for under the client's entity as required by each platform, to avoid feature failures from replacing keys after launch.

The developer can assist with software copyright application materials, server environment setup, domain DNS resolution, app store backend information, and privacy policy page generation, but assistance does not mean holding the account. You can self-check: are the registration email, bound phone number, and recovery codes for every account concentrated in the hands of the client's contact person? When the developer needs to use an account, is it authorized by the client, rather than the developer holding an admin role?

Pay attention to the enterprise mailbox as well: if the mailbox under your domain receives verification codes, set up a shared mailbox and keep login logs, so that verification codes are not lost after an individual handler leaves the company.

Three common approaches: cost and risk comparison

Based on 2026 project delivery experience, there are three main ways to handle the accounts. The comparison below can be checked item by item against your project:

• The client provides all formal accounts: Initial startup takes 1–2 extra working days for document submission; ICP filing and software copyright are external waiting times, with typical ranges of 7–20 working days and around 30 working days, respectively; later risk is low, and switching outsourcing vendors, domains, or servers does not depend on others.
• Use the developer's test accounts during development, then migrate to the client before launch: The development phase starts faster; migration takes 1–3 extra working days for configuration checks; risk is medium, and missing any certificate callback can cause crashes.
• Publish directly under the developer's own developer account: Early work is simpler, but the probability of entity mismatch with the software copyright is high; transferring ownership requires a platform appeal with a typical timeline of two weeks or more, and the outcome is uncertain; risk is high, so it is not recommended for formal external products.

From the experience range, the difference in initial startup speed among the three approaches is about one week. Later, however, if personnel or service providers change, client-owned accounts usually save one to three weeks, while developer-held accounts may require a process measured in months. What truly determines long-term risk is not the few hundred yuan saved on the first-year cloud host fee, but who holds the accounts.

When should account preparation start?

Many teams leave software copyright, ICP filing, and payment approval until after development is complete, which means that once development acceptance passes, they can only queue for external processes and the launch is pushed back by one or two months. Account preparation should run in parallel with development, not close to launch. Based on the typical 2026 outsourcing project pace, proceed as follows:

1. Before contract signing: confirm whether the client's current enterprise qualifications can register the intended developer accounts; review the expiration dates of existing domains and servers to avoid sudden expiry in the middle of development.
2. Week 1: purchase the domain and buy the server under the client's cloud account, then submit ICP filing. The typical filing period is 7–20 working days, and you can run requirements analysis and UI design in parallel during this phase.
3. Mid-development: submit the software copyright application under the client's entity; the typical processing period is around 30 working days. Meanwhile, register the developer account and payment merchant accounts, because these reviews usually need additional materials.
4. At the end of development: switch code, certificates, and third-party keys to the production environment and run full regression tests, focusing on login, payment, push, and map functions under the formal accounts.

For enterprise entity applications, most developer accounts also require corporate bank account payment verification or legal representative face recognition. These steps are not under the developer's control, so never set the day development ends as the day you submit for review.

Frequently asked questions

If I am an individual without a company, can I still commission a custom app and list it normally?

Individuals can apply for independent developer accounts on some platforms to list apps, but WeChat Pay, Alipay merchant accounts, and enterprise open platform services mostly require enterprise qualifications. If you need payment collection or corporate data features, it is recommended to prepare accounts under a company name first.

Is it feasible to keep the domain and server under the developer's name first and transfer them later?

Domain transfer out and server ownership transfer require operation in the management backend. If the developer does not cooperate, you can only go through the platform appeal process, where the timeline can vary widely. The common safe practice is to purchase directly under the client's entity, because the transfer cost is far higher than expected.

Does software copyright registration have to wait until the app is fully developed?

The application materials generally require usable source code and a user manual, not the final UI. The common approach is to organize and submit core modules in the middle or later phase of development, so the external review time runs in parallel with the development cycle, rather than waiting in line after development finishes.

If we use the developer's test environment for development and migrate to the client's server before launch, what should we check?

Focus on the API domain, push certificates, third-party callback URLs, database permissions, and file storage permissions. It is recommended to use the production domain and the client's account to set up the environment during development; the later the migration, the more likely you are to miss something.

When is client self-holding appropriate, and when is it not necessary to stick to this rule?

This article advocates that domains, servers, and developer accounts be registered in the client's real name. This is suitable for public-facing products that need long-term operation, involve real user data, and may need to switch among multiple service providers in the future. If your project is a one-time demo for internal presentation, or a campaign app that is explicitly scheduled to be taken offline after three months, using the developer's test environment can save early registration and ICP filing time. However, the contract must still state how the code and database will be handed over after the demo ends, to avoid a data gap after cooperation ends.

If the business involves cross-border data transfer or industry compliance requirements, server nodes must be located in regions within China as required by regulators, and the client must be the subscription entity. There is no room for compromise here, and outsourcing vendors' verbal assurances cannot circumvent this.

Starting point: list the five categories—the domain, the server, the developer account, the payment merchant account, and third-party open platforms—and fill in the current registered entity for each. If the entity is not the client's name, either change it back before development starts, or specify the transfer timeline in the contract. The earlier you address these account issues, the lower the launch and handover costs will be.