Health signals
Identify useful availability, error or journey signals and decide who receives and acts on them.
- Monitoring assessment
- Alert ownership
- Critical journey checks
Audit / Maintain / Improve
Care with clear edges.
Maintenance works best when the product is understood, responsibilities are visible and coverage is written down. Hich Web begins with an onboarding audit, then proposes care around the actual website or application.
Care / Operating loopAgreed coverage
01 / KnowAudit
02 / NoticeObserve
03 / ActMaintain
04 / LearnImprove
01 / BaselineAudit first
02 / BoundaryCoverage written
03 / OwnershipRoles visible
04 / ProgressBacklog prioritized
Maintenance, defined
Ongoing website care based on an audited product and an explicit agreement.
Hich Web maintenance can cover selected monitoring, updates, recovery planning, issue handling, content assistance, performance review and improvement. The exact platforms, environments, hours, frequencies, targets and exclusions are agreed only after onboarding.
01 / Possible coverage
Care shaped around what exists.
These are coverage areas to assess, not a universal package. The onboarding audit determines what is technically feasible, what is important and who owns each responsibility.
Update review
Review relevant software or dependency changes, their risk and an appropriate path through testing and release.
- Dependency inventory
- Compatibility review
- Agreed release path
Recovery planning
Clarify backup ownership, retention needs, restoration access and how recovery would be checked.
- Existing backup audit
- Recovery responsibilities
- Restore-test planning
Issue handling
Give reported problems enough context to reproduce, prioritize, resolve and document the next action.
- Request intake
- Impact assessment
- Resolution notes
Content care
Where agreed, support structured content changes while protecting layout, accessibility and editorial consistency.
- Content requests
- Page-level changes
- Editorial checks
Improvement
Turn observed friction, performance findings and business changes into a prioritized, separately understood backlog.
- Performance review
- UX observations
- Improvement backlog
02 / Onboarding audit
Understand before taking responsibility.
A support relationship should not begin with assumptions. The audit establishes the technical baseline, ownership, immediate risk and whether Hich Web can responsibly accept the requested coverage.
| Audit area | What is reviewed | What must become clear |
|---|---|---|
| Ownership & access | Domain, hosting, repositories, administration, analytics and external accounts | Who owns each account, who may grant access and what credentials are available? |
| Technical baseline | Architecture, software versions, dependencies, environments and deployment path | Can the product be changed and released responsibly with the available information? |
| Current health | Known errors, critical journeys, performance concerns and unfinished work | Which issues predate support, and which need stabilization before normal care? |
| Data & continuity | Data stores, existing backups, retention, restoration access and external dependencies | What could be lost, what recovery is available and who is responsible? |
| Business criticality | Important user journeys, operating hours, campaign periods and business impact | How should priorities be defined for this specific product? |
| Request model | Authorized contacts, communication path, approvals, content ownership and release decisions | Who can request, approve and verify work? |
03 / Coverage agreement
Define the promise. Define the limits.
The audit informs a written support model. It should make expectations testable without suggesting that all failures, vendors or changes are under one party's control.
Covered work
List maintained properties, environments, activities, request types and any planned review work.
Impact levels
Define priority using the actual business and user impact, with evidence needed when reporting an issue.
Communication
State authorized contacts, request channels, service hours and any agreed response or update targets.
Responsibilities
Record exclusions, external providers, account ownership, approvals and work that needs separate scope.
04 / Care cycle
A repeatable route from signal to learning.
The exact cadence and activities depend on the agreement. The operating model keeps evidence, decisions and follow-up connected.
Audit the product
Establish ownership, access, technical baseline, existing issues, continuity needs and business context.
Set coverage
Document properties, included work, priorities, communication, responsibilities, targets and exclusions.
Address the baseline
Where separately agreed, resolve priority findings that would otherwise make ongoing care unreliable.
Handle agreed work
Review signals and requests, assess impact, test appropriate changes and keep useful resolution context.
Prioritize next
Use findings, repeated issues and changing goals to maintain a visible improvement backlog.
05 / Care planner
Prepare an onboarding conversation.
Select the areas that appear relevant. Hich Web will confirm feasibility and coverage only after reviewing the actual product, access and dependencies.
06 / Useful answers
Clear expectations before support.
The audit and written agreement are the source of truth for coverage, targets, responsibilities and exclusions.
Can Hich Web maintain a website built by another provider?
Potentially. Hich Web first audits the codebase or platform, hosting environment, access, dependencies, documentation, known issues and ownership. Support is offered only when the product can be taken on responsibly and the required access and boundaries can be agreed.
What is included in a maintenance agreement?
Coverage is defined after onboarding. It may include selected monitoring, update review, backup and recovery checks, issue handling, content assistance, performance review or planned improvements. Anything not listed in the written coverage should not be assumed to be included.
Does Hich Web promise an uptime level or fixed response time?
No universal uptime or response promise applies to every product. Service hours, priority definitions, communication routes, response targets, dependencies and exclusions must be agreed for the specific environment and recorded in the support terms.
How often will backups be made?
Backup frequency, retention, storage responsibility and restoration testing are chosen after the product, hosting environment, data change rate and recovery need are understood. Existing provider backups are verified rather than assumed.
Does maintenance guarantee that a website cannot be hacked or fail?
No. No provider can guarantee that a website will never be attacked, compromised or unavailable. Maintenance can reduce avoidable risk through agreed updates, access practices, monitoring, backups and response planning, while responsibilities and third-party dependencies remain explicit.
Are content changes and new features included?
Only when the agreement says so. Small content or configuration requests may follow an agreed request process. New functionality, redesigns or work outside the maintained product are assessed and scoped separately.
Is hosting included with maintenance?
Hosting is not automatically included. The onboarding audit identifies the hosting owner, provider, access, renewal responsibility and technical limits. Any hosting or infrastructure responsibility must be stated separately in the agreement.
07 / Related services
Care, improve or reconnect.
An audit may reveal that the useful next step is a focused redesign, search improvement or integration project rather than recurring maintenance alone.
Need dependable ownership around an existing product?