# Dino Omanović: full profile > Everything on the homepage as plain text, first in English, then in German. ## Key facts - Name: Dino Omanović (also written Dino Omanovic) - Role: Staff Engineer, AI & Backend at Hygraph (at Hygraph since 2021) - Focus: AI agent platforms, Model Context Protocol (MCP) servers, durable workflows with Temporal, GraphQL, PostgreSQL - Languages: Go (Golang), TypeScript; 14+ years of backend engineering - Location: Bonn, Germany (CET), works fully remote; English and German - Profiles: https://www.linkedin.com/in/dino-omanovic/, https://github.com/domano - Last updated: 2026-10-16 ## Talks - [Building an AI Knowledge Base with MCP](https://www.youtube.com/watch?v=8730GGrYdng) (2026) - [Building an AI Agent with TypeScript and MCP](https://www.youtube.com/watch?v=BHHjCripshs), Hygraph Livestream (2025) - [Choosing a GraphQL Provider](https://www.youtube.com/watch?v=LZ5rtP1PvMA), GraphQL Conf (2022) - [The state of Kafka and Go](https://www.youtube.com/watch?v=tcaPzIXwj8A) - [Why Go?](https://www.youtube.com/watch?v=BRdRm3wwvjs) - [Database bottleneck](https://www.youtube.com/watch?v=mGv79zsJ1K8) - [Microservice quality](https://www.youtube.com/watch?v=jKbIDyxQmOU) - [Reactive Go](https://www.youtube.com/watch?v=DsQgf6rgS_s) - [Serverless Go](https://www.youtube.com/watch?v=g-xWLYgeJ-M) # Dino Omanović · Staff Engineer, AI & Backend (MCP, Go) (English, https://www.dinodino.cloud/en) > Staff engineer in Bonn, Germany: LLM agent platforms, Model Context Protocol (MCP) servers and Go/TypeScript backends at Hygraph. 14+ years backend, remote. I've been building backends for about 14 years. At Hygraph I currently work on AI: an MCP server, the service that runs our agents, and everything between them and the content API. Mostly in Go and TypeScript. ## Idea. Experiment. Software. My favourite part of the job is when an idea turns into something that runs in production. With AI that got more interesting. You can build a demo agent in an afternoon. Getting one to work on real customer data takes a lot longer. That's where most of my time goes at the moment. Before that I spent years on GraphQL APIs, Postgres and large e-commerce platforms, and I still like all of that too. ### AI & agents I built Hygraph's MCP server and a good part of the agent platform behind it. Lately that includes custom agents that customers set up themselves. ### Long-running work Agents call slow and sometimes unreliable APIs. I use Temporal for that, so retries, cancellation and restarts are handled in one place. ### Data & APIs Lots of GraphQL, SQL and Postgres over the years, most recently vector search with pgvector. I like migrations that can go out in small steps. ### Leading I led the core team at Hygraph for two years. Now I work across teams as a staff engineer, which means design reviews, rollout plans and mentoring. ## Roles - **AI & Backend Engineer**: Agents, MCP tools and the Go and TypeScript services they run on. I still write a lot of the code myself. - **Forward Deployed Engineer**: Close to customers. From the first conversation to a released feature, and I keep it running afterwards. - **Architect**: Deciding where the boundaries between services go, and how to get there in steps. - **Tech Lead**: Coaching engineers and helping product and engineering agree on what comes next. ## how i build agents Roughly what happens when an agent runs on the platform I work on. Most of my work is in the steps around the model call. 1. start: A workflow step changes, a webhook comes in, or someone clicks “run” in the editor. 2. queue: Temporal takes over. Each agent has a coordinator with a fixed number of slots, so a big batch doesn't flood the LLM provider. 3. think: The model works through MCP tools, but only the ones that make sense for this one entry. Publishing isn't one of them. 4. check: Before writing, the agent asks whether a person is editing the entry right now. If so, it backs off. 5. review: Everything one run changed ends up as a single version. A person looks at it and decides whether to publish. ## selected work Things I led or shaped over the last couple of years, mostly at Hygraph. What I built is only half of it, so each card also has the decision behind it. None of these were solo projects. ### One MCP interface for AI clients AI clients needed a safe way into customer projects, not a new integration for every use case. I set up the Go MCP server and the rules for adding tools to it: authenticated, scoped to a project, validated input and errors a model can actually work with. Content, schema and migration tools followed on the same contract. decision: One shared tool contract instead of per-feature integrations. That gives more leverage, but every tool becomes part of the platform's security boundary, so validation isn't optional. Tags: Go, MCP, Auth ### Durable execution for agents Agents call slow LLM APIs and have to survive deploys and restarts, so plain request/response wasn't going to work. I set up the agent service on Temporal and defined the orchestration and recovery patterns: one coordinator per agent, limited parallelism, retries and cancellation. Later agents reuse them instead of inventing their own. decision: Take on Temporal as a new dependency in exchange for durable retries, queueing and visibility we'd otherwise build badly ourselves. Tags: Temporal, AWS, Go ### Custom agents people can trust Customer-configured agents are only useful if people trust what they do. I worked out the boundary first and then built it across four services: agent config, the tool loop, content versioning and the review UI in the editor. decision: An agent may only change the entry it was started on and can't publish. All edits of one run become a single version that a person reviews. Tags: Agents, MCP, Versioning ### Agents vs. people editing Agents shouldn't write into an entry someone is working on. My first design had the agent service read the editor's Redis directly. I changed course to a small API owned by the editor team, so the team that owns the data also decides what it means. decision: Fail open on timeouts, so an editor outage doesn't stop every agent. Run in shadow mode first and look at what would have been blocked before enforcing it. Tags: Temporal, Redis, Rollouts ### Vector fields in the CMS A new field type has to mean the same thing in the database, migrations, GraphQL schema, SQL translation and the editor. I split the work into seven separate pieces, so each layer could be reviewed and shipped on its own behind a flag. decision: Show users the trade-off between exact and approximate search instead of hiding it behind an index that can silently miss results. Tags: pgvector, GraphQL, Aurora ### Leading the core GraphQL platform Two years setting technical direction for the team behind Hygraph's global GraphQL API, balancing performance, reliability and API stability. That included edge caching with finer invalidation, the move to Aurora, and building our on-call and incident routines. decision: Change risky infrastructure region by region, with monitoring in place first, instead of one big switch. Tags: GraphQL, Fastly, Aurora ## experience Started as an apprentice in 2012, fell for Go along the way and ended up working on AI. ### Hygraph (Remote, 2021 – today) - Staff Engineer AI & Backend (2025 – today): MCP server, agent runtime on Temporal, vector search and the infrastructure underneath. - Staff Engineer Backend & Infrastructure (2024 – 2025): Content search with permissions, workflow authorization, autoscaling and keeping observability costs in check. - Engineering Lead · Core (2022 – 2024): Led the team behind the GraphQL API. Edge caching, Aurora, on-call and a lot of coaching. - Engineering Lead · Developer Experience (2021 – 2022): Reusable content components across data model, API and editor, while the team grew quickly. - Senior Backend Engineer (2021): Reworked schema generation so each project needs only one cached GraphQL schema. ### TheyDo (Amsterdam · Remote, 2024) - Staff Engineer (2024): Importing large amounts of customer research and pulling insights and journeys out of it with LLMs. ### Qvest Digital (Germany, 2012 – 2021) - IT Consultant & Systems Architect (2020 – 2021): Architecture group for the e-commerce platform of a large car manufacturer. - Product Owner & Systems Architect (2018 – 2020): Worked with the customer for two to three teams, translating priorities into technical work. - Developer → Systems Architect (2012 – 2018): Go and Java microservices for large online shops. Taught Go internally until people started using it. ## technology - languages: Go, TypeScript, SQL, Rust, Java, Node.js - ai & agents: Agents, pgvector, RAG, Embeddings, MCP, LLM tool loops - data: Kafka, Aurora, PostgreSQL, SQS, Redis - apis & architecture: Event-driven, GraphQL, Microservices, gRPC, OPA - runtime & infra: Docker, Temporal, Fastly, Kubernetes, AWS, Pulumi, ECS/Fargate, CI/CD - observability & quality: OpenTelemetry, Load testing, Distributed tracing ### where i used it - Go: One MCP interface for AI clients; Durable execution for agents; Developer → Systems Architect @ Qvest Digital; talk: Why Go?; talk: The state of Kafka and Go; talk: Reactive Go; talk: Serverless Go - TypeScript: Staff Engineer AI & Backend @ Hygraph; talk: Building an AI Agent with TypeScript and MCP - MCP: One MCP interface for AI clients; Custom agents people can trust; Staff Engineer AI & Backend @ Hygraph; talk: Building an AI Agent with TypeScript and MCP; talk: Building an AI Knowledge Base with MCP - Temporal: Durable execution for agents; Agents vs. people editing; Staff Engineer AI & Backend @ Hygraph - GraphQL: Leading the core GraphQL platform; Vector fields in the CMS; Engineering Lead · Core @ Hygraph; Senior Backend Engineer @ Hygraph; talk: Choosing a GraphQL Provider - PostgreSQL: Vector fields in the CMS; Staff Engineer AI & Backend @ Hygraph - Redis: Agents vs. people editing - AWS: Durable execution for agents - Agents: Custom agents people can trust; Agents vs. people editing; Staff Engineer AI & Backend @ Hygraph; talk: Building an AI Agent with TypeScript and MCP - LLM tool loops: Custom agents people can trust - pgvector: Vector fields in the CMS; Staff Engineer AI & Backend @ Hygraph - Aurora: Vector fields in the CMS; Leading the core GraphQL platform; Engineering Lead · Core @ Hygraph - Fastly: Leading the core GraphQL platform; Engineering Lead · Core @ Hygraph - Kafka: talk: The state of Kafka and Go - Java: Developer → Systems Architect @ Qvest Digital - Microservices: Developer → Systems Architect @ Qvest Digital; talk: Microservice quality - Event-driven: talk: Reactive Go ## in short ### Who is Dino Omanović? Dino Omanović is a staff engineer for AI and backend systems, based in Bonn, Germany. He has worked at Hygraph since 2021. Before that he was at TheyDo and spent nine years at Qvest Digital. ### What does he specialize in? AI agent platforms and LLM tooling, Model Context Protocol (MCP) servers, durable workflows with Temporal, GraphQL APIs and PostgreSQL, mostly in Go (Golang) and TypeScript. He has done both hands-on engineering and technical leadership. ### What kind of roles does he take on? Staff-level AI and backend engineering, forward deployed engineering close to customers, architecture across teams, and tech lead roles. ### Does he work remotely? Yes. He has worked fully remotely since 2021 from Bonn (CET) and works in English and German. ### What has he built? At Hygraph: the Go MCP server that lets AI clients work in customer projects, the agent runtime on Temporal, customer-configured agents with human review, and vector fields backed by pgvector. Before that he led the team behind Hygraph's global GraphQL API for two years. ### Where can I watch his talks? On YouTube: Building an AI Agent with TypeScript and MCP (Hygraph livestream, 2025), Choosing a GraphQL Provider (GraphQL Conf 2022), and several Go talks, including The state of Kafka and Go, Reactive Go and Serverless Go. They are all linked in the talks section. ### How can I get in touch? The easiest way is a message on LinkedIn (linkedin.com/in/dino-omanovic). His code is on GitHub (github.com/domano). --- # Dino Omanović · Staff Engineer, KI & Backend (MCP, Go) (Deutsch, https://www.dinodino.cloud/de) > Staff Engineer aus Bonn: KI-Agenten-Plattformen, MCP-Server (Model Context Protocol) und Go/TypeScript-Backends bei Hygraph. 14+ Jahre Backend, remote. Ich baue seit rund 14 Jahren Backends. Bei Hygraph arbeite ich gerade an KI: einem MCP-Server, dem Service, auf dem unsere Agenten laufen, und allem, was dazwischen liegt. Meistens in Go und TypeScript. ## Idee. Experiment. Software. Am meisten Spaß macht mir der Moment, in dem aus einer Idee etwas wird, das in Produktion läuft. Mit KI ist das spannender geworden. Einen Demo-Agenten baut man an einem Nachmittag. Bis einer zuverlässig mit echten Kundendaten arbeitet, dauert es deutlich länger. Damit verbringe ich gerade die meiste Zeit. Davor waren es viele Jahre GraphQL-APIs, Postgres und große E-Commerce-Plattformen, und das mag ich nach wie vor. ### KI & Agenten Ich habe den MCP-Server von Hygraph gebaut und einen guten Teil der Agenten-Plattform dahinter. Inzwischen gehören auch Custom Agents dazu, die Kunden selbst einrichten. ### Lang laufende Arbeit Agenten rufen langsame und manchmal unzuverlässige APIs auf. Dafür nutze ich Temporal, damit Retries, Abbrüche und Neustarts an einer Stelle gelöst sind. ### Daten & APIs Viel GraphQL, SQL und Postgres über die Jahre, zuletzt Vektorsuche mit pgvector. Migrationen rolle ich am liebsten in kleinen Schritten aus. ### Führung Zwei Jahre habe ich das Core-Team bei Hygraph geleitet. Heute arbeite ich teamübergreifend als Staff Engineer: Design-Reviews, Rollout-Pläne und Mentoring. ## Roles - **AI & Backend Engineer**: Agenten, MCP-Tools und die Go- und TypeScript-Services, auf denen sie laufen. Viel Code schreibe ich immer noch selbst. - **Forward Deployed Engineer**: Nah an Kunden. Vom ersten Gespräch bis zum fertigen Feature in Produktion, und danach kümmere ich mich auch darum. - **Architekt**: Entscheiden, wo die Grenzen zwischen Services liegen, und wie man schrittweise dorthin kommt. - **Tech Lead**: Engineers coachen und Produkt und Technik helfen, sich auf das Nächste zu einigen. ## so baue ich agenten Ungefähr das passiert, wenn auf der Plattform, an der ich arbeite, ein Agent läuft. Der Großteil meiner Arbeit steckt in den Schritten rund um den Modellaufruf. 1. start: Ein Workflow-Schritt ändert sich, ein Webhook kommt rein oder jemand klickt im Editor auf „ausführen“. 2. queue: Temporal übernimmt. Jeder Agent hat einen Koordinator mit einer festen Zahl an Slots, damit ein großer Batch den LLM-Provider nicht überrennt. 3. think: Das Modell arbeitet mit MCP-Tools, aber nur mit denen, die für genau diesen Eintrag Sinn ergeben. Veröffentlichen gehört nicht dazu. 4. check: Vor dem Schreiben fragt der Agent, ob gerade jemand den Eintrag bearbeitet. Wenn ja, hält er sich zurück. 5. review: Alles, was ein Lauf geändert hat, landet in einer einzigen Version. Ein Mensch schaut drauf und entscheidet, ob sie live geht. ## ausgewählte arbeit Dinge, die ich in den letzten Jahren geleitet oder geprägt habe, meistens bei Hygraph. Was ich gebaut habe, ist nur die halbe Geschichte, deshalb steht auf jeder Karte auch die Entscheidung dahinter. Keins davon war ein Soloprojekt. ### Eine MCP-Schnittstelle für KI-Clients KI-Clients brauchten einen sicheren Weg in Kundenprojekte, statt einer neuen Integration für jeden Anwendungsfall. Ich habe den MCP-Server in Go aufgesetzt und die Regeln für neue Tools festgelegt: authentifiziert, auf ein Projekt begrenzt, validierte Eingaben und Fehlermeldungen, mit denen ein Modell etwas anfangen kann. Content-, Schema- und Migrations-Tools kamen danach auf demselben Vertrag dazu. entscheidung: Ein gemeinsamer Tool-Vertrag statt Integrationen pro Feature. Das bringt mehr Hebel, aber jedes Tool wird Teil der Sicherheitsgrenze der Plattform. Validierung ist also Pflicht. Tags: Go, MCP, Auth ### Robuste Ausführung für Agenten Agenten rufen langsame LLM-APIs auf und müssen Deployments und Neustarts überstehen, mit einfachem Request/Response klappt das nicht. Ich habe den Agenten-Service auf Temporal aufgesetzt und die Muster für Orchestrierung und Recovery festgelegt: ein Koordinator pro Agent, begrenzte Parallelität, Retries und Abbruch. Spätere Agenten nutzen genau diese Muster, statt eigene zu erfinden. entscheidung: Temporal als neue Abhängigkeit in Kauf nehmen, dafür bekommen wir robuste Retries, Queueing und Einblick, die wir sonst schlechter selbst gebaut hätten. Tags: Temporal, AWS, Go ### Custom Agents, denen man vertrauen kann Agenten, die Kunden selbst konfigurieren, bringen nur etwas, wenn man ihnen vertraut. Ich habe zuerst die Grenze definiert und sie dann über vier Services gebaut: Agenten-Konfiguration, Tool-Loop, Content-Versionierung und die Review-Oberfläche im Editor. entscheidung: Ein Agent darf nur den Eintrag ändern, auf dem er gestartet wurde, und nichts veröffentlichen. Alle Änderungen eines Laufs werden zu einer Version, die ein Mensch prüft. Tags: Agenten, MCP, Versionierung ### Agenten vs. Menschen im Editor Agenten sollen nicht in einen Eintrag schreiben, an dem gerade jemand arbeitet. Mein erster Entwurf hat dafür direkt das Redis des Editors aus dem Agenten-Service gelesen. Ich habe umgeschwenkt auf eine kleine API des Editor-Teams, damit das Team, dem die Daten gehören, auch entscheidet, was sie bedeuten. entscheidung: Bei Timeouts offen scheitern, damit ein Editor-Ausfall nicht alle Agenten stoppt. Erst im Shadow-Mode laufen lassen und schauen, was blockiert worden wäre, bevor es scharf geschaltet wird. Tags: Temporal, Redis, Rollouts ### Vektorfelder im CMS Ein neuer Feldtyp muss in Datenbank, Migrationen, GraphQL-Schema, SQL-Übersetzung und Editor dasselbe bedeuten. Ich habe die Arbeit in sieben einzelne Teile geschnitten, damit jede Schicht für sich reviewt und hinter einem Flag ausgeliefert werden konnte. entscheidung: Den Trade-off zwischen exakter und approximativer Suche für Nutzer sichtbar machen, statt ihn hinter einem Index zu verstecken, der still Treffer verpassen kann. Tags: pgvector, GraphQL, Aurora ### Leitung der Core-GraphQL-Plattform Zwei Jahre technische Ausrichtung für das Team hinter Hygraphs globaler GraphQL-API, zwischen Performance, Zuverlässigkeit und API-Stabilität. Dazu gehörten Edge-Caching mit feinerer Invalidierung, der Umzug auf Aurora und der Aufbau unserer On-Call- und Incident-Routinen. entscheidung: Riskante Infrastruktur Region für Region umstellen, mit Monitoring vorab, statt alles auf einmal umzulegen. Tags: GraphQL, Fastly, Aurora ## werdegang 2012 als Azubi angefangen, unterwegs Go lieben gelernt und jetzt bei KI gelandet. ### Hygraph (Remote, 2021 – heute) - Staff Engineer AI & Backend (2025 – heute): MCP-Server, Agenten-Runtime auf Temporal, Vektorsuche und die Infrastruktur darunter. - Staff Engineer Backend & Infrastructure (2024 – 2025): Content-Suche mit Berechtigungen, Autorisierung für Workflows, Autoscaling und Observability-Kosten im Griff behalten. - Engineering Lead · Core (2022 – 2024): Leitung des Teams hinter der GraphQL-API. Edge-Caching, Aurora, On-Call und viel Coaching. - Engineering Lead · Developer Experience (2021 – 2022): Wiederverwendbare Content-Komponenten über Datenmodell, API und Editor, während das Team schnell gewachsen ist. - Senior Backend Engineer (2021): Schema-Generierung umgebaut, sodass jedes Projekt nur noch ein gecachtes GraphQL-Schema braucht. ### TheyDo (Amsterdam · Remote, 2024) - Staff Engineer (2024): Große Mengen Kundenforschung importieren und mit LLMs Insights und Customer Journeys daraus ziehen. ### Qvest Digital (Deutschland, 2012 – 2021) - IT Consultant & Systems Architect (2020 – 2021): Architekturgruppe für die E-Commerce-Plattform eines großen Autoherstellers. - Product Owner & Systems Architect (2018 – 2020): Ansprechpartner des Kunden für zwei bis drei Teams, Prioritäten in technische Arbeit übersetzt. - Entwickler → Systems Architect (2012 – 2018): Go- und Java-Microservices für große Onlineshops. Go intern so lange unterrichtet, bis es alle benutzt haben. ## technologie - sprachen: Go, TypeScript, SQL, Rust, Java, Node.js - ki & agenten: Agents, pgvector, RAG, Embeddings, MCP, LLM tool loops - daten: Kafka, Aurora, PostgreSQL, SQS, Redis - apis & architektur: Event-driven, GraphQL, Microservices, gRPC, OPA - runtime & infra: Docker, Temporal, Fastly, Kubernetes, AWS, Pulumi, ECS/Fargate, CI/CD - observability & qualität: OpenTelemetry, Load testing, Distributed tracing ### wo ich es eingesetzt habe - Go: Eine MCP-Schnittstelle für KI-Clients; Robuste Ausführung für Agenten; Entwickler → Systems Architect @ Qvest Digital; Talk: Why Go?; Talk: The state of Kafka and Go; Talk: Reactive Go; Talk: Serverless Go - TypeScript: Staff Engineer AI & Backend @ Hygraph; Talk: Building an AI Agent with TypeScript and MCP - MCP: Eine MCP-Schnittstelle für KI-Clients; Custom Agents, denen man vertrauen kann; Staff Engineer AI & Backend @ Hygraph; Talk: Building an AI Agent with TypeScript and MCP; Talk: Building an AI Knowledge Base with MCP - Temporal: Robuste Ausführung für Agenten; Agenten vs. Menschen im Editor; Staff Engineer AI & Backend @ Hygraph - GraphQL: Leitung der Core-GraphQL-Plattform; Vektorfelder im CMS; Engineering Lead · Core @ Hygraph; Senior Backend Engineer @ Hygraph; Talk: Choosing a GraphQL Provider - PostgreSQL: Vektorfelder im CMS; Staff Engineer AI & Backend @ Hygraph - Redis: Agenten vs. Menschen im Editor - AWS: Robuste Ausführung für Agenten - Agents: Custom Agents, denen man vertrauen kann; Agenten vs. Menschen im Editor; Staff Engineer AI & Backend @ Hygraph; Talk: Building an AI Agent with TypeScript and MCP - LLM tool loops: Custom Agents, denen man vertrauen kann - pgvector: Vektorfelder im CMS; Staff Engineer AI & Backend @ Hygraph - Aurora: Vektorfelder im CMS; Leitung der Core-GraphQL-Plattform; Engineering Lead · Core @ Hygraph - Fastly: Leitung der Core-GraphQL-Plattform; Engineering Lead · Core @ Hygraph - Kafka: Talk: The state of Kafka and Go - Java: Entwickler → Systems Architect @ Qvest Digital - Microservices: Entwickler → Systems Architect @ Qvest Digital; Talk: Microservice quality - Event-driven: Talk: Reactive Go ## kurz gesagt ### Wer ist Dino Omanović? Dino Omanović ist Staff Engineer für KI- und Backend-Systeme und lebt in Bonn. Seit 2021 arbeitet er bei Hygraph, davor bei TheyDo und neun Jahre bei Qvest Digital. ### Worauf ist er spezialisiert? KI-Agenten-Plattformen und LLM-Tooling, MCP-Server (Model Context Protocol), robuste Workflows mit Temporal, GraphQL-APIs und PostgreSQL, meistens in Go (Golang) und TypeScript. Er hat sowohl selbst entwickelt als auch technisch geführt. ### Welche Rollen übernimmt er? Staff Engineering für KI und Backend, Forward Deployed Engineering nah am Kunden, teamübergreifende Architektur und Tech-Lead-Rollen. ### Arbeitet er remote? Ja. Seit 2021 komplett remote aus Bonn (MEZ), auf Deutsch und Englisch. ### Was hat er gebaut? Bei Hygraph: den Go-MCP-Server, über den KI-Clients in Kundenprojekten arbeiten, die Agenten-Runtime auf Temporal, von Kunden konfigurierbare Agenten mit menschlichem Review und Vektorfelder auf Basis von pgvector. Davor hat er zwei Jahre das Team hinter Hygraphs globaler GraphQL-API geleitet. ### Wo kann ich seine Talks sehen? Auf YouTube: Building an AI Agent with TypeScript and MCP (Hygraph-Livestream, 2025), Choosing a GraphQL Provider (GraphQL Conf 2022) und mehrere Go-Talks, darunter The state of Kafka and Go, Reactive Go und Serverless Go. Alle sind im Talks-Abschnitt verlinkt. ### Wie erreiche ich ihn? Am einfachsten per Nachricht auf LinkedIn (linkedin.com/in/dino-omanovic). Seinen Code gibt es auf GitHub (github.com/domano).