Constantin Potapov
I put the model where a person repeats the same operation by hand every day.
We write the success metric down before the work starts.In three months we check against it.
16 years of backend in production · Python · FastAPI · Django · PostgreSQL · Redis
Some get paid when projects ship. I get paid when they live.
A pilot built to be shown is not a system. It is a slide deck that learned to reply.
And I will not quote you a savings percentage before I have looked at the system. A number invented before the diagnostic is marketing, not an estimate.
I look for the place where a person already repeats one action and where the result can be checked objectively. If there is no such place, I say so and decline. That is cheaper than finding out two months in.
Not «it feels better», but a number: requests per hour, the share that still goes to a human, cost per month. Written down before I write the first line of code.
The model is the smaller part of the work. The rest: queues, retries, cache, monitoring, behaviour when the provider goes down. So the system survives load and my departure.
Code, documentation, a dashboard with the metric. What to do when quality drifts is written down too.
My client cases are under NDA and cannot be shown. What can be shown is the systems I built myself: you can open them and poke around, unlike a wall of logos.
A live EdTech product on its own domain: content generation and mock interviews via OpenRouter, with validation of what the model returned. FastAPI, async SQLAlchemy, PostgreSQL, Redis.
The character has motives and concession thresholds you do not know in advance. 78 scenarios, six scoring scales, voice or text replies, a report quoting your own words. FastAPI, Celery, OpenRouter, TTS.
The AI author argues in the thread and edits code in response to your comments. Nine languages, 130+ scenarios, weighted scoring: a missed blocker costs more than a missed nit.
An agent looks for signals, the system demands evidence for each one, a human decides who to contact. Exactly the architecture I sell: agent, validation, human fallback. Closed beta.
Five years as lead Python developer at PVS-Studio: the main site and around twenty related projects.
The boring part. Also the reason an AI pipeline does not fall apart in week three.
More about meAn agency brings a strong engineer to the pre-sale call and hands the work to whoever is free. Here there is nobody to bring.
An agency profits when the work takes longer. I profit when the pipeline works and you come back with the next task.
An agency will not tell you «do not build this» — it has a team to keep busy. My no costs me one project, not five people idling.
Code, documentation, a dashboard with the metric. Not generosity: a single contractor is a risk, and the only thing that covers it is what was written down.
What I do not have is people to swap in. If the task needs five engineers at once or round-the-clock on-call, you need an agency. That is not modesty, it is the right advice.
90 000 ₽
5 working days
I look at what gets done by hand, where the model fits and where it does not. You get a written analysis, the metric I propose to measure, and an estimate in money and time. «Do not build this» is also a result of the diagnostic, and you will get it if it is the right one.
from 350 000 ₽
4–8 weeks
A working pipeline inside your backend: code, deploy, monitoring, a dashboard with the metric. Fixed price, quoted after the diagnostic.
from 250 000 ₽
per month
The system keeps living: I watch quality and token cost, fix drift, extend it. For teams without their own person for this.
I do not bill by the hour.
If nobody does this work by hand yet, there is nothing to automate. First you need to know what should happen at all.
«It feels more modern» is not a metric. Without one I cannot prove I did the work, and you cannot prove you paid for something.
Not because it is hard, but because then I cannot guarantee anything.
Different budget and a different team.
When synchronous calls strangle your system, how to implement events painlessly, Kafka vs RabbitMQ in practice, and why eventual consistency is a conscious choice. Typical production cases with metrics and a breakdown of all EDA pitfalls.
The events table grew to 400 GB. Indexes did not save it. Partitions did in three hours what we should have done six months earlier. Then JSONB, RLS, advisory locks, and the rest I actually use.
Count money under load: k6 as code, SLA thresholds, and a report after which nobody can say 'optimize the database'.
Three things in the email: which operation repeats, how many times a day, and who does it. That is enough for me to say whether a model fits there. No deck required. I sign an NDA before the detailed conversation.