The screenshot.
It happens every time. The DNS record switches at 10:00 Moscow time. Lighthouse gives five greens. Someone in the studio takes a screenshot of the top of the screen. Someone at the client's does the same. By 10:30 the congratulatory image is in three work chats, and by lunch — a LinkedIn post captioned "proud to present…"
We have nothing against this ritual. We went through it ourselves on the first two or three projects. A screenshot at the moment of release is an emotional punctuation the team needs after three months of work.
But somewhere around the fourth or fifth launch we noticed: the photo is always taken at the worst moment. When the site has been up for forty minutes and nobody has used it yet. When no form has been submitted by a real person. When no email notifier has fired in live mode. When no editor has published a single edit.
That photo doesn't show the site. It shows the design lying in a browser. Those are different things.
Three weeks of silence.
In our practice, three weeks pass between the moment of release and the moment we publish the case study. It isn't a random number — it's the period during which the site turns from "the design we handed over" into "the site that works."
In those three weeks we:
- don't publish a launch post on our social media,
- don't write a case study on the site,
- don't send a press release (if one is even needed),
- don't submit the work to industry awards,
- don't tell new prospective clients about the project.
What we do — answer emails and look at logs. That's all.
For the studio's marketing side, this is a period of silence. For the engineering side, it's the densest period of the project, alongside the first two weeks of development.
What fills the silence.
What we do in those three weeks:
We read the logs every day. Every endpoint that returned a 4xx or 5xx in the first 72 hours is read by a person. Most are bots scanning a new domain. A few are bugs we missed on staging because they only fire under real traffic. Those bugs are the most valuable finds of the whole project, because they show exactly what's wrong in our model of the site.
We run Lighthouse once a week. Real traffic changes performance numbers in ways CI won't predict. Images optimized on staging may be swapped by an editor in production. The CDN behaves differently under load. We rerun Lighthouse against production every Monday and fix anything that dropped below 95.
We train the editors on real content. A session held during handoff is a rehearsal. A session held a week after release, when the editor already has specific questions about specific materials, is ten times more useful. A Q&A with real questions is always more productive than practice "on dry runs."
We make small copy edits. In almost every project a list of twenty to thirty edits surfaces in the first week: a comma in the wrong place, a heading a line too long on a narrow screen, an image cropped not at its most flattering point. We do them silently and don't invoice. It's the part of the project impossible to catch in advance — because it's only visible in a live context.
We watch the forms. If the site has forms, we get a notification for every submit in the first three weeks. That gives two things: first, we're the first to see if a form breaks; second, we see how many real people pass through it. It's the first truth about whether the site works.
The site isn't one object.
The main reason we hold the pause is the understanding that a site isn't one thing but two at once.
The site is a design object: composition, typography, color, motion, hierarchy. This part is ready on launch day. It can be photographed, judged, submitted to an award.
The site is a piece of infrastructure: code on a server, a database, a CDN, caches, forms, integrations, task queues, monitoring. On launch day this part is an untested hypothesis. It hasn't yet carried real traffic, hasn't met a real editor, hasn't been on the wrong side of an outage.
A case-study photo taken in the first hour catches only the first half. The design object — yes, the infrastructure — no.
A site is two things at once. It's ready only when both are.
That's why we wait three weeks. In that time the infrastructure moves from "hypothesis" to "it works." Then we have the full picture — and then the case study can be published.
What the fourth week catches.
By the end of the third week we know everything about the site that couldn't be known on launch day:
- How many forms were submitted and what percentage converted into an inquiry to the client.
- Which pages turned out most visited, and whether that matches what we counted on in the design.
- Which micro-bugs surfaced only on real devices from real geographies.
- How the editors use the CMS — what's convenient for them, what isn't, what needs supplementing with documentation.
- How performance behaves under load — where there's headroom, where it's tight.
- What the client thinks not "at handoff," but after three weeks of real operation.
This data is far more honest than the impressions of the first hour. And it's this data that turns "a design in a browser" into "a site that works."
A case study written with this data reads differently. Not "here's a beautiful site," but "here's a site that, after three weeks, does X, Y, Z." That's the difference between a marketing piece and an engineering report.
Why it matters for the client.
The client also gains from the pause. For several reasons.
First, at the moment of release the client doesn't have enough data to judge the project's success. After three weeks — they do. A case study written with the client's involvement after the pause is a joint story about a working product. A case study written on launch day is a commercial statement the client may regret signing a week later.
Second, during this time the client focuses on operation, not PR. If a problem occurs in the first week (and in premium projects it almost always does), we solve it together — without noise, without public reputational loss, without having to "explain why the site we posted yesterday is down today."
Third, silence is a signal of calm. The client sees we're not rushing toward a PR effect; that it matters more to us how the site works than how it looks in a screenshot. It changes the relationship between studio and client — toward partnership rather than "contractor–customer."
What's wrong with noisy launches.
In the industry it's customary to celebrate a launch loudly. A LinkedIn post at 11 a.m. A press release. A video with the team. It works for the studio's portfolio — it grows reach, attracts new clients.
The downside of this approach is focus. In the first hours after release the team switches from the engineering task (watch, fix, repair) to the marketing one (answer comments, repost, prepare follow-ups). It's a mode switch, and it combines poorly with simultaneously monitoring production.
The second downside is premature commitment. A site published on LinkedIn as "here's our new launch" has had a public presentation, and now any edit feels like "a correction after criticism." That pressures the studio and the client — it forces them to defend decisions that could still have been adjusted.
The third downside is disagreement with reality. If a serious problem is discovered in three days (a slow server, a broken form, a missed SEO tag), it has to be solved against a backdrop of public celebration. It's a bad combination — a high-load task in an emotionally elevated state.
A footnote about confetti.
This doesn't mean we don't celebrate. We celebrate quietly, in person, with those who were in the room.
Usually there's a bottle of good wine someone brought. Usually there's a dog — a dog is sometimes in the studio. The confetti goes to the dog.
The client — no sooner than three weeks later. When the site we opened at 10:00 Moscow time actually works: forms submit, editors publish, Lighthouse holds at 95+, the logs are clean. Then we write to the client: "you can publish." And only then — the post, the case study, the award, the portfolio.
In a world where everyone rushes to the screenshot, slowness is a position in itself. Not the position "we're better than others." The position "we look at a site longer than others before calling it done."
It isn't ideology. It's an operational standard that's worked for us for two years and, as far as we can see, will keep working.