Daily diagnostics, backups, updates, fixes and a report — after launch.
Anyone after launch, whoever built the site.
Diagnostics at four in the morning, a backup at two, certificates renewed automatically, updates after testing and an agreed hour budget for changes. The work history lives in the task system, and you have access to it.
Our recommendation: the first three months included in the project, then voluntary. The promise "we stay after launch" should be true, not compulsory.
Daily diagnostics, a backup off the server, fixes, and a work history you have access to.
A script at four in the morning checks the disk, the containers, the certificates, backup freshness, container writable layers and the framework cache, and the result is graded OK, WARN, FIX or ASK. On top of that, an IP ban after a hundred failed logins and a restart for containers that died.
A backup daily at two: database dumps plus an incremental copy to external cloud storage, with 7 days, 4 weeks, 6 months and 2 years of retention.
Why this is not empty. On 12 August the disk hit 100 percent and five services stopped. The repair went through without site downtime, and the lessons went into three places: the diagnostics script, the project canon and the documentation. That is what care that learns something looks like.
What you getDiagnostics, the first analysis of an incident, preparing a fix.
Deciding what is an outage and what is noise, and writing the lesson into the procedure so it does not come back.
Private project: We do not promise an SLA with response times in minutes or 99.9 percent uptime. This is one server and one person. The honest promise: a reply within one business day, a backup off the server, a known restore procedure.
A cookieless visitor counter — so no consent banner — on our server, with access for you.
Custom events (a discount code clicked, a form sent) and a monthly report that answers "where did they come from and what did they do", not "how many page views were there".
Where it stands today: our own instance, five registered domains, the script wired into four sites, traffic confirmed on three.
What you getA draft report and spotting anomalies in the traffic.
Wiring the counter, defining the events and interpreting the numbers.
Private project: The analytics panel is private, so the proof is a screenshot on a call, not an address.
Speed work measured with a tool, with a record of what helped and what did not.
Measured with the same engine as PageSpeed, locally, with the flags that cut out the browser artefact on a Mac — without them first paint lands about 1.5 s later and the whole analysis is fiction. A median of several runs, not one result, because a single run sits inside the tool’s own spread.
A result from a real project: mobile 81 → median 91 (spread 87–92), page weight 793 kB → 415 kB, fonts 166 kB → 105 kB and 10 files → 5, accessibility 96 → 100 on mobile and 92 → 100 on desktop.
What you getA first optimisation pass and spotting the obvious losses.
Measurement that tells the truth, and rejecting changes that only look good on paper. One such "57 kB saving" produced CLS 0.22 and minus 11 points — reverted.
A site audit, a code audit after "vibe coding", model evaluation, or market analysis before you build.
Site audit: performance measured as a median, technical SEO, structured data, accessibility, form and header security. The result is a report ordered by payoff, plus what to reject and why.
The code audit after "vibe coding" is the most current service of 2026. We look for exactly the things that happened to us: caches with no boundary, data that passes validation and still makes no sense, no limits towards external APIs, secrets in the repository, no healthcheck, logs writing the same line thousands of times.
Market analysis before building: does the idea hold, who already does it, what does it cost, what can go wrong. We have two such documents and both of them stopped a build until the assumptions were validated.
What you getReviewing the code and the content, a first pass of the report.
Recognising the errors of meaning and operation that syntax never shows, and setting priorities honestly.
No. This is one server and one person. The honest promise is a reply within one business day, a backup off the server and a known restore procedure — not 99.9 percent uptime.
We start with an audit, because without one care is guesswork. After the audit it is clear what needs fixing before we take it over.
We estimate in hours, after a phone call and a look at the project. Our latest projects took 15 to 45 hours.
