Any director who buys software development knows the routine. Every idea turns into an invoice, and whether it worked gets sorted out later, after the money is gone. On the Certificate Analytics platform the routine is different. Dozens of orders have come through us over the years: shipped, shelved, rejected. This case isn’t about one product. It’s about how the call “build it, skip it, or test it first” gets made, and how we help the client work out whether an idea is worth its cost before the first invoice. Enough episodes have piled up to show the method on facts rather than slogans.
Snapshot
| Sector | Product certification, B2B market analytics |
| End client | Certificate Analytics |
| Engagement | Retainer support: a stream of orders, each one priced and signed off |
| Project type | The studio’s way of working: prototype before the invoice, economics modelled, help with the choice, an honest status |
| What we show | Nine documented episodes from the project history where the “build / skip / test first” call was made together with the client |
| Period | October 2021 to today |
| Effort | Not reported: this case is about the approach, not the size of one task |
| Team | Anton Hersun (project lead, estimates and prototypes) and the analytics-panel developer who has run this track since day one |
| Status | Engagement ongoing, order stream open |
A method instead of a price list
When a task is voiced for the first time, we don’t reach for the calculator. First, three questions. Is the idea technically viable? Do the economics work for the client? And can we test the idea cheaply before committing to all of it? The talk about cost and timelines starts after the answers, not before.
Below are the four moves the method is built from, with a real episode for each.
A prototype on our own dime, before we propose a big spend
The most expensive mistake in custom development is paying for the full build of an idea that won’t fly in practice. So we try to feel out the big ideas with a prototype before any talk of budget.
In June 2024 the client’s interest in artificial intelligence was only forming (“somehow get AI into the work”), and we built a working prototype on our own initiative. In one evening an AI analyst went up on the server, taking natural-language queries against the certificate database. The client got a short message: “Launched an AI prototype on the server,” plus a login, a password, and example queries. Access was free, for testing and shakedown. When they wanted to show the prototype to partners, we kept it alive, then shut it down honestly “so it stops eating resources.”
The prototype exposed both the real cost of the idea and its weak spots at once: the model confused the comparison operator, fine-tuning on niche questions was still ahead, and a server database for this carries serious cost. The client felt all of that firsthand instead of hearing it from us in words. The big order was never placed, but the client made that call looking at a working thing. (The AI-analyst prototype itself is covered in a separate case.)
The same move worked in 2026 on a pricing system for Bitrix24. We parsed the data from the client’s export, built a prototype on our own infrastructure, and handed over a link with a short request: see how it works, write back what to add, what to drop, whether the layout suits you. We stated the logic plainly: “I’ll collect your wishes and feed them into the prototype. Once the prototype is approved, we do the final estimate.” The prototype suited them, and only then did we move to a full estimate.
The “full or demo” split as a third option
Between “build the whole thing” and “build nothing” there is almost always a third path: test the idea on a trimmed scope. We try to put it on the table explicitly.
When a Telegram bot for quick answers to managers came up in 2022, we prepared not one quote but two: a full version and a demo. The demo dropped the most expensive stage entirely (linguistic parsing of queries) and the link to the technical department, leaving a minimal dialog on a single account. The point of the split: for a smaller scope, the client tests the mechanics before committing to the full build. The bot never reached a production launch, sign-off stalled on the client’s side, but the choice was a deliberate one, with a clear line between “try it” and “build it properly.” (Details on the bot are in a separate case.)
Helping model the economics, and the right to say “we won’t build this”
Sometimes the most useful thing a contractor can do for a client is help them drop an idea before it eats the money.
In spring 2026, on that same pricing system, we took the prototype to the point where the client could model the economics together with partners. The partners’ verdict came back negative, and the client put it plainly: for us alone the project comes out too costly, at list price it’s a stop. What matters here isn’t the stop itself but that there was something to count with: the prototype and the estimate were already on the table. We immediately offered a path that keeps the project alive: finish it on our own dime and fold the cost into the monthly retainer, especially since a system like this could serve others too. The decision stayed with the client.
The same honesty runs the other way, when the economics fail in front of us before any quote. On one of the document-builder changes, the client wanted the test dates to recalculate automatically when the main date changed. We didn’t even write it into a spec: “looks like a small thing, but in the build it costs like a Ferrari.” New tags, links between them, accounting for public holidays: roughly 30 hours of work for a convenience that wasn’t worth it. We talked them out of it.
Not charging for something that won’t survive
The clearest episode involves document-status checking. By 2025 the talk was about bulk reconciliation of statuses across more than a hundred thousand declarations. The client was ready to write the spec and pay, but we put on the brakes ourselves: there was one path to see it work, building a test rig with multi-threaded parsing through proxies and watching for a week or two whether it survived on the full document volume. We held the principle straight:
If we see signs of viability, we’ll continue with the spec. If we don’t, we won’t write it up and charge for something that lives a week and dies.
We wrote no spec and issued no invoice until there was confidence the product would outlive its own launch.
In the same category sits a diagnosis that saved the client a server purchase. Registry search was slow for users, and the obvious reaction suggested itself: add more hardware. We dug into the cause first. People were searching the OGRN registration number with a “contains” parameter, and that search skips the index: the database scans rows one by one, checking for a substring in each. The same query with an “equals” parameter leans on the index and ran in a millisecond. We put the conclusion plainly: the issue isn’t capacity and isn’t a new server, fixing what we found is enough. No server had to be bought.
The same bucket holds a refusal to batch-convert documents to PDF. The idea came from the client, but the conversion produced page-numbering glitches, and this is a document a manager forwards into work without a second look. We offered to run a dozen files as a test, and the client backed out on their own: if glitches show up already, there’s no point. We don’t take on work that ruins the result.
An honest status: what’s a real task and what’s just a setting
The method works on small things too. Once the client took “issuing fresh numbers” for a paid change, when in fact one lab simply hadn’t ticked the box for using dates during booking. We wrote back exactly that: go into the templates section, set the flag, save. A setting, not a task, and no invoice appeared for it.
The flip side of that same honesty is owning risk on our side. On one of the parsing-improvement orders the estimate was about 56 hours, and it actually came to 156: the first collection method turned out to be a dead end, and we had to rebuild it. The reaction was short: “those are my risks, let’s look at the result overall.” The estimate was given in fixed hours, so the overrun stayed with the contractor instead of landing on the client.
What the client gets out of this
| What | How it looks in practice |
|---|---|
| A prototype before a big spend | The AI analyst and the pricing system were built and handed over for testing before any talk of a full budget |
| A split instead of “all or nothing” | For the Telegram bot, two estimates were prepared, full and demo, with a clear boundary |
| Help modelling the economics | On the pricing system the client and partners costed it and decided not to build, with the prototype and the numbers in hand |
| Protection from wasted spend | We talked them out of auto-recalculating dates (“costs like a Ferrari”), out of buying a server (it was the search operator), out of PDF conversion |
| An honest status on every task | “Fresh numbers” turned out to be a setting and never became a paid task; the parsing overrun was logged as the contractor’s risk |
Team
- Anton Hersun, Xaver Pro — project lead. Prototypes, fixed-hour estimates, diagnosis, the talk with the client about economics and priorities.
- analytics-panel developer — has run this track from day one to today. Any module written years ago is reworked by the same person, so the “build or skip” call rests on knowing the whole system rather than on guesses.
Screenshots and materials
Not applicable: this case is about a way of working, with no separate product interface of its own.
If you have an idea you’re not sure about, and you don’t want to pay for a full build blind, show it to us. We’ll say honestly whether it’s technically viable, how to test it with a minimal prototype, and where the economics might not add up. The first estimate is free.