Custom website development: a colleague wants to help with articles — give them the admin password or create a separate account?

After a custom website build is delivered, a colleague wants to help publish articles. To save effort, sending the admin password directly is convenient in the short term; but once multiple people edit, someone leaves, or the backend holds inquiries, orders, and customer records, actions cannot be traced to a person and accounts cannot be taken back. Based on typical 2026 delivery practices, a 1–2 person showcase site can be as simple as one admin account plus one editor. For multi-person collaboration or sites with customer data in the backend, it is better to have one account per person with role-based permissions, so when someone leaves you deactivate the account instead of just changing the password once.

Where do the risks usually show up when you give a colleague the admin password?

The problem is often not “something will happen tomorrow,” but that when something does happen, you cannot trace it or recover it. Most corporate website backends record operation logs, but logs only record the account name, not the person. If three people use the same admin account and one day a section is deleted or a price is changed, all you can see is that the account made the change; you cannot identify who actually did it, which puts you in a passive position when you need to assign responsibility or roll back.

Another easily underestimated point is excessive permissions. An admin account can usually change navigation, delete sections, modify payment configuration, and export customer data. If a colleague who only publishes articles gets the admin account, you are handing the entire site configuration to them. One mistaken operation may take half a day to several days to recover, depending on whether backups are complete and how large the change is.

• Hard to trace: logs are recorded by account, so shared use cannot be tied to a specific person;
• Too much permission: admins can change sections, change configurations, and export data, far beyond what publishing articles requires;
• Hard to recover: when one person leaves, you must change the password and notify everyone one by one; miss one notification and the password is effectively unchanged;
• Wide spread: passwords are often sent via WeChat, chat history, or verbally, and may remain on old devices after someone leaves.

When accounts are separate, how should roles be split in practice?

The basis for splitting is not job title but “what this role can break.” Separate the three types of permissions — changing configuration, touching data, and publishing content — so that if one account has a problem, the impact is controllable. The four layers below are fairly common in projects; smaller sites can keep only the first two.

1. Super admin: usually 1–2 people, responsible for accounts, permissions, backups, payments, and third-party API configuration; not involved in daily publishing;
2. Content editor: can write articles, upload images, and save drafts, but cannot publish, delete, or adjust section structure;
3. Reviewer/publisher: confirms content and layout before publishing, and can roll back to the previous version when needed;
4. Read-only viewer: can view inquiries, orders, or reports but cannot change content, often used by sales and customer service.

Two details are worth noting: first, separating editor and reviewer reduces typos and layout problems caused by publishing immediately after editing; second, grant only the permissions the work requires, and do not give admin to everyone just to save effort. Before delivery, confirm with the client who each account belongs to and what role it has, and write it into the delivery checklist so that adding or removing people later has a basis.

A delivery scene: when accounts are not separated, where does the cost land?

In one corporate site project, the client arranged for two operations staff to update in turn and one external writer to contribute. Budget and timeline were tight, the permissions module was cut, and the backend kept only one admin account whose password was sent to three people in a group chat. Two months after launch, the external writer mistakenly deleted a section while changing the layout and turned a block of pricing content on the homepage into a draft. Because the logs showed only the same account, no one could say who did it; recovery relied on comparing backups item by item.

The cost was not the recovery itself but the investigation. In typical ranges, basic role and account configuration adds about 1 to 3 person-days; restoring item by item from backups afterward commonly takes 0.5 to 2 person-days depending on the scope, plus repeated confirmation with the client about which version to restore. What you save is configuration time; what you spend more of is communication and fallback time. So cutting permissions is possible, but agree at the same time: content editor and admin should at least be separate, and the account register should be completed at delivery.

What is the difference between one account per person and a shared account?

There is no universal better or worse; match it to the actual number of users and data sensitivity of the site. The figures below are experience ranges; specifics depend on the actual project.

• Applicable scale: shared accounts suit showcase sites maintained by 1–2 people; one account per person suits teams of 3 or more or multi-role teams;
• Traceability: shared accounts can only be traced to the account; one account per person can be traced to the person;
• Recovery difficulty: shared accounts require changing the password and notifying everyone; one account per person only needs deactivation, without affecting others;
• Delivery cost: most backends include basic account management; role-based permission detail depends on complexity and commonly adds 1 to 3 person-days;
• Maintenance burden: shared accounts require almost no management; one account per person requires a register plus periodic reviews.

Which sites can be simplified first, and which should not cut corners?

For a pure showcase official website maintained by 1–2 people, updated monthly, with only articles and images in the backend, one admin plus one content editor account is usually enough. Forcing a full role-permission system instead adds development and training cost.

But if any of the following applies, it is not advisable to keep only one shared account: multiple people edit content at the same time; the backend contains inquiry, membership, order, or payment data; content is maintained by external people or an outsourced team. In these three cases, the traceability and recovery capability brought by separate accounts is worth more than the configuration time saved.

The boundary can be remembered in one sentence: the complexity of account permissions follows data sensitivity and the number of collaborators, not company size. A small company may have three people editing content at once, while a large enterprise may have only one dedicated operator.

When taking over or accepting delivery, check these items first

In 2026, many projects remember the account issue only at the final stage, and it is even harder to check when taking over someone else's site. The following items can be checked one by one during acceptance or handover.

• Account list: how many accounts exist in the backend and what roles they have;
• Account register: account name, role, user, activation time, maintained by the client;
• Initial password handling: changed by the client after delivery, not sent in plain text through chat tools;
• Offboarding recovery process: deactivate the account before handing over work and keep operation logs, rather than deleting directly;
• Periodic review: check the list quarterly or semiannually and clean up accounts that have not logged in for a long time.

The pass line can be set realistically: if the client can add a content editor account themselves and knows how to deactivate a departing person's account, that item passes. If the client has no dedicated technical staff, compress the process into a one-page explanation and include it in the delivery document.

FAQ

Is it a serious problem if the backend has only one admin account shared by several colleagues?

It depends on whether the backend contains customer or order data. For a pure showcase site the risk is relatively controllable; for sites involving inquiries, memberships, or payment data, it is better to create accounts per person.

After a colleague leaves, is changing the password enough?

Usually not. A safer approach is to deactivate that account first, then decide whether to delete it, so operation logs are preserved and other colleagues are not affected.

Should the admin account be left with the client at delivery?

Yes. The admin account should be handed to the person designated by the client, and the password should be changed on the spot. The development team generally does not keep it, avoiding later permission disputes.

Will adding multiple account permissions significantly increase development cost?

Basic account management is included in most backends; role-based permission detail depends on complexity, and in experience it commonly adds 1 to 3 person-days of development or configuration.

Can backend operation logs show exactly who made a change?

It depends on whether there is one account per person. Logs are recorded by account; a shared account only shows the account name, while separate accounts can be tied to specific people.

If you are accepting a custom website, start with one thing: log in to the backend and look at how many accounts are in the list, what roles they have, and whether anyone who has left is still on it. For sites involving customer data, separate the accounts before launch; for a showcase site maintained by 1–2 people, keep the simple two-account setup, and do not add extra budget for a permission system.