What we can deliver: five projects and five principles

When someone reaches out about a new engagement, I do not start with what we are proud of. I start with what we have actually built and what that means for them. Here are five projects. Each one demonstrates a different capability, and from each one comes a single principle I carry forward.

Enterprise performance: the bottleneck is not where you reach first

At ČSOB I worked on contract generation. It took two hours. After my work it took three minutes. That is a 40× speedup, and it did not come from rewriting in a newer framework or adding servers.

A similar story: Atlas Copco. A SAP data pipeline written as a single SQL script of fifteen thousand lines. After the refactor — three thousand lines, eighty percent less, and a conversion to event-driven on Azure Functions. Runtime went from several days back down to roughly four hours from Europe and six from Asia. Globally deployed SAP downloaders feeding data warehouses that had previously been perpetually catching up with themselves.

The principle is the same in both cases. Find the real bottleneck first, not the first one that is visible. Most of the time it is not "slow servers" — it is data structures, missing caching, SQL written against how the database actually works, or a synchronous step that should be an event. When you hit the right spot, the number does not improve by a few percent — it improves by an order of magnitude. When you do not, you buy a bigger machine and still have the problem.

Resilient integration under load: the state does not forgive fire-and-forget

TrafinOil needed to send invoices to KSeF — the Polish government e-invoicing system. That kind of system is asynchronous, rate-limited, occasionally unavailable, and has its own state. It is not an endpoint you send a request to and trust that it went through. It is a long-running stateful workflow.

I built it as a durable pipeline. Idempotent submission, so retries do not duplicate documents. Retry with exponential backoff for when the system is under load. Rate limiting so the government does not cut us off. Reconciliation that periodically checks that reality matches our records. UPO confirmation as proof of delivery and an audit log on every state transition. Verified in production on more than 40,000 documents, 100% delivered. Plus a data migration to Dynamics 365 Business Central.

I have confirmation of why it has to look this way, and it came the hard way. The previous pipeline was fire-and-forget and was silently losing documents. I forensically tracked down and recovered 15,141 missing documents that nobody knew were missing. That is the difference. Fire-and-forget looks exactly the same as a durable workflow in a demo. It only diverges the moment the government does not respond — and at that point you either have an audit log and reconciliation, or you are hunting for fifteen thousand invoices after the fact.

By the way: performance and resilience are not opposites. On the same project I cut the nightly dataloader from 20 hours to 30 minutes. Robustness does not mean slow.

Principle: for any external system that is asynchronous, rate-limited, and has its own state, I budget the full machinery upfront, not incident by incident. Durable state, idempotence, reconciliation, observability on every transition. Not because it is elegant, but because the cheaper alternative is paid for later and at a higher price.

A complete product from scratch: four months, not four years

Carivio, also known as TaxiLight, is a complete taxi dispatching platform. Three platforms — backend, web, and mobile. As SolutionBox we delivered it in four months and it is running. Around 50 live vehicles operate in production; you can see it at transportprague.com.

A few numbers to make clear what "complete" actually means. Backend around 128k lines of code. 48 feature modules. 107 EF migrations. Six roles. Four SignalR hub endpoints for real-time. An auction model for rides where the offer is broadcast to drivers over SignalR, geospatial queries on GPS, background location on mobile that has to survive real Samsung, OnePlus, and Huawei phones and their aggressive app-killing. Plus an offline queue and recovery for when the OS kills the app.

The principle here is not "we work fast." The principle is that a complete product from scratch contains a lot of things you do not see in a demo, and those things decide whether it holds up in production. Background location on real OEM phones, recovery after the app is killed, real-time that does not flood the network with duplicate events. These cannot be added "later." Either they belong in the design from the start, or the app behaves as broken and nobody knows why.

AI inside real systems: foundation first, model second

Now to AI, because that is the number-one question today. Let me be direct about one thing upfront: I am not an ML researcher. I do not do fine-tuning, MLOps, or model training. I do application and integration AI inside production systems. That is a different discipline and it is worth saying so upfront.

For the city of Zlín, together with Continero, we built a citizen RAG chatbot with ~90% accuracy on live data. Under it is a multi-agent engine with hybrid retrieval that combines document search with queries over structured municipal data and self-corrects when a query fails. It won a regional hackathon, Innovation Day.

That same logic runs through the other things we do. An AI agent for invoice data extraction that reads documents and writes them into an existing ERP — but with human-in-the-loop and an audit log, not as a black box. A production AI code-review service that comments on pull requests with deduplication and branch context. Automation for emails and public procurement, where entity extraction via embeddings and RAG finds relevant opportunities. From Continero: Artima.ai, an all-in-one social media marketing tool that generates photos and videos with AI and schedules publication. And HDTS, a computer-vision system that reads skating angles from video and coaches a hockey player in real time.

Principle: I build a clean, production-ready foundation first, and only then add the LLM or RAG on top. Most teams do it the other way — ship a PoC without foundations and spend a year catching up. I go from foundations up, because LLM calls without cost tracking, guardrails, and observability are a liability in an enterprise system, not a feature. Token auditing, a budget gate, guardrails against prompt injection and hallucination, a log on every call. That is what separates an AI demo from AI in production.

AI inside a fintech system: a model that trades with its own state

The fifth project goes a step further. Robootec, which I am building with Continero as architect, is an AI algorithmic trading platform. It is not a chatbot you type something to and it replies. It is a system that takes data, evaluates it, and trades — so every decision has a consequence and its own state that has to live somewhere.

The input is not just prices. It combines AI news sentiment (reading news with a model), macro data, and technical indicators, and generates signals from that. The stack is .NET 10 on the backend and Next.js on the frontend, CQRS inside, multi-provider LLM orchestration, real-time via SignalR and SSE, and observability via OpenTelemetry.

A few things are worth highlighting, because they are the less glamorous but decisive part of AI in production. Multi-provider LLM orchestration with prompt caching, so we are not locked to a single provider. Local inference for sentiment, so it runs on our side and not every call goes out. A budget gate before every request that monitors how many tokens and how much money go into the model before it is sent. And a stateless signal engine where adding a new strategy does not break existing ones.

Where things stand right now, I will say plainly. The PoC is running live. Autonomous AI trading — what we call "vibe trading," meaning the system trades on its own — is in development, not finished. I am building it for the same reason as everything else: for a system that touches money, cost tracking, durable state, and observability are prerequisites, not extras.

Principle: AI makes sense when it is embedded in a real system with data and state, not as an isolated chatbot alongside. Only when the model reads live data, does something with it, and that decision has a consequence that must be traceable and paid for — only then does it become clear whether you have a system built around it or just a demo. That is why I am building the cost gate and the state engine at Robootec before autonomous trading.

And we apply the same logic internally. ModularPlatform is our modular foundation for read-heavy applications, still in development. A .NET modular monolith with architectural boundaries enforced mechanically via ArchUnitNET, durable messaging via Wolverine with outbox, inbox, and sagas, Postgres row-level security for tenant isolation, crypto-shred deletion for GDPR, Stripe for payments, and Next.js 15 with React 19 on the frontend. It exists so we do not start every product from zero and have a proven foundation instead of rebuilding the same infrastructure repeatedly. Source code stays with the client — no vendor lock-in.

How we approach a new engagement

These five projects share a common pattern. I start by asking where the real problem is, not where it hurts most at first glance. Then I decide how much resilience the engagement actually needs — because a durable workflow and fire-and-forget only look different under load, not in a demo. Then I build the foundation so it holds up in production, including the things you do not see in a demo. And only at the end, when it makes sense, do I add AI — with cost tracking and observability from the start, whether it is a chatbot over municipal data or a model trading with its own state.

So when a new engagement comes in, I do not promise a framework or a buzzword. I ask what actually matters, what needs to be handled before it goes to production, and where the one change is that moves the number by an order of magnitude instead of a few percent. That is work I am not embarrassed by.