Where Does Free Website Support End and Ongoing Maintenance Begin?

Yazar: Üzeyir Hakan Ceylan02/08/202612 dk okuma

Henüz puanlanmadı Puanınız:

Free website support is the post-launch period in which defects within the delivered and approved scope are investigated and corrected. Ongoing maintenance covers recurring work—such as updates, security checks, backups, performance reviews and functional checks—needed while the website remains live. A request for a new page, feature, integration or workflow will usually be new development.

The most reliable way to distinguish these categories is not to ask how many minutes a task might take. Ask whether it was part of the approved scope, what caused the issue and whether it requires a recurring operational process.

Unless a proposal or contract states otherwise, Kumsal Ajans provides six months of free technical support from go-live or final handover for software defects within the delivered scope and technical issues caused by the project. Corporate websites can then move to an annual maintenance plan. Custom web software may instead require monthly or project-based maintenance, depending on its users, integrations and operational importance.

What Is the Difference Between Free Support, Maintenance and New Development?

The key question for free support is:

Is an approved, delivered function failing to behave as agreed because of a project-related defect?

If the answer is yes, the request may fall within free defect support. For example, an approved contact form that cannot create a submission because of a defect in the delivered implementation may belong in this category.

Maintenance starts with a different question:

Does keeping the live website current, observable and manageable require a recurring check or action?

Planned software updates, security reviews, backup checks, periodic form testing and performance monitoring may be included in a maintenance plan. The actual tasks and frequency should be defined in writing according to the platform, data, integrations and risk profile of the project.

New development asks a third question:

Does the request change or expand the approved scope?

A new application form, membership area, user role, payment flow, report or external-service integration may be valuable. It is not, however, a correction to a previously delivered function. It may therefore need a separate scope, schedule and budget.

When Does the Six-Month Free Support Period Begin?

Under the Kumsal Ajans model, unless stated otherwise in the agreement, the period begins on the go-live or final handover date. The start and end dates should be recorded in the proposal, handover note or acceptance record so that the six-month window is not open to different interpretations.

The free period covers:

Correcting software defects within the delivered scope
Making sure approved functions behave as planned
Investigating technical problems caused by the project

It does not allow the website to be changed without limit for six months. If the original scope, design approvals, feature list and acceptance checks were not recorded, it becomes difficult to distinguish a defect from a later change request. The pre-launch acceptance process therefore creates the boundary for post-launch support as well. The corporate website handover checklist can help teams record access, functionality, responsive behaviour and the support start date.

Which Requests Fall Outside Free Support?

Unless they are explicitly included in the proposal or contract, the following are assessed separately from free defect support:

A new feature, module or integration
A change or expansion of the approved scope
Design and user-experience revisions
A new page template or workflow
Substantial content or data entry
Adaptation required by a third-party service change
Work caused by intervention from the client or another provider
Domain, server, licence and third-party service fees
Routine maintenance, security updates, performance monitoring and operational monitoring

“It is only a small change” is not a sufficient classification rule. A field that looks small on screen may affect the database, user permissions, email messages and reports. Its impact should be reviewed before it is treated as a defect or free task.

Why Is Ongoing Maintenance a Separate Service?

A website does not remain technically unchanged after delivery. Server environments, software components, browsers, disclosed vulnerabilities and third-party services evolve over time.

The NIST Secure Software Development Framework treats identifying and responding to residual vulnerabilities in released software as a distinct practice group. It also recommends considering known vulnerabilities and end-of-support status throughout the lifecycle of commercial, open-source and other third-party components. This does not prescribe one maintenance package for every website. It shows why ownership and response processes for post-release changes should not remain undefined.

For a corporate website, an annual plan may organise recurring work across a defined period. Custom web software can have a different level of operational activity, transaction volume, user access and integration risk; monthly or project-based support may therefore be more appropriate.

The label of the plan is less important than its written scope. “Annual maintenance included” is not sufficiently clear unless it answers these questions:

Which tasks are included?
How often will each task be checked?
Who submits and assesses a request?
How are urgent and normal requests distinguished?
Are there written initial-response or resolution targets?
Which circumstances and third-party costs are excluded?
How will completed work be recorded?

What Should a Maintenance Plan Define?

Four maintenance-plan fields defining the task, frequency, owner and record — Defining maintenance through task, frequency, owner and record.

The following table can be used when reviewing a maintenance proposal or service schedule. Not every row is necessary for every project; an excluded item can be marked as not applicable with a reason.

Maintenance area	What should be defined	Question to ask
Software updates	Components covered, testing and rollback approach	Are updates applied directly to production?
Security	Review scope, notification and response boundary	Who is notified when a vulnerability is identified?
Backups	Files/data covered, frequency, retention and restore checks	How do we know the backup can be restored?
Availability and logs	Functions monitored and error records reviewed	How will a failed form or integration be detected?
Performance	Pages, tools and comparison method	Are results recorded before and after a change?
Content support	Included change types or allowance	How is a new page distinguished from a text edit?
Support channel	Email, phone, messaging or ticketing system	Which channel creates the official request?
Service targets	If applicable, priority, initial response and resolution targets	When does the target clock start, pause or stop?
Third parties	Hosting, licences, APIs and external-service responsibilities	Who handles a provider-side change?
Reporting	Task, date, result and unresolved item	What record is shared at the end of the period?

“Backups are taken” is not a complete operational definition. The CISA StopRansomware Guide recommends regularly testing backup procedures and checking the availability and integrity of backups in a recovery scenario. This does not establish one universal backup frequency. It supports defining frequency, retention and restoration procedures according to the system's risks.

Three post-launch request types: defect support, maintenance and new development — Classifying post-launch requests into three primary scopes.

A Post-Launch Request Classification Table

For every request, record the following:

What is the request or problem?
Does it have a direct counterpart in the approved delivery scope?
What was the expected behaviour, and what happened instead?
Is the source a project defect, recurring operation, client change or third party?
Is it free defect support, maintenance, new development or third-party work?
Which party is responsible?
What information or access is required?
Are there any service targets and exceptions?
Is there an additional cost or external dependency?
Where will completion and client acceptance be recorded?

Example request	Likely category	Reason
A delivered form cannot submit because of a project defect	Free defect support	An approved function does not behave as expected
A new dealer application and approval flow is requested	New development	It expands the approved scope
Planned software and security updates are required	Maintenance	Recurring preventive work is needed
An external service changed its API	Third-party-related work	Impact and adaptation scope need separate assessment
A phone number and image need changing	Maintenance/content support/separate work	The content allowance in the plan determines the category

These are illustrative decision scenarios, not real client cases. The final category depends on the approved scope and agreement for the project.

Five Short Decision Scenarios

1. A form has never worked correctly

If an approved form cannot create a submission because of a defect in the delivered project, it may be investigated under free support. If the cause is a client-side mailbox change or a new rule introduced by an external email provider, responsibility must be assessed separately.

2. A new page is requested

Correcting a sentence on an existing page is not the same as producing a page with a new layout, template and form. A maintenance plan may include a limited amount of content support, while new-page production may be separate development.

3. A security update is required

The update itself is only one part of the task. Compatibility, testing and the rollback approach should also be considered. Because updates are recurring lifecycle work, they may be included in maintenance.

4. An integration provider changes its service

A change made by an external payment, mapping, email, SMS or API provider is not automatically a project defect. The affected function, new requirement, testing work and provider fees should be assessed separately.

5. The website becomes slower over time

The cause should be identified first. Newly uploaded oversized images, increasing data volume, server resources, third-party code and application changes can create different responsibilities. “The site is slow” alone does not establish a free-support obligation.

How Should Client, Agency and Third-Party Responsibilities Be Divided?

A maintenance plan does not mean that every responsibility belongs to the agency. The client may need an authorised owner for content accuracy, user access and request approval. The agency performs the technical checks, updates or development work included in the agreement. Hosting, licence, email or API providers remain responsible for the terms and operation of their own services.

For each maintenance item, identify:

Who performs the work
Who supplies the required information or access
Who accepts the outcome
Which third-party dependency is involved

This division should be considered alongside source-code, data and account ownership. The off-the-shelf versus custom web software guide explains how control and maintenance responsibility can change between delivery models.

How Should You Prepare Before Free Support Ends?

Do not wait until the free-support period has ended to discuss maintenance. Define the basic ownership model during handover, then use the support history to refine the plan before month six:

Group support requests by subject and source.
Identify recurring form, content, integration and performance needs.
List the owners of software components and external services.
Assess which backup, update, security and functional checks the project needs.
Define the task, frequency, owner, channel, target and exception fields.
Move new-development requests into a separate roadmap.
Add domains, hosting, licences and external-service renewals to the budget.

To separate initial build costs, renewals, maintenance and future development over a longer horizon, use the three-year website cost template.

Red Flags in a Maintenance Proposal

“Unlimited support” is promised without defining the subject or official channel.
“Regular backups” are listed without frequency, retention or restore checks.
Initial response and resolution time are treated as the same thing.
New development and defect correction are combined into one vague service.
Responsibility for third-party service changes is not stated.
Update testing and rollback are not addressed.
Accounts and access remain solely under the provider's control.
Maintenance tasks are completed without a dated result record.
Security, speed or uninterrupted operation is guaranteed without scope and conditions.

When assessing a provider, review its technical process and handover approach as well as its service list. The web software company technical capability guide provides an additional evaluation framework.

Conclusion: Define the Boundary Before the Duration

Free support is the defect-correction period for making the delivered scope behave as agreed. Annual or monthly maintenance organises recurring work needed to keep a live website current and manageable. New development changes or expands the approved scope.

Do not classify these areas as “small” or “large” tasks. Use the approved scope, source of the issue, operational frequency, third-party dependency and expected outcome. A maintenance plan should state the task, frequency, responsible party, official request channel, any service target, exceptions and completion record.

Kumsal Ajans can plan annual maintenance after the first six months of free defect support for corporate websites. Custom web software can instead use monthly or project-based maintenance according to its needs. To review the post-launch responsibilities and maintenance scope for your project, visit the Kumsal Ajans web software service page.

Frequently Asked Questions

When does the six-month free support period begin?

Unless the proposal or contract states otherwise, it begins on the go-live or final handover date. The start and end dates should be recorded in the handover documentation.

Does free support include new feature development?

No. New features, modules, integrations, design changes and scope expansions are assessed separately from free defect support.

Are website maintenance and technical support the same service?

Not always. Technical support responds to a problem or usage request. Maintenance may include recurring planned work such as updates, security reviews, backups and functional checks. The exact boundary should be written into the agreement.

What should an annual website maintenance plan include?

There is no universal package. Depending on the project, it may include software updates, security checks, backups, performance reviews, form and integration testing, content support and reporting. The owner and frequency of each task should be defined.

Who is responsible for work caused by a third-party service change?

A change made by an external provider is not automatically a project defect. Impact assessment, adaptation, testing and provider fees are handled according to the responsibilities defined in the proposal or contract.

Should maintenance be planned before free support ends?

Yes. Reviewing support requests, components, external services and recurring operational needs before month six helps prevent an ownership gap after free support ends.