Ani Petrinchik
Engineer with a growth brain.
I design AI systems and orchestrate the agents that run them — and own the backend underneath: data ingestion, payments, infrastructure. I came to code from growth, so every system answers to a user and a unit cost.
- AgentsNarrow roles, hard gates, a human signs off
- EconomicsEvery row goes to the cheapest model that can read it
- TrustThe server computes the price, not the client
what I own
I build AI systems as a team of agents, not one clever prompt.
Each agent gets one job and a written brief, hands work over through explicit contracts, and runs behind gates it cannot argue with: build-time checks, isolated branches, and a person’s sign-off before anything goes public. This site is maintained that way. how the fleet works →
Every row goes to the cheapest model that can read it.
Structured fields first, then deterministic matching, then a lightweight text model, and a vision model only as the last resort — each rung measured on a real sample before anyone pays for the next one. the model ladder →
In week one I turned a failing architecture into a system that ran itself.
The pipeline was supposed to need constant attention. I built it to recover on its own, surface only the alerts that mattered, and keep working while I watched. insights.fashion →
Official APIs and partner feeds instead of fragile workarounds.
Sanctioned sources land catalogs with prices, images and variants straight into Postgres, cost a fraction of anything heavier, and do not break when someone redesigns a page. the ingestion engine →
Every source earns its cost, and the cheapest route runs first.
Ingestion strategies run in order — official APIs, then partner feeds, then a manual queue — within each source’s terms and rate limits. A source that keeps failing switches itself off rather than spend the budget.
Before launch I tested the checkout the way a buyer might try to game it.
Every price rule moved to the server rather than staying in the interface, because a price rule that lives in the browser is a suggestion. the commerce backend →
Buyer data lives in the country that claims it, and never in the logs.
Two data-protection regimes, so residency decides the store, personal data stays off the shared analytics database, emails and phone numbers are masked in every log channel, access to a document is recorded, and erasure on request is a command rather than a promise. the security model →
Three languages, dir=rtl included — on zero extra servers.
A build step emits the localised pages, so a search engine or a shared link arrives in the right language before any JavaScript runs. agritech platform →
the systems
sketches
Not systems, and not presented as any. Each of these started as an idea I wanted to test, so I built the smallest thing that would tell me whether the idea held.
questions I get asked
Are you Ani or Anna Petrinchik?
Both. Ani is what I go by day to day and online (@anipers). Anna Petrinchik is my formal and legal name on passports and corporate paperwork. If you are looking for Ani Petrinchik or Anna Petrinchik, you have found the right engineer. Online you may also run into me as anipers, annapers, anypers or aniperss — all the same person.
Growth and engineering — how do the two fit together?
I started in growth and moved into engineering by building my own tooling instead of briefing someone else to. For the last two years I have written production code, and on my current project I own the backend and the infrastructure across three products — ingestion, schema, commerce, deploys. The growth years are why every system I design answers to a user and a unit cost. The case studies above show the engineering side: schema decisions, index choices and the tradeoffs written down.
Which parts of these systems did you design?
The architecture, end to end. The payment flow is mine — market routing, invoice before payment, idempotent webhooks, order status as a state machine rather than a free-text field. So is the security model: personal data separated by country of residence across two clouds, kept off the shared analytics database, masked in every log channel, audited on access and erasable on request. So is what it runs on — the containers, the databases, the deploys. Each case study lists the decisions with the reason attached, and the conditions under which I would revisit them.
What does AI agent orchestration look like in practice?
Narrow agents with written briefs, explicit contracts between them, and gates they cannot talk their way past. This site is run that way: an SEO agent audits pages and opens pull requests, a content security agent reviews every draft, and nothing merges or goes public without a person signing off. The full write-up covers the roles, the contracts, the gates and where the money goes.
What do you actually work in?
Python and TypeScript day to day. FastAPI and Laravel for services, PostgreSQL underneath — schema, indexes and migrations are mine — Docker and Linux to ship it. Next.js and React when the system needs a face. LLM pipelines in production every week.
What kind of work do you take on?
AI systems and the backend underneath them, where I own the system rather than a slice of one: agent orchestration and LLM pipelines, ingestion, database schema, and what it all runs on. Founding-engineer and systems-architect roles, and advisory work for teams putting agents into production. Remote, and I am in Abu Dhabi — comfortably overlapping European hours.
Can I see the code?
Some of it. precheck is a prototype you can click through, and insights.fashion is live. Most repositories are private client work, so the case studies describe the architecture and the decisions instead. Happy to walk through any of it on a call, or share access where the client permits.
You list Arabic. Do you speak it?
No. I speak English and Russian. I have shipped Arabic interfaces with proper right-to-left — layout direction, punctuation and numerals — working with translators for the copy. Localisation is an engineering problem; the language is a separate skill and I would not claim it.
What is the fastest way to reach you?
Email — anipers.official@gmail.com. Telegram works too, @aniperss.
Let's
talk
Putting AI agents into production,
or need a system that runs itself and pays for itself?
Founders who need one engineer to own the AI system end to end
Teams putting multi-agent pipelines into production
Anyone building across MENA