About Dario Mory

ChallengeAt a coordinated hub every arrival and departure holds a slot, and they are reallocated continuously as the day drifts from the plan. The system doing that was legacy scheduling infrastructure — hard to change, hard to scale into peaks, and running an operation that gets no maintenance window.

ApproachA microservices platform on Kubernetes and Google Cloud: Python and FastAPI at the API layer, C++ for the compute-bound scheduling logic, and real-time integration with the legacy systems it had to coexist with. I led the API work for a team of around six engineers, established the CI/CD and infrastructure-as-code practices we delivered through, and modelled the architecture in Enterprise Architect for sign-off.

OutcomeA scheduling platform that could be deployed during the operating day, scaled per service into demand peaks, and integrated with through a documented API rather than by reaching into a database.

ChallengeEU regulation requires member states to publish public-service information that is findable, current and available in a second language. In the Netherlands that obligation lands on every municipality, province and water authority in the country, each holding its own wording of the same descriptions.

ApproachProject lead for the Invoervoorziening — a CMS and an API, both on Django and developed in the open. Each organisation edits from a national reference text rather than a blank page, and the API publishes the result as structured data with a defined update path.

OutcomeOne national route for Dutch government bodies to publish service information uniform enough to aggregate, structured enough to reuse across national and European portals, and open enough to inspect.

ChallengeThe product depends on knowing a specific customer’s actual electricity tariff, which sits with suppliers under no obligation to hand it over. The Dutch market splits across several routes at once, each with its own agreements and its own idea of what a tariff record contains.

ApproachI built the Dutch access layer: the integrations across those routes, plus the negotiation and authorisation work that made them possible at all — behind a single schema, so none of the fragmentation is visible from outside.

OutcomeDutch supplier coverage delivered through the same public API as every other market, which is what makes consumption shifting a feature someone else can ship without ever talking to a utility.

ChallengeA low-code platform has to serve citizen developers who never want to see a runtime and professional developers who abandon it the moment there is no escape hatch. Serving only one of them produces either a toy or a framework nobody needed.

ApproachFull-stack platform engineering: Elixir on the BEAM for multi-tenant concurrency and fault isolation, React and TypeScript for the visual builder, GraphQL between the two layers, and WebAssembly extensions as the route into custom code.

OutcomePlatform capability that holds both audiences at once — visual development that stays genuinely visual, and a route to custom code that does not require abandoning it.