Who Owns What in a Website Project? Comparing Delivery Models

Choosing how a website will be delivered is not just a matter of deciding who will design or develop it. You are also deciding who will define the requirements, prepare the content, run acceptance tests, own the service accounts, manage the launch, and respond when something goes wrong after release.

That is why a hosted website builder, an independent specialist, and an agency should not be compared on price and delivery time alone. A useful comparison makes ownership visible throughout the project. The responsibility matrix below is designed to help buyers document that ownership before accepting a proposal.

Define responsibilities before choosing a delivery model

The phrase “corporate website” can describe very different projects. One business may only need to present its services and provide a clear contact route. Another may require multiple languages, user roles, custom forms, third-party integrations, or workflows built around internal operations.

The first project may need a deliberately limited scope. The second requires coordinated work across design, frontend development, backend development, integration, content, SEO, and quality assurance. The better starting question is therefore not only “Who should we hire?” but “Who owns each task, and how will that responsibility be confirmed?”

If your scope is still unclear, begin with our guide to preparing a website requirements document. A delivery model cannot be evaluated properly against requirements that have not yet been defined.

What do the three delivery models mean?

Responsibilities vary by provider, platform, contract, and scope. The following descriptions are not universal rules. They are practical prompts for questions that should be answered during procurement.

Hosted website builder

With a hosted website builder, much of the design and functionality is shaped by the platform’s templates, modules, and configuration options. The business may remain responsible for content entry, image selection, account administration, and routine settings. Even when setup support is included, buyers should ask how custom requirements will be handled, whether required integrations are supported, and what can be exported if the platform is changed later.

Independent specialist

An independent specialist may deliver a direct working relationship centred on one person’s expertise and availability. This can make communication straightforward when the assignment is narrow and requires a clearly defined skill. When design, development, content, SEO, testing, hosting, and launch management are all involved, the proposal should explain whether one person will cover them, whether other specialists will participate, or whether some responsibilities remain with the client.

Agency delivery model

An agency model is intended to coordinate multiple disciplines under one project plan. The word “agency,” however, does not by itself guarantee clear ownership or continuity. Buyers should still confirm which roles will participate, where decisions will be documented, what happens when the main contact is unavailable, and what post-launch support does and does not include.

Website project responsibility matrix

Complete this matrix separately for every provider you are considering. Avoid descriptions such as “the provider handles it.” Record the responsible person or team, required output, approval owner, and exclusions.

The purpose of the matrix is not to shift every task to the provider. The client may remain responsible for factual accuracy, legal copy, brand assets, internal approvals, and timely feedback. The goal is to prevent any task from remaining in an unowned space between both parties.

Who owns discovery and scope?

The client understands its commercial goals and internal operations. The provider should translate those needs into an information architecture, user journeys, and technical requirements. Discovery should therefore be a shared activity rather than a one-sided questionnaire.

On the client side, identify the decision-maker, project owner, and relevant departmental representatives. On the provider side, clarify who will lead the questions, document the requirements, and maintain the approved scope.

A later request can only be assessed fairly as a defect, an interpretation of agreed scope, or new development if the starting scope was documented. The same record is essential when comparing bids. If you already have several proposals, use our website proposal comparison scorecard to review them consistently.

How should content, design, and sign-off be shared?

Website content is more than copywriting. Someone must own the accuracy of service and product information, rights to use images, legal copy, contact details, and every localized version.

The design process also needs a clear feedback and approval route. Independent comments from several stakeholders can pull a project in conflicting directions. A client-side owner who consolidates feedback and provides the final decision helps keep the approved direction clear.

Kumsal Ajans offers unlimited design revisions until design sign-off. Requests that alter the approved structure or scope after sign-off may be treated as additional work. Establishing this distinction at the beginning prevents a design revision from being confused with a scope change.

Who owns development, integrations, and acceptance testing?

A project involving custom forms, membership, role-based access, payments, multiple languages, or external services requires more than completed screens. Business rules, failure states, permissions, and test scenarios also need owners.

The client may provide the service account and define the business rule, while the provider implements the technical connection. The parties should separately record third-party charges, usage limits, access credentials, and work caused by later changes to an external service.

Before launch, test at least form submission and email delivery, mobile and tablet layouts, current browsers, language switching, links, the management panel, and project-specific integrations. The project should also state who gives client acceptance and what counts as a critical defect. Our website handover checklist provides a more detailed review.

Who should own the code, data, and service accounts?

The ownership of the domain, hosting, email, analytics, and third-party accounts can feel unimportant while the same provider manages everything. It becomes critical when the provider changes or a new internal owner takes over.

The proposal or contract should answer these questions:

• In whose account is the domain registered?
• Who has hosting and server access?
• Which roles exist in the management panel?
• Under what conditions are the source code and database delivered?
• Who is the primary owner of analytics and search performance accounts?
• Who pays for third-party licences and usage-based services?
• How will access be transferred when the service relationship ends?

Kumsal Ajans prefers domains, hosting, email, and third-party service accounts to be created directly for the client wherever possible. Project-specific source code is transferred after the contractual payment and delivery conditions have been completed. Client and user data belong to the client. Open-source libraries and third-party components remain subject to their own licence terms.

How should post-launch support and continuity be assessed?

A website does not create one single type of post-launch work. Defect correction, security maintenance, content changes, new features, and work caused by a third-party service change are different responsibilities. The agreement should separate work included in the original delivery from maintenance and new development.

Unless a proposal or contract states otherwise, Kumsal Ajans provides six months of free technical support from go-live or final delivery for defects within the delivered scope and technical issues caused by the project. New features, modules, integrations, design changes, and scope extensions are not included. Ongoing maintenance and development can then be planned under an annual support model.

Continuity also depends on who can take over the work. Depending on the project, Kumsal Ajans may involve a project manager, designer, frontend developer, backend developer, content specialist, and SEO specialist. Because project decisions and processes are documented, another team member can take over when the relevant person is unavailable. This does not promise a specific response time or uninterrupted service, but it is intended to prevent the project from depending solely on one person’s memory.

Post-launch planning should also separate initial delivery from recurring services and future development. Our three-year website cost template can help structure that budget.

Which delivery model does Kumsal Ajans recommend?

Kumsal Ajans evaluates website projects from a custom software and organisation-specific responsibility perspective. As part of its own service approach, it does not recommend a third-party website builder or freelancer model as a sufficient delivery solution. This is not a claim that every freelancer or hosted platform fails in every project. It is Kumsal Ajans’s position on account ownership, team continuity, customisation, and post-launch responsibility.

For a straightforward corporate presentation and contact website, the scope can be intentionally limited. The resulting solution is not a third-party ready-made website. It is a focused configuration of Kumsal Ajans’s own web platform, using only the capabilities the project needs. Requirements such as multiple languages, custom permissions, integrations, or organisation-specific workflows expand the scope accordingly.

For a separate technical assessment of platform choice, see our guide to off-the-shelf and custom web software.

Two anonymised project examples

A project requiring multiple languages and integrations

One anonymised project required multiple languages, custom permissions, and integrations. The available off-the-shelf structure could not meet those requirements sustainably, so a project-specific solution was developed. The client, sector, date, user count, and integration details are withheld to protect the project’s identity.

The lesson is not that every multilingual website requires the same level of custom software. Language-to-page mapping, user roles, data flows, and integrations must be assessed together.

A focused corporate presentation website

Another project only needed to explain the organisation’s services and give visitors a reliable contact route. It did not require custom roles, complex integrations, or operational workflows. Kumsal Ajans therefore configured its own platform around a deliberately limited scope.

This example demonstrates the value of avoiding unnecessary features when the underlying need is simple. A focused project scope is not the same as using a third-party website builder.

Ten questions to ask before accepting a proposal

1. Who will prepare and approve the requirements and scope?
2. Who owns the accuracy, localization, and legal review of content?
3. Who consolidates design feedback and gives final sign-off?
4. Which people or teams own frontend, backend, and integration work?
5. Who prepares test scenarios and who gives client acceptance?
6. In whose name will the domain, hosting, email, and service accounts be opened?
7. Under what conditions will the source code, database, backups, and technical information be delivered?
8. Who takes over when the primary contact is unavailable?
9. How are defects, maintenance, content changes, and new development separated?
10. What are the duration, boundaries, and commercial model of post-launch support?

Do not leave these answers only in meeting notes. Record them in the requirements document, proposal, contract, or project management system. You can then compare providers by their actual ownership model rather than their label.

Conclusion: compare ownership before provider labels

Choosing a website builder, an independent specialist, or an agency does not by itself explain how the project will be managed. Before work begins, ownership should be visible across discovery, content, design, development, testing, account administration, handover, and post-launch support.

Kumsal Ajans favours a model that coordinates the disciplines required by the project, records decisions, protects client account ownership, and defines post-launch boundaries. The scope can be reduced for a straightforward project, but the platform remains Kumsal Ajans’s own system configured around that project’s needs.

To define who should own each responsibility in your website project, you can arrange a requirements and scope discussion with Kumsal Ajans.

Frequently Asked Questions

Who should prepare the content for a website project?

Content ownership should be agreed at the start. The client can confirm the accuracy of organisational and service information, while the agency may provide information architecture, editing, copy support, or SEO assistance within the proposal scope. Legal copy may require review by an appropriately qualified professional.

Which responsibilities should be documented when working with a freelancer?

Document who owns design, frontend and backend development, content, testing, hosting administration, source-code delivery, launch, and post-launch support. If other specialists will participate, the coordination owner and final accountability should also be stated.

What is the main responsibility difference between a website builder and a custom platform?

With a hosted website builder, platform rules may determine some technical boundaries and updates, while the business may retain much of the content and account administration. A project-specific platform can assign responsibilities around the agreed requirements. The exact position should always be confirmed in the service contract.

How does Kumsal Ajans manage design revisions?

Kumsal Ajans provides unlimited design revisions until design sign-off. Requests that change the approved structure or agreed scope after sign-off may be treated as additional work.

What does the first six months of post-launch support cover?

Unless the proposal or contract states otherwise, the first six months cover correction of defects within the delivered scope and project-caused technical issues. New features, integrations, design changes, and scope extensions are not included in free support.