Support & Maintenance

Yes.

Post-launch support can be provided depending on the needs of the project.

This may include:

• bug fixes

• software updates

• technical troubleshooting

• performance checks

• security-related maintenance

• integration support

• small improvements

• ongoing development

Not every project requires the same level of support, so the appropriate arrangement depends on how important the website or software is to daily business operations.

Not necessarily.

A small, stable website may only need periodic updates, backups, monitoring and occasional technical support.

A larger e-commerce store, SaaS product or business-critical application may justify more continuous maintenance because downtime or technical failures can have a greater operational impact.

We do not believe every client should automatically be placed on a monthly contract.

Ongoing support should exist when it provides real value.

Maintenance can include different services depending on the project.

Typical responsibilities may include:

• software and dependency updates

• backups

• uptime monitoring

• security-related maintenance

• performance checks

• technical SEO health checks

• fixing broken functionality

• monitoring important integrations

• troubleshooting errors

The exact scope should always be defined clearly so both sides understand what is included.

Usually not.

Maintenance is primarily about keeping the existing system healthy, secure and functional.

New functionality such as:

• new modules

• major integrations

• new user workflows

• significant design changes

• large new sections

• major platform changes

is normally treated as development work rather than routine maintenance.

Small technical adjustments may sometimes be included depending on the support agreement, but the boundaries should be clear from the beginning.

Backup responsibility depends on the hosting environment and support arrangement.

Where backups are part of the maintenance scope, they may include:

• application files

• databases

• uploaded media

• configuration where appropriate

The required frequency depends on how often the system changes.

A mostly static website does not have the same backup requirements as an active e-commerce store or application receiving new data throughout the day.

A backup strategy should also consider whether the data can actually be restored when needed.

Yes, in many cases.

Before taking responsibility for an existing project, we first need to review its technical condition.

This may include:

• code quality

• framework or CMS version

• dependencies

• hosting setup

• deployment process

• database structure

• integrations

• documentation

• known issues

If the existing system is reasonably maintainable, we can often take over support without rebuilding it.

If serious technical problems exist, we will explain them before agreeing to an ongoing maintenance responsibility.

Response time depends on the support arrangement and the severity of the issue.

A critical production problem affecting sales or core business operations should not be treated the same as a minor visual adjustment.

Support agreements may therefore distinguish between issues such as:

• critical outages

• major functionality failures

• normal technical problems

• low-priority improvements

Expected response times should be agreed in advance when guaranteed availability or priority support is required.

This avoids vague promises such as “24/7 support” without a clear definition of what that actually means.