FULL-STACK PRODUCT ENGINEER · AI-NATIVE
From a founder's idea to a working MVP — fast, autonomous, AI-native.
I'm Andrii Radkovskyi. Twenty years of engineering in a field where a mistake is not allowed to exist — nuclear power. Six months ago I moved that discipline into software, with AI agents as the production force. The result already runs in production.
The exact match
You described the person you are looking for — fast with a product, autonomous in technical decisions, AI as the key parameter, delivers to a working result, no micromanagement, understands the business task. Here is that description, set against the evidence.
I built an electricity-consumption forecasting product end to end, alone — requirements, data, ML, full stack, DevOps. About one month to a working MVP.
For me AI agents are not a side helper — they are the main production force, on every phase. The product is the proof, not the claim.
You wrote "senior-level ownership". I have twenty years of it — on the operational line of the national nuclear operator, deciding in real time and answering for the outcome. Ownership is not a title I take; it is a reflex I trained.
My method begins with understanding the task — the first and most important skill. A product built on a misread task is wasted, however well it is engineered.
Nuclear-grade discipline: five levels of tests, dedicated data-leakage tests — accuracy that is verified, not assumed.
The forecasting product started with interviewing the expert forecasters. Twenty years across operational teams — I work with people, not around them.
Proof of work — the forecasting system
My strongest project: an hourly electricity-consumption forecasting system for a regional power company. The hard part is the constraint — the forecast for tomorrow must be ready by noon, with only yesterday's actual consumption as input. No intraday data. The system is engineered to be accurate inside that real-world limit, not around it.
Forecasting core — an ensemble, not one model
Four models carry the forecast together: LightGBM and CatBoost (gradient boosting), Ridge (a stable linear anchor), and Google's TimesFM neural network for seasonal patterns. Their weights are recomputed from recent hourly accuracy — separately for each hour of the day. Around 37 engineered features: calendar, consumption lags, heating-degree-days, rolling means, anomaly flags.
Architecture and stack
A three-tier system: PostgreSQL 16 (~18 tables, schema under versioned SQL migrations) → Python 3.11 / FastAPI → React 18 / TypeScript. A strictly layered backend with no backward dependencies. Containerised with Docker Compose, deployed to a VPS, with health checks, log rotation and off-site backups.
Testing and honest accuracy
Five levels of tests: ~129 backend unit tests, ~15 integration and ~29 smoke tests, frontend unit tests, and 11 end-to-end Playwright tests. Validation is walk-forward — the model trains strictly on the past — and dedicated data-leakage tests guarantee it never looks into the future. The accuracy above is verified, not assumed.
Built by AI agents
Every phase — research, code, verification — ran with AI agents as the production force, under human control. Not "AI helped here and there": it is the working method, and this product is the proof that it ships.
You have seen one project in depth. There are fourteen.
Thirteen more working applications — forecasting, analytics, operator consoles, simulators — across energy, agriculture, finance and security. One engineering method behind all of them.
The method
One engineering method stands behind every project. Six stages — and the engineering is in what each one actually holds.
Understand the task
The first stage, and the decisive one — not the brief as written, but what the founder actually needs beneath it. Everything downstream is only ever as good as this.
Research and analogy
How is this already solved — in this business and in others? Most problems are not new. The work is recognising which solved problem yours resembles, and borrowing the architecture across domains — what energy does with a forecasting problem, commerce can reuse.
Solution architecture
The shape of the answer, designed before a line of code: which approach, which parts, how they fit together.
MVP
MVP architecture, and a technical spec from it. Build, check, and iterate — again and again — until the MVP works. Its purpose: to prove against reality whether the solution architecture was right, before the full product is built.
The full product
Full product architecture, a technical spec from it, and then fully agentic development — the build runs on AI agents under human control: code, tests, security, DevOps, testing again, trial operation.
Operation and support
The product lives after launch — monitoring, maintenance, and the support that keeps it working.
A prototype instead of a specification
A working product — even a single file — beats a stack of documents. It gets tested in reality at once.
Design from the failure scenario first
Before the happy path, the worst case. Twenty years of investigating accidents taught me this is engineering, not pessimism.
Where the discipline comes from
Twenty years in nuclear power — the whole path, from the ground up to the top of the operational line.
Then, at Energoatom — the national operator of every power unit in Ukraine — senior analyst for the investigation of emergency situations across all of the country's nuclear plants: root-cause analysis, finding hidden defects before they become events.
That is the discipline of a field where a mistake is not allowed to exist. It is exactly what I bring into software — and it is rare in this industry.
Six months
Six months ago I had not built software.
Your posting asks for a Senior developer — and you have thirty years in IT, so let me be exact rather than flattering. My software tenure is six months; I will not dress it as more. But the words you chose — "senior-level ownership" — are not six months old. They are twenty years old. I have owned decisions where an error is measured in human lives. The ownership is senior. The code is recent. You should see both.
I came from twenty years of hard engineering, made one decision, and put everything into it. Six months later — a working ML product, in a domain I knew nothing about at the start. That is the rate I move at, and what I could do with the right task in front of me is the question I would like you to ask.
The first skill
I don't know your startup yet. That is not a gap — it is my strongest ground.
Understanding the task — grasping what the founder actually needs, beneath the words — is the first and most important skill. Everything after it is execution. This is the part most engineers skip, and it is the part I am built for.
The proposal — zero risk for you
Concrete, and built so that you carry no risk.
One real task. One week. Freedom to act — no micromanagement.
A deep reading of the task and a solution architecture — most likely an MVP architecture as well. A concrete result you can judge.
You risk one week. In return you see exactly who you are dealing with — before any commitment is made.
Let's talk
If the person you described is the person on this page — here is how to reach me.