The Certificate Analytics platform lives on someone else’s data: it pulls records from the state registries of Russia, Kyrgyzstan, Kazakhstan, and Belarus. Those registries change structure regularly, bring in limits, block collection, move to new infrastructure. Let the parsing stall and within a week the analytics go stale, and with them the whole product loses value. The client framed the priority early and short: “the parser is the core.” The retainer is built around keeping that core from falling over. From the first spec in October 2021 to today, the platform has never once been left unwatched.
Snapshot
| Sector | Product certification, B2B market analytics |
| End client | Certificate Analytics |
| Engagement | Monthly retainer support: uninterrupted parsing, small changes, incident response, server protection, backups |
| Project type | Continuous support of an in-house B2B platform |
| Relationship length | October 2021 — June 2026 (4.5 years without a break) |
| What the retainer covers | Parsing uptime, accumulated small work, incident response, monitoring, a server-protection retainer, backups |
| Documented stream of small batches | About 90 hours across 6 spec add-on tasks (2022–2023), plus a stream of individual micro-fixes |
| Team | Anton Hersun (lead), analytics-panel developer, widgets-and-parsers developer, infrastructure team |
| Tech stack | Laravel + Horizon, ClickHouse, MySQL/MariaDB, proxy rotation, number enumeration, Grafana monitoring, S3 backups |
The problem
The big specs on this project are written up separately: the platform, reports, templates, widgets, database architecture. But alongside the large tasks a stream of small things always runs, the kind you can’t gather into a spec. A source registry changed its format, so the parser needs a fix overnight. A user asks for a button or a new sort order: an hour of work. An external portal admin wiped an integration by mistake, and the widget has to come back up at once. The server is under load, the disk is filling, time to bump the plan.
Write every one of those small things up as a separate order, and the overhead on documents and invoices eats more than the work itself. Pile them up silently and then bill “lots of bits and pieces, many hours” at month’s end, and the client stops trusting the estimate. The retainer closes both extremes: a predictable monthly subscription covers the background, and anything beyond it is logged in explicit hours.
The main thing the client buys on retainer is certainty. The parsing runs every day, and any failure gets closed fast, without a separate negotiation for each case.
How we did it
1. Parsing under constant watch. Over four and a half years the sources broke dozens of times, and almost every case was closed inside the retainer, with no separate spec. European proxies stopped allowing access to Russian registries, so we built a mini-farm of Russian servers. Kyrgyzstan closed its public registry, so we switched to collection by enumerating numbers from the last known ones. The federal service changed infrastructure and banned the parser machines, so the system was rewritten onto several machines running two threads with proxy rotation. Kazakhstan’s move to a new registry turned into collection from 46 sources, and the New Year blocks in Belarus were worked around through a working proxy with a later catch-up pass. The platform barely notices any of this: the patch lands before the data goes stale.
2. Small work piles up and closes as a batch. The retainer arrangement is simple: a single hour doesn’t turn into a separate invoice. In November 2025 the client asked for a small button worth an hour of work, and the call was this: “let’s wait a bit, something will turn up during the week, we can pool it all at the end of the period or do it against the prepaid balance.” That’s how the extra studiocracy goes away. At the same time, some small roles and changes close the same day: the “TO+ staff” mini-role was ready within a few hours of the request, and the June batch of add-on tasks was closed in a day.
3. The discipline of an explicit estimate where the volume grows. When the small work became a steady stream in 2022–2023, we wrote it up as monthly add-on-task batches: one document, specNN_addons_<month>_<year>, with numbered items and a single estimate. The _approved suffix in the filename means the version went through discussion and was locked. New requests go into the next batch. Six such batches gave about 90 approved hours, and not one dispute over the estimate. A side effect turned out to be useful: a recurring request type shows up at once and grows into a separate large track of its own. That’s what happened with parsing foreign registries.
4. Incident response in minutes and overnight. Response speed is the whole reason a retainer exists. An external portal admin accidentally wiped the widget integration and the client lost access to the admin panel, and full recovery took about twenty minutes from the first message. When the database “killed itself and recovered by a miracle” in the middle of an overnight collection, the parser was back up by morning, and the incident itself became the reason to move to a more powerful server. There were harder days too: after the server was infected with a trojan miner, the cleanup work ran three times over the planned time, and the client got a written incident report with a root-cause breakdown.
5. Load protection and cleaning up after users. Analysts were exporting reports of millions of rows and taking the server down with it. The answer stayed in the product for good: a daily auto-cleanup of exports older than 3 months plus a cap on export size. The same bucket holds server protection and maintenance on a separate retainer billed quarterly, external monitoring with alerts straight into the work chat, and backups that over the life of the project grew from a weekly database dump to FTP into a daily dump of the whole database to object storage.
Results
| Metric | Value |
|---|---|
| Length of unbroken support | 4.5 years (October 2021 — June 2026) |
| Parsing uptime | Dozens of format changes and source blocks closed inside the retainer, with no long product outages |
| Incident response speed | Widget restored in ~20 minutes; database back up overnight; written incident reports |
| Documented stream of small batches | ~90 hours across 6 spec add-on tasks, with no estimate disputes |
| Protection and durability | Server-protection retainer, export auto-cleanup and caps, backups from weekly to daily into S3 |
| Product alive in year 5 | 66–79 active users weekly (login statistics, spring 2026), even load, no sign of fade |
The main result doesn’t reduce to a single number. Over four and a half years the product was never left without support, the parsing survived every change of rules at the sources, and the client never once got a surprise invoice: the background is covered by the retainer, everything beyond it goes in explicit, approved hours.
Process and timeline
| Period | What the retainer covered |
|---|---|
| 2021–2022 | Start of support; weekly database backups; mini-farm of Russian servers after European proxies were blocked |
| 2022–2023 | Six monthly add-on-task batches (~90 h); server upgrades for the growing load |
| 2023 | Source banned the parser machines — a rewritten multi-threaded system, 100% period coverage |
| 2024 | Registries moved to enumeration collection; export auto-cleanup and caps after a server overload; adaptation to the sources’ infrastructure change |
| 2025 | Server-protection retainer (quarterly); external monitoring with alerts; widget restored in 20 minutes; database back up overnight; new Kazakhstan registry |
| 2025–2026 | Daily backups to S3; migration to a more powerful plan; New Year blocks worked around; collection rebuilt for the new Russian registry limits |
Team
- Anton Hersun, Xaver Pro — project lead, setting the retainer estimate, incident coordination, infrastructure.
- analytics-panel developer — runs this track from day one to today. Any module written years ago is reworked by the same person.
- widgets-and-parsers developer — closes small changes in his own zones. He has picked up some of the recent parsing work specifically.
- infrastructure team — servers, protection, monitoring, and backups under Anton’s lead.
The support principle is simple: whoever wrote the module closes the small things and incidents on it. The line-up by track hasn’t changed in years, so context never has to be handed over again with each request. For a retainer that is the core value: any request is taken up by someone who already knows that part of the system from the inside.
Screenshots and materials
Not critical for this case: the point is the support model and the continuity, not the visuals.
If your product has a “core” that must not fall over, a parser, an integration, an overnight data collection, and small work keeps running alongside that won’t add up into big specs, let’s talk. We’ll show you how to hold it under one retainer: a predictable background, explicit hours on top, and incident response in minutes. We don’t charge for the review.