Before You Hire a Website Developer: Accounts, Access and Ownership

Before hiring a website developer, agree which accounts belong to your business, what access the developer needs and who can approve changes. These decisions affect the project from its first day. Leaving them until handover can turn a straightforward build into a search for logins, missing files and unclear permissions.

Our website development service for Tagaytay and Cavite businesses starts with the work you need and the responsibilities around it. A useful proposal explains both the website deliverables and how the people involved will work together.

Identify the accounts you already use

Make a short inventory before arranging project access. You may have a domain registrar, website host, email service, existing website platform, analytics account and tools used for enquiries or bookings. A new business may have only some of these. Record the actual starting point rather than opening replacement accounts automatically.

For each service, identify the business account holder and the person authorised to approve changes. Check who receives renewal notices and who can recover the account if a team member leaves. A familiar website address does not prove that the right person can manage its registration.

If another provider manages an account, explain that arrangement to the prospective developer. Agree the coordination needed before including a transfer or connection change in the project. The first conversation should establish the situation without requiring you to send passwords or customer records.

Distinguish account control from project access

A developer may need access to carry out the agreed work. That does not mean every participant needs the same account or permissions. Ask which services are needed, for what task and for which stage of the project.

For WordPress, roles determine what a user can do. The official roles and capabilities guide explains the different permissions. Agree suitable accounts for development, content editing and business administration instead of assuming that one shared login is the complete access plan.

Discuss who will arrange access and review it when the work ends. The aim is a practical working arrangement your team understands. Keep account recovery under the control of an authorised person in the business.

Agree what you are commissioning

“You own the website” needs enough detail to be useful. Ask the proposal to identify what the provider will deliver, what you supply and which services or licences remain subject to another provider’s terms.

Clarify these items before signing off the scope:

• The website files, content and design work included in the project.
• The hosting and domain arrangement, including the account holders.
• Any paid theme, plugin, font, image or external tool used in the build.
• The editing access and guidance your team will receive.
• What can be handed over if you later appoint a different provider.

Do not assume that a subscription or third-party licence becomes a business-owned asset merely because it appears on the website. Ask for the proposed arrangement in plain language. If a contractual ownership term is unclear, have it clarified before agreeing to the project.

Name the person who approves public content

Your developer needs to know who can confirm service descriptions, contact details, prices if published, photographs and client information. Several people can contribute, but a named final approver helps the team resolve conflicting comments.

Gather the assets you have permission to use. Identify where a photograph or project can be shown publicly and where information must remain private. Approval to build a page is not automatically approval to publish every name, image or document supplied during the project.

Our guide to the pages a small business needs for launch helps you identify the content that deserves attention first. Give the developer approved facts and useful assets for that scope, rather than sending an unlabelled archive and assuming everything will go live.

Make the review process part of the agreement

Ask how you will review the build, where comments should be recorded and what counts as a new request. Agree the decision points that need business approval, including the final public content and any change to the live website connection.

A local meeting and a remote review can both work. What matters is that the next action, owner and approval are clear. Our local versus remote developer guide helps you assess communication alongside relevant experience.

Plan a handover your team can use

Before appointing the developer, describe the routine changes your team expects to make. Ask for a demonstration of those tasks and a record of the agreed accounts, tools and support contacts at handover. Receiving a login is only useful when the responsible person knows what to do with it.

Continuing technical care is a separate buying decision. Use our website maintenance service to discuss that work, rather than assuming it is permanently included in the build.