Client identities are kept confidential by default; engagement details and outcomes are described as openly as professional discretion allows. For specifics on scope, methodology, or references, please reach out directly.
Four national railway operators were running mission-critical control and monitoring stacks on legacy virtualised infrastructure approaching end of vendor support. The mandate was to migrate each operator from VM-based deployment to a modern Red Hat OpenShift cluster — entirely in live production, with zero tolerance for service interruption and full audit traceability across every step.
Each customer environment had its own configuration baseline, governance model, and acceptance criteria. The technical scope was repeatable; the human and procedural scope was not. Application owners across the four organisations needed to be embedded into the delivery flow as domain specialists, not handed a finished plan.
Approach
I authored the customer-specific Migration Method of Procedure (MOP) for the first deployment, then adapted and refined it through each subsequent migration. The MOP defines preparation, pre-staging, cutover, and post-migration validation as a sequence of explicit, auditable steps — designed to be executed under SLA constraints by a cross-functional team of four to six engineers per deployment.
For each migration I led the preparation phase end-to-end: stakeholder alignment, technical risk assessment, dry-run rehearsals, and customer sign-off. During execution I coordinated the engineering team through go-live, with application owners embedded as the operational ground truth for service-level decisions. After cutover I led the technical handover and documentation freeze required by each operator's audit framework.
The MOP I authored has since been adopted as the reference framework across the programme and has been handed off to at least four additional migration teams within Kontron Transportation — with my involvement in their kickoff and handoff phases to ensure consistent execution.
Outcome
Every migration to date has reached go-live with zero SLA impact and zero service disruption. The MOP-driven approach has compressed preparation cycles for follow-on deployments and provided each operator with a complete audit trail of the migration — a hard requirement in national rail infrastructure governance.
Throughout each engagement I served as the primary technical point of contact for Tier-1 client stakeholders, translating engineering progress into executive-level reporting and maintaining full audit-readiness across all deliverables.
4Countries · ÖBB, SZDC, SZ, ZSR
0SLA breaches across the programme
4+Internal teams adopting the MOP
4–6Engineers coordinated per deployment
Challenge
The product objective sits inside a regulated segment of European fintech: a data product for retail users, delivered under constraints on confidentiality of personal financial information and on how automated systems are allowed to communicate with retail investors. Two decisions were treated as non-negotiable from day one — a confidentiality-by-design data model where the operator has no ability to read user data in normal operation, and a compliance framework that keeps the product on the right side of European regulation on communications with retail investors.
The delivery constraint made the design problem harder: solo-founder, no engineering team, no external capital. Everything — architecture, technology selection, security model, compliance framing, build pipelines, distribution — had to be scoped so that a single technical project manager could direct it end-to-end using an AI-agentic development workflow.
Approach
My role on this project is not that of a hands-on engineer. It is that of an architect and product owner directing a code-generation workflow: I define the architecture, specify the security invariants, choose the technology stack, write the acceptance criteria and integration contracts, and orchestrate agentic coding tools that produce the implementation under those constraints. I review, test, and iterate on the output. This is closer to how a technical product owner runs a distributed engineering team than to traditional hands-on development — and it is the mode of delivery that makes a one-person build of this scope feasible in 2026.
Security architecture. The data model is built around a confidentiality invariant: user data on the server is encrypted with keys the operator cannot derive on its own, and is inaccessible to the operator during normal operation. A hypothetical breach of the storage layer returns only ciphertext. This invariant dictated a set of downstream decisions across session management, backup strategy, and operational tooling — all of which had to preserve it end-to-end. Cryptographic primitives were selected from modern, well-reviewed standards appropriate to the trust model; the specifics are held privately as product IP.
Compliance-aware AI layer. The product exposes an AI-driven analytics interface. In a regulated context, this is only defensible if the AI layer is engineered not to generate the outputs that regulation prohibits — factual numbers, personalised investment advice, unbounded natural-language claims about financial instruments. The design isolates quantitative computation from generative reasoning, routes user queries through classification before the model is engaged, and keeps the model's output surface inside a bounded contract. The result is an AI feature that adds real value to users without crossing lines that would make the product non-compliant.
Native distribution and integrity. The product is packaged inside signed native shells across desktop and mobile — with signed updates, certificate pinning at the transport layer, and OS-level biometric unlock. The rationale is straightforward: a financial product cannot be shipped as an unsigned browser app; users need to verify that the binary they run is the one that was built, and the update channel must be resistant to tampering.
Verification through tests, not intuition. The codebase carries over 2,400 automated tests across unit, integration, and end-to-end layers. In a solo-founder AI-agentic setup, the test suite is not optional — it is the mechanism by which correctness is enforced when the person directing the work is not the person writing every line.
Outcome
The platform is currently in MVP phase — codebase runs end-to-end across the target platforms, security invariants hold under the test suite, and the compliance guardrails have been validated against adversarial query sets. The venture remains in stealth; the objective at this stage is proof of the architecture, not commercial launch. Product-specific details are held privately.
The reason this case study belongs on this site is not the specific product. It is the working method. The project demonstrates end-to-end direction of a complex, security-sensitive, regulation-adjacent software build carried out by a single technical project manager using AI-agentic tooling — from initial architecture and threat modelling through to signed binary distribution. That capability translates directly into how modern IT programme delivery is starting to run: fewer hands on keys, more discipline on requirements, tests, and architecture. This is a live demonstration of it.
SoloFounder directing AI-agentic delivery
2,400+Automated tests across unit / integration / E2E
Multi-platformSigned native distribution, desktop & mobile
RegulatedEU financial-communications compliance by design
Challenge
A European railway measurement and analytics company — a returning Comtest customer — had received a recently engineered drive-test trolley equipped with GSM-R radios and an RF scanner. The unit was a near-prototype configuration; in the field, the power-supply board burned out repeatedly, with visible smoke and progressive damage. The customer's active measurement campaign on a national rail network was effectively halted, and a €250,000 contract was placed in formal written cancellation threat to Comtest sales and the CTO.
The escalation arrived during the summer holiday window. The assigned project manager and the account's sales lead were both out of office; the customer needed an answer, not a delayed handoff. The CTO delegated full operational ownership of the situation to me. At that point I was officially in a technical support role at my third year of total experience and second year at the company, but I was already operating as Technical Account Manager in practice — so the delegation made sense, and I took it.
Approach
I led the response inside a Lean Six Sigma DMAIC framework, used as a structuring discipline rather than as a documentation exercise — I was the only Green-Belt-certified person in the company at the time, so the methodology lived in how I sequenced decisions, not in a separate paper trail.
Define and measure. Together with the senior software developer and the original electronics designer of the trolley, I scoped the failure pattern: the power-supply board was burning out under field-realistic operating conditions, not reproducibly tied to any single trigger. After the second board failed, we ruled out manufacturing defect and committed to a design-issue hypothesis.
Analyse and improve. The electronics designer led the technical root-cause work on the board; I owned coordination, prioritisation against my parallel customer load, and the daily reporting line back to the CTO each evening. We iterated on the hardware fix and, in parallel, addressed potential electromagnetic interference paths on the cabling — even though EMI turned out not to be the primary cause, the additional ferrite cores were retained as a hardening measure.
The first field trip. I flew to the customer site in Poland with an interim revised board, framed openly with the customer as a provisional fix on the way to a definitive solution. The interim board burned out as well. The customer's technical lead delivered that news to me directly; the contract was visibly closer to cancellation. I held position: confirmed that the interim was always meant to be provisional, requested updates from the home team, and committed publicly to delivering the definitive board next.
The second field trip. Before the second trip we validated the redesigned board on a clone of the customer's measurement kit, running continuous-operation stress tests for 72–96 hours on both mains and battery power. I returned to Poland and ran further hours of field validation on site before handover.
Communication discipline. Throughout the six weeks of the crisis I held a single point-of-contact relationship with the customer's technical lead and an email channel with their management. Working language was English; cultural calibration with the Polish counterparts was direct and unproblematic given prior international exposure. Internally, I reported to the CTO each evening — a non-negotiable rhythm that let senior management stay informed without slowing down delivery.
Outcome
The definitive board held in production. The customer completed the interrupted measurement campaign successfully, paid the remaining contract balance, and the formal cancellation threat was withdrawn. The €250,000 engagement closed inside the same calendar year.
Inside the company, the case had a structural follow-up. I designed and authored a dedicated Factory Acceptance Test (FAT) suite for drive-test products — focused on endurance under continuous operation, thermal performance, and stress testing under field-realistic conditions. I trained colleagues on the protocol; the suite was adopted as the internal standard for drive-test product lines, ensuring that the failure mode that had triggered this crisis could not reach a customer in production again.
For me personally, the case was a turning point. The CTO formally acknowledged that I had been the only person to follow the situation through to resolution, despite being at the third year of total experience. From that point onward I was given expanded responsibility for cross-functional team coordination on subsequent engagements — the operational shift from Technical Support to de-facto Technical Account Manager became permanent.
€250kContract retained, balance paid in full
2Field trips to customer site (Poland)
72–96hContinuous validation on cloned customer kit
FATSuite authored, adopted as internal standard
Full case study in preparation
Preserving full data integrity and audit traceability across mission-critical validation assets.
Mission-critical validation assets — 2,300+ test cases and 2,100+ acceptance tests — needed to move out of in-step Blue into Jira, with the supporting knowledge base reorganised in Confluence. The migration had to preserve full data integrity and audit traceability throughout, because the validation evidence is referenced in customer acceptance and certification flows.
I designed the Confluence knowledge structure to host the migrated content, and engineered the import automation script that performs the mapping and transfer from in-step Blue into Jira at scale. The detailed write-up — data model, automation design, integrity checks, and rollout strategy — is available on request.
Looking for delivery experience that maps to your problem?
These three are a representative slice. If your engagement looks different — a different stack, a different geography, a different governance model — there may still be a closer parallel. Let's talk through the specifics.
This site uses essential cookies for basic functionality and, with your consent, Google Analytics to understand site usage. You can change your choice at any time via "Cookie preferences" in the footer.
Choose which categories of cookies this site may use. Your choice is stored locally and applies to this device and browser.
Essential cookies
Always active
Required for the site to function (consent storage, basic security). No personal data is shared with third parties.
Analytics cookies
Google Analytics 4 (Google Ireland Ltd.). Helps me understand which pages visitors find most useful. No advertising profiles are built. Data may be transferred to the United States under the EU-US Data Privacy Framework.