How I went from factory ERP systems
to my own AI services

In October 2017 I joined Baltic Shipyard in Saint Petersburg as a first-category engineer. My job was planning shipbuilding projects in Primavera P6. In practice that meant multi-level network schedules for ships that take 5–7 years to build, and specifications with tens of thousands of material line items. I moved data between Excel, Primavera and Infor LN with tools I wrote myself, because no ready-made solution existed.

Almost four years later I became lead software engineer. By then I was already writing my own sessions in Infor LN Studio in BAAN 4gl. In this system a session is a program with its own screens. I sped up complex SQL queries for cross-workshop reports and taught the workshops to record completed work in Progress Reporter. I also built IBM Cognos reports for the finance department.

At the shipyard I learned what it means to be responsible for a live system. When the records hold tens of thousands of items, one typo in a SQL query can stop a workshop for a day. Every line of code immediately affects the people at the machines: they stand and wait until you fix it.

I took three rules away from the shipyard, and I still follow them in my AI services:

• · Every error has an address. At the shipyard, behind every error there was a specific welder, waiting. I treat failures in AI services the same way: behind each one there is a specific person.
• · Keep logs from day one. If something breaks at night, in the morning you need a record that lets you reconstruct what happened. Since then I haven't launched a single AI agent without detailed logs.
• · Every system degrades over time. The shipyard taught me to build in regular checks and clean-up of old data from the start.

For me a system truly works when someone is responsible for it: if it gets stuck at 03:47 in the morning, I'm ready to get up and sort it out.

In November 2022 I moved to Turkey and joined IPL Consulting, working for clients in Western Europe, Russia and the Middle East. A year later I moved to Asertiva Solutions in Bulgaria, which serves the EU market. Over those two-plus years I saw one ERP system, Infor LN, adapted for the car industry, including Ferrari and Aston Martin, for nuclear power (Kozloduy NPP, Rosatom) and for shipbuilding (United Shipbuilding Corporation and dozens of shipyards in different countries).

That sounds like a line from a sales deck. In practice it meant dozens of tickets from companies in different countries and industries, and each one showed the same thing: standard Infor LN is only a foundation. Each client's real manufacturing logic lives in their own customisations: sessions in BAAN 4gl, VB.NET changes in Mongoose, and Birst reports where half the formulas exist “because that's what we agreed back in 2007”.

One platform. The same tables. A different failure at every client. At Ferrari a single ticket could grow into a large amount of custom code, because they have strict requirements for tracing every component. At Kozloduy the same field fed reports to the nuclear regulator. One mistake in one formula, and you get either an incomplete parts shipment to Maranello or a query from the regulator.

That is the main lesson of large implementations: a working system stays alive only while people keep adjusting it to reality. It changes through small fixes, because life moves faster than any specification. When nobody maintains a system, within a year or two it usually has to be painfully migrated or replaced altogether.

So when someone tells me “we launched an AI agent and it works”, I'm not reassured. “It works” describes a single moment. To keep AI working, someone has to watch it every day: the logs, the quality test results and the costs. Without that, six months later something quite different is running from what you launched.

The second lesson: regulatory requirements are an engineering task. At a nuclear plant every change has to be traceable. In Russia the personal data law (152-FZ) directly shapes code, architecture and logs, and for critical information infrastructure (CII) 187-FZ adds its own requirements. If you don't build these in from day one, you will have to redo the work later.

In the summer of 2021, already a lead engineer at the shipyard, I enrolled in the App Brewery iOS course and watched the WWDC21 sessions alongside it. I wanted to learn to build my own products. When the product is yours, you answer for everything: how easy it is to use, the server side, and making it easy for people to pay you.

Over a year I wrote more than twenty apps in Swift, SwiftUI and UIKit. Most were learning projects, and not all of them reached the App Store. Each one had a concrete task behind it: image recognition with CoreML, augmented reality with ARKit, in-app purchases through StoreKit, a Mac version through Catalyst, data storage in CoreData and Firebase, push notifications.

The main thing this gave me: you only really learn a product from live users. You can sit through a 40-hour course and know what @StateObject is. No lecture will tell you what to do with a StoreKit error when a user's purchase fails and receipt validation hangs for 30 seconds. You learn that when your app is losing money on real users.

It's the same with AI agents today. A course will explain RAG: a search across your documents that the model uses to answer. What to do when the search returns a useless chunk of text for an important question, you only learn by working with real people.

From November 2024 I worked as a middle-level media buyer in a large ad-buying team in Moscow. Its name is under NDA. From September 2025 I was a senior media buyer in a second team of this kind, also under NDA. Over sixteen months $1.34M in ad budget went through my hands on the largest social networks. Net profit came to about $379k, an average return of 28%.

The main thing ad buying gave me was a different view of architecture. When you run an A/B test (a comparison of two versions) on a daily budget of $2–5k, every extra second a landing page takes to load lowers conversion. The money burns right now, in front of you, in the ad account report.

I used to optimise code because it was the right thing to do. Now I look at speed and cost the way a media buyer does: I count how much margin an extra fraction of a second eats every day.

That is also when I started writing my own tools: automated campaign launches through the Facebook Graph API, collecting competitors' ads and analysing them with GPT, and a connection to the Keitaro tracker through CAPI, which sends events about new enquiries and purchases from the server straight to the ad account. I wrote all of it so that I didn't have to launch each of some 300 ad creatives by hand. The desktop program that grew out of those first scripts later became a Telegram bot and a web app. How that platform works.

That led me to a conclusion that matters to me. Engineers learn most from work where spending is visible every day and any delay hits the cash flow straight away: trading, ad buying, running an online shop, small online services.

I now apply this to AI. When I build a system for a client, the first two questions I ask are how much it will spend on model calls each month at current traffic, and when it will pay for itself. If the investment doesn't come back within eighteen months, I don't take the job: a system like that can eat the client's whole margin. You can see how I work out payback on sample quotes in What AI implementation costs.

Since 2025 I have been running my own AI services. They work around the clock, and they spend and earn money. Watchdog processes keep an eye on them: they notice anomalies, stop a system on their own when it fails, and send me a Telegram message straight away.

What's running now:

• · Trading bots. They run around the clock, and I don't share the details. They have end-to-end logs, automatic shutdown on failure and a review of every incident. How their reliability is built is covered in a separate write-up.
• · Ad automation. There are 327+ Facebook ad campaigns on my platform. A Telegram bot watches the metrics that arrive through CAPI, sends me a summary and warns me when the numbers change sharply.
• · Promo page generator. A desktop program builds a page from a template and a short brief, or from a link to an existing page, and publishes it to hosting on its own.
• · Research from open sources (OSINT). A 12-step method for researching a competitor or a future partner using public data. The browser sessions that run it restart on their own after a crash.
• · Shared memory across projects. A SQLite database that records every file edit and command from my Claude Code sessions, plus a decision log that is copied to Discord.

All of this runs on rented VPS servers linked by an encrypted WireGuard network. Alerts go to Telegram and Discord, and the SQLite databases are compacted once a quarter.

The main lesson: the hardest part begins after launch. You need to know what to do when OpenAI limits your access at night, when quality checks reject a new model version, or when a regulator asks where you store personal data.

That is why I design, launch and support everything I offer clients myself.

This is the most useful chapter. If you're a CTO, a founder or a manager about to spend serious money on AI, read at least this one. It collects uncomfortable things that are better known before you pay.

1. An AI agent doesn't work on its own. It needs a well-designed system around it, where its job is only to help. The “autonomous agents” I've seen running in 2025–2026 consist mostly of ordinary code with predictable behaviour: data validation, retries, a fallback path, logs. Calls to the language model are the smaller part. If your ratio is the other way round, what you have is still a demo.

2. The term “AI agent” has lost its meaning. It is now applied to almost anything that calls a language model, including ordinary robotic process automation (RPA) and chatbots. Gartner places AI agents at the peak of inflated expectations, and in June 2025 it predicted that over 40% of such projects will be cancelled by the end of 2027. So judge a project by its quality test results and its cost structure.

3. What really matters once AI works with real users:

• a. Quality checks (evals). Repeatable tests on a reference set: a fixed list of questions with known correct answers. Without them, you're flying blind.
• b. Complete logs. Every model call is recorded: the request, the response, the cost and the response time. Otherwise you can't work out why the agent did something stupid today.
• c. A spending cap. Some attacks are designed to inflate what you spend on the model. Without a cap, a single night's bill can exceed your monthly budget.
• d. The personal data law and CII requirements. If you're a Russian company, look at article 13.11 of the Code of Administrative Offences as it stands today. A data leak costs 3–15 million ₽ depending on how many people are in the database; failing to notify the regulator, Roskomnadzor, costs 1–3 million ₽. A repeat leak costs 1–3% of revenue, and no less than 20 million ₽. The figures, with links to the law, are in the article on personal data and AI models. The ban on foreign software needs to be described precisely. It was introduced by Presidential Decree No. 166 of 30 March 2022, while the security of critical information infrastructure (CII) is governed by 187-FZ. Since 31 March 2022, organisations that buy under the 223-FZ procurement law may purchase foreign software for significant CII objects only with the approval of the authorised body. Since 1 January 2025, state bodies and those same organisations may not use such software on the significant CII objects they own. Since April 2025 the ban has applied “unless otherwise provided by federal law” (Decree No. 166 as amended on 07.04.2025). The ban applies to the owners of significant CII objects. A bank, an oil and gas company or a telecom operator falls under it only if it owns such an object. The duty to use Russian software from the official register on significant CII objects was written into 187-FZ itself and took effect on 1 September 2025 (Federal Law No. 58-FZ of 07.04.2025). The government sets migration deadlines for each sector in separate acts. If your object falls under these rules, using Cursor, Claude or OpenAI on it is a formal violation. If it doesn't, there is no “ban from 2026” to cite: no such rule exists.

4. Read the 2025 edition of the OWASP LLM Top 10. It is the widely used list of the main risks for systems built on language models. If your AI works with real users and you haven't read the latest edition, put everything aside and read it. Prompt injection (LLM01), system prompt leakage (LLM07), excessive agency (LLM06) and unbounded consumption that inflates your costs (LLM10) are real attacks of 2025–2026. The EchoLeak vulnerability (CVE-2025-32711) scored 9.3 on the CVSS severity scale; remote code execution through GitHub Copilot (CVE-2025-53773) scored 7.8.

5. Prompt injection comes from unexpected places. From RSS feeds that end up in document search. From email signatures that land in the model's context. From comments on code changes that a coding assistant reads. If your agent reads any data from users, it can be attacked.

If you have an AI agent running and don't know the answers to these five points, that's normal: many teams are in the same position. It means you need an outside view, someone who comes in and shows you where the holes are. That's the review I offer. Formats and prices are on the AI security review service page. The ready-made solution AI chatbot security audit lays out every step. Its figures are estimated for a typical online school.

I divide my work into four areas:

• · Customer communication: AI assistants in chats (WhatsApp, Telegram, your website), voice agents on Vapi or Bland AI with ElevenLabs voices, assistants that answer from your company's knowledge base.
• · Process automation: workflows in the n8n and Make builders, document processing, ad automation for Facebook and Keitaro, connections to any CRM or ERP system.
• · AI infrastructure: running and supporting language models on your own hardware (vLLM, Ollama, GigaChat) where CII rules require it. Quality checks, logs, spending caps, and protection based on the OWASP LLM Top 10.
• · Development: server side in Python and Node.js, mobile apps (native iOS and cross-platform), interfaces in React and Astro, integrations with any API.

I can be most useful to founders of B2B services with 20–100 people, ad agencies spending $500k or more a month, mid-sized online shops that need AI customer support, and law firms and medical clinics that handle personal data. If a company's revenue is under 1 million ₽ a month, automation usually doesn't pay off, and I'll tell you so on the first call.

If you've read this far, start with the 5,000 ₽ audit. It's a 60–90 minute call and a written report: what to build first, when it will pay off, and whether your business needs AI at all. Sometimes it doesn't, and I'll tell you so honestly.