József Márton Jung

MeridianBet runs a betting and online casino platform with a backend of over 60 microservices, Kafka as the messaging backbone, and an architecture that grew fast under a “new feature, new service” philosophy, and grew messy along with it. My job now is untangling that: identifying which services actually belong together and merging them, and rewriting others to properly use Spring’s framework capabilities instead of treating it as a glorified dependency-injection tool. The real challenge isn’t the redesign itself, it’s that every one of those 60+ services is live and under active development, so consolidation has to happen without breaking anything currently in production or blocking the teams still shipping features on top of it. I’ve also stepped outside pure engineering to help shape a client-facing proposal and SOW for a new project, a reminder that good architecture decisions start before the first line of code.

ContentLion set out to do something ambitious: build a next-generation headless CMS, site builder, and digital asset platform good enough to replace Oracle Content Management outright, enterprise security and scale included, running on Oracle Cloud, built entirely from scratch. I led a team of six (3 backend, 2 frontend, 1 QA) building the Go backend APIs powering content, asset, and site-management services, and was one of a small group shaping the microservices architecture from the ground up rather than inheriting someone else’s decisions. I also worked closely with infrastructure on CI/CD, because a platform this size lives or dies on how smoothly it ships. Since launch, one client migrated 1.2 million assets onto the platform, and another, gov.ky, moved over 70 archived government sites from Oracle Content Management without major issues.

Grocery Buddy helps shoppers find the best deal across stores, which sounds simple until you need accurate, current prices from a dozen different sources, most of which would rather you didn’t scrape them. I built the Java backend API powering the core app, and wrote the Python crawlers that kept product data fresh. The real challenge was making them convincing enough, in request patterns, headers, and timing, to keep operating without getting banned by the sites they pulled from.

Halfords runs the full journey from “I need new brake pads” to “installed and done” through one point-of-sale system, and my work was making that journey smoother end to end, from order placement through to parts installation, inside a legacy codebase still running on Java 1.6. Not the most modern stack to work in, but a good reminder that reliability at real retail scale matters more than chasing the latest version.

Partou, the largest childcare organisation in the Netherlands, needed to schedule children and staff across facilities more intelligently, a genuinely tricky planning problem with real people on the other end of it. I was the sole developer on the full-stack application: the React/TypeScript interface and the Python planning API behind it, working alongside a data scientist who supplied the underlying data. Along the way I also helped the data science team tighten up their coding standards.

Bauwatch keeps watch over construction sites, energy farms, and vacant properties, often with no power and no reliable connectivity on-site. I built a Go application from the ground up that translates between Bauwatch’s internal protocol and the SIA DC-09 industry standard, so customers with compliant security hardware could plug straight into Bauwatch’s system without custom integration work. The constraints shaped the whole approach: it had to run as a single self-contained binary on edge hardware, so every dependency needed real justification, since size and speed mattered, and it had to keep working through offline periods with no network connection at all.

Coolblue Energy (formerly Servicehouse) wanted to operate as a full charge point operator, which meant implementing the OCPI protocol’s CPO role from scratch. The eMSP side already existed by the time I joined the project. Beyond that, I built two more services from zero: internal tooling that tracked the entire fulfillment journey, from buying energy products to getting them installed at a customer’s site, and a centralized service for monitoring what was actually sellable, which I led. I also managed a team of five through all of it.

M-Pioneers builds software across healthcare, logistics, and HR. A short engagement, but a genuinely different stack from most of my work: a C#/.NET Core backend with Entity Framework and SQL Server, tracking equipment and items issued to employees. Useful proof that I’m not tied to one ecosystem when a project calls for something else.

codecentric placed me as a consultant with METRONOM, METRO AG’s digital innovation arm, embedded in their Data Science team to support the data scientists on the software side. I architected and built, in Python on GCP, a machine learning application analyzing customer transaction data for churn, decline, and growth prediction, plus a second one suggesting product substitutes when an item was out of stock. I set up CI/CD for both, automated monthly prediction runs with Apache Airflow, wrote the test suites, kept documentation current, and worked with other teams to help them actually consume what the models produced. The pipeline ran across 24 countries where METRO sells, and the data itself was the real challenge: raw input came in as single-item lines on bills, each bill holding multiple items, and buyers were legal entities like hotels and restaurants rather than individual shoppers, with daily volume swinging, from memory, somewhere between hundreds of thousands and a few million line items depending on the country.

Another codecentric consulting placement, this time with OBI Next, exploring digital touches for hardware store customers. I designed the high-level architecture together with the stakeholders, then built it from scratch in Python on a pure serverless AWS stack: an app that reads weather forecasts and notifies the right customers at the right moment: rain coming means it’s time to think about garden covers, not after the fact. I wrote the tests, documented the project, and integrated it into the broader OBI Next ecosystem. What made it memorable: this was my first time writing Python, and honestly every piece of the stack was new to me going in.

Playerhunter connects athletes, clubs, and agents. I specified, designed, and implemented a complete redesign and rewrite of the Java/Spring backend from scratch, and took charge of the Digital Ocean infrastructure underneath it: set up Jenkins CI for build automation, documented the API, and worked closely with the frontend team to get them integrated. This ran at the same time as the Gazindo engagement below, with the same core team and the same stack. Proper early-stage startup work, juggling two greenfield builds in parallel, part-time. Playerhunter kept going beyond this engagement.

Gazindo aimed to run purchasing and inventory end to end: supply, ordering, accounting, and stock, all in one solution. I built the Java/Spring backend from zero, specifying and implementing features as the product grew, and owned the complete Digital Ocean infrastructure, including the web frontend. I set up Jenkins CI to automate build and deployment across the backend, web frontend, and Android app, documented the API, helped with web and Android integration, and built an internal Kotlin application for managing backend data, all working alongside the same team building Playerhunter at the same time. Gazindo eventually ran out of funding and shut down, the kind of outcome that comes with early-stage startup work.

Improve Digital’s 360 Platform helps publishers automate and improve monetization of advertising and audience across every screen, format, and sales channel, public and private alike. I built a report delivery pipeline on Hadoop using Python, Hive, Impala, Sqoop, and Oozie. That was my first real hands-on work building a data ingestion pipeline. I also contributed to Phoenix, a set of Java/Spring microservices extending the 360 Platform’s backend, and built and maintained three core applications: Data Ingest, which batch-processed bidding data; Third Party Integration, syncing the backend with partners like AppNexus; and Reports, which generated and uploaded reports to Amazon S3.

TomTom was a leading name in navigation: in-car and personal devices, in-dash infotainment, fleet management, maps, and real-time services like TomTom HD Traffic. I sustained Java backend applications handling device and user management, subscription rights, and promotions, and built a new middleware application that became the single point of contact between TomTom’s mobile apps and the rest of the backend, with everything exposed as REST or XML web services. One feature I’m particularly proud of: extending the subscription system to automatically notify a third-party system about refunded shippable items, turning what had been manual busywork into something automatic. I also worked on Java/Scala middleware sitting between devices, device-support apps, and backend systems, and beyond feature work, handled production issues, wrote unit/integration tests, monitored code quality with SonarQube, set up Jenkins CI for build and release automation, and built internal tools in PHP and JavaScript.

Relatieplanet was, at the time, the biggest and most-visited paid dating site in the Netherlands, also covering Dutch-speaking Belgium. I helped rebuild the front end from ASP/VB to JSP/JSTL and overhaul the backend, migrating roughly 3.5 million live user accounts in the process without breaking the site under its users. I also implemented content search using Solr and built an image manipulation library on Java 2D to convert and transform user-uploaded images, alongside the usual stream of bug fixes and unit tests.

The backstory here is half the story: MOL, Hungary’s state-owned oil company, modernized its fuel dispensers and sold off the old hardware, and smaller independent gas station owners snapped up the used dispensers, but had no way to connect them to modern cashier systems. That’s the gap this project filled. The dispensers themselves were German-made, so the only documentation available was in German, which was its own small challenge before any code got written. I designed and built a Java application, installed on a PC wired to the dispenser hardware, that bridges the fuel dispenser and the cashier system, talking to the dispenser over serial port using the RXTX library and to the cashier system through server sockets. I added HTTP-based log access and maintenance via Restlet, persisted dispenser controller state in an H2 database, and built a dispenser emulator with Com0Com and RealTerm so the whole thing could be tested without needing real hardware on hand. Wrapped it up with a full user manual for the client.