Example health check · fictional SaaS service

What does a technical health check look like in practice?

This example shows the report structure, areas reviewed, and level of detail in the findings. The system and findings are fictional and are not based on client material.

Book a free scoping call Back to the service description

Example starting point and scope

The fictional Client Portal is a B2B SaaS service that has been in production for five years. Development has slowed, releases feel risky, and management needs to decide whether to improve the current system or renew the architecture.

Technology: React, Node.js, PostgreSQL, and AWS
Material: 2 code repositories, documentation, and read-only production access
Work: Scoping call, material review, verification of findings, and results meeting
Delivery time: 5 working days from the agreed start date

What does the review cover?

The emphasis is agreed based on the system and the decision to be made. Not everything receives equal weight: the report focuses on findings with a practical impact on risk, delivery speed, or cost.

Architecture and maintainability

We establish the system responsibilities, interfaces, data flows, and the impact radius of changes.

division of responsibilities between modules and services
consistency of interfaces and data models
coupling, monolithic risk areas, and unnecessary complexity
whether documentation matches the implementation

Code quality and testability

We assess how safely the system can be changed and how defects are detected before production.

fitness of tests and coverage of critical paths
error handling, validation, and edge cases
duplication, readability, and structures that are hard to change
reliability of the build, linting, and type checking

Dependencies and security signals

We identify risks visible in the supplied material without performing penetration testing or a legal audit.

outdated and known-vulnerable dependencies
handling of secrets, permissions, and sessions
input validation and common application-level risks
update process and ownership of dependencies

Delivery and production operations

We review whether the service can be built, released, observed, and recovered in a controlled way.

repeatability of CI/CD and manual release steps
logs, metrics, alerts, and incident diagnosis
backups, recovery exercises, and rollback procedures
management of environments, configuration, and infrastructure

Performance and cost signals

We highlight evident bottlenecks and structures that may increase cloud costs unnecessarily.

risk areas in database queries and external calls
basic caching and scaling choices
oversized resources, unused services, and cost limits
whether measurement data is sufficient for future decisions

Examples of report findings

Every finding includes evidence, practical impact, severity, and a recommended next action. The report also identifies sound choices that should not be changed without a reason.

High

Recovery from backup has not been tested

Observation: The database is backed up automatically, but the recovery procedure has not been documented or exercised.
Impact: In a serious incident, recovery time and the integrity of restored data cannot be predicted.
Recommendation: Run a recovery exercise into an isolated environment, name an owner, and verify the target recovery time.

High

The release has three manual production steps

Observation: A database change, environment-variable update, and service restart are performed from a separate instruction.
Impact: Release success depends on the operator’s memory, while rollback is slow and error-prone.
Recommendation: Move the steps into CI/CD, add a preflight check, and make restoring the previous version a single command.

Medium

A key reporting query scales with all historical data

Observation: The query loads all events into application memory before grouping them, and the timestamp used has no index.
Impact: Response time and memory use grow with the client base and may eventually limit use of the feature.
Recommendation: Move aggregation into the database, add an index based on the query plan, and measure latency with production-like data.

Sound choice

Business logic is separated from interfaces

Observation: Core rules live in dedicated modules and have fast unit tests.
Impact: New interfaces and integrations can be added without broadly changing the core rules.
Recommendation: Preserve the structure and extend the same pattern to two older modules instead of rewriting the entire system.

Example prioritised 90-day plan

Days 0–14 · reduce immediate risk

exercise database recovery and document the recovery procedure
automate critical manual release steps or add mandatory checks
add measurement and an alert for abnormal report-query latency

Days 15–45 · make delivery repeatable

move database changes and configuration validation into CI/CD
optimise the reporting query based on measurements and add a regression test
assign owners and minimum tests to critical user journeys

Days 46–90 · improve control

define service-level objectives and matching alerts
record architecture decisions and legacy structures to remove
introduce cost budgets and a monthly variance review

What does the client receive?

An executive summary covering the current state, highest risks, and recommended decision.
A technical finding register with evidence, impact, severity, and remediation proposal.
A prioritised 90-day action list for assigning ownership and planning work.
A 60-minute results meeting to review the findings and answer questions.
Immediate notification of a critical risk during the review — not only in the final report.

Would you like the same view of your own software?

We review the system, decision need, and available material in a free 30-minute call. Before ordering, you receive a written scope, agreed start date, and price.

Book a free scoping call