Why off-ramp.
In aviation, an off-ramp is the exit from the runway. The plane has already landed, the gear is working, the speed is dropping, but it isn't at the gate yet. It's moving along a special lane that leads from the runway to the terminal. A transitional state that looks like "no longer flight" but isn't yet "full stop."
In the studio we use this word for the period between the moment a site goes to production and the moment the client fully owns it themselves. In our experience, that period is three months. Not three weeks. Not one month. Three.
Most studios end a project on the day of the DNS switch. They sign the acceptance form, send the last invoice, wish good luck. That's formally correct — and almost always bad for the client. A site without support in the first three months is a site that starts to fall apart before anyone notices.
Three weeks of dense support.
The first three weeks are the densest. What's included:
- Reading 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. A few are bugs we missed on staging because they only fire under real traffic.
- Lighthouse measurements on Mondays. Real traffic changes performance numbers in ways CI won't predict. Images that were optimized on staging may be swapped out by an editor in production. The CDN behaves differently. We rerun Lighthouse once a week and fix anything that dropped below 95.
- Two sessions with the editors. One session happened during handoff, but that was a rehearsal. The real sessions are when the editor has already tried to publish their first piece and hit specific questions. These sessions are ten times more useful than practice on test content.
- Copy edits. In almost every project a list of fifteen to twenty small fixes 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.
- Form monitoring. If the site has forms (briefs, feedback, subscriptions), we get a notification for every submit in the first three weeks. It means we're the first to see if a form breaks; and second, we see how many real people pass through it.
Three months on call.
After three weeks of dense support, the second period begins — three months "on call." During these three months the client can write to us in a shared chat (Telegram, Slack — their choice), and we answer within the business day. Free.
What's included: questions, small fixes, content consultations, help configuring analytics, discussing "how best to lay out a new section." All of it a dialogue, not a contract.
What's not included: new features (say, adding multilingual support), large redesigns (say, reworking the home page), content work (writing copy, retouching photos), integrations with new services. Those are separate mini-projects we're happy to take, but not "as a favor."
The boundary is simple: if something takes minutes or a few short hours, we do it without invoicing. If it takes days, it's other work, and we scope it separately.
Why so long.
A site without support is unfinished. Not in the sense of "we didn't finish the code," but in the sense of "we haven't brought it to a state where the client operates it independently."
In the third week, errors surface that are impossible to catch on staging. They're tied to real traffic, real forms, real editors, real load. In the third month the client asks questions they didn't ask at handoff — because at handoff they hadn't yet realized what they actually want.
These three months are the period during which the site turns from "our product" into "the client's product." Without this period the transition doesn't happen. The client thinks they own the site, but is actually afraid to touch it.
Release isn't the finish. It's the first day of operation.
What comes after.
After three months the client owns the code, the documentation, the design system, the access themselves. We stay in the address book, but not in the chat every day. Contact — by occasion.
If a client needs a permanent maintaining developer (because the business is growing and the site regularly needs work), we recommend people from our network. This isn't subcontracting through us — it's a direct link between the client and the developer, and we have no financial interest in it. We simply know who does good work.
Most of our clients manage on their own. A modern stack (Next.js, Payload, Tailwind) is built so that a client's team can have one or two mid-level developers who calmly run the site for several years. We build the site for this reality — not for "you'll always depend on us."
Why free.
Three months of support are built into the project's cost. It's not a "bonus" and not a "promotion." It's part of the product.
Formally we could invoice separately for support, on average 80–150 thousand rubles a month. But we know that at handoff the client thinks "finally, it's over," and an extra invoice feels like "a con at the last moment." Better to account for it in the total price and take it out of the negotiation.
Besides, post-release support is in our interest. A site that lags in six months is a bad portfolio. A site that works perfectly in six months is a new referral from the client. We pay for support out of future revenue, not current margin.
What we don't do.
We don't do a "monthly retainer" after release. That format — a fixed sum per month for everything — usually turns into either "the studio does little, the client feels awkward complaining," or "the studio does a lot, but on credit, and in four months the retainer multiplies."
We don't do "an SLA in hours." If something important goes down, we respond fast, because we don't like a broken site either. If something unimportant — we answer within the day. Guaranteeing a response in 30 minutes twenty-four hours a day is a different profession, and it needs different people.
We don't do "extend support as needed." If after three months it's clear the client needs a regular developer, hire a dedicated one. We'll help you choose. Studio support is a transitional period, not a permanent state.