Cloud Orchestrator — open project
A distributed orchestrator for service instances — nodes find each other, work moves between them, and a failed machine costs no downtime.
- Kotlin
- Netty
- Coroutines
- Protocol design
- +1
maybecode.dev
I build software
that holds up.
Distributed systems, backend services and tools — mostly in Kotlin and Java, with a preference for clear boundaries between the parts.
- Focus
- Distributed systems
- Working in
- Kotlin & Java
- Currently
- Orchestration without Kubernetes
Selected work
What I am building
Three projects that show how I cut systems apart — from a distributed cluster down to a small tool that does exactly one thing.
YAML Editor — open project
A desktop editor for YAML and JSON that shows the mistakes configuration files hide — tabs, duplicate keys, values two parsers read differently.
- Kotlin
- Compose Desktop
- Gradle
- Parser design
ytwav — open project
A command line tool that turns a source into a cleanly named lossless WAV file by orchestrating yt-dlp and ffmpeg properly.
- Java 21
- ProcessBuilder
- ffmpeg
- yt-dlp
Toolbox
What I work with
Not a contest for the longest list. These are the things I reach for often enough to know when they are the wrong choice.
Languages
- Kotlin
- Java
- TypeScript
- SQL
- Bash
Backend
- Netty
- Coroutines
- Spring Boot
- REST
- PostgreSQL
- Redis
Frontend
- React
- Astro
- Compose Desktop
- Vite
- CSS
Tooling
- Gradle
- Docker
- Git
- JUnit
- GitHub Actions
About
Short version
I am maybecode, a developer based in Germany. The part I enjoy most is where a system stops being a single program: several services, several machines, and the question of what happens when one of them falls over.
Most of what is here started from curiosity rather than a brief. When I want to know how something works, I build it — and usually learn more about the decisions behind the originals than any documentation would have taught me.
This site runs without trackers, cookies or third-party services. What is here is here because I want to show it.
- 01
Boundaries first
Modules get sharp interfaces before they get features. Whatever should be extractable later must not read across today.
- 02
Fail loudly and early
A bad configuration should surface at startup, not weeks later in production. Error messages say what to do about it.
- 03
Nothing for its own sake
Every dependency and every abstraction has to justify itself. Fewer moving parts means fewer things that can break.
- 04
Done means tested
A feature counts as finished once tests cover the interesting case — not just the happy one.
Contact
Something to discuss?
Questions about one of the projects, an interesting problem, or a note that I have got something wrong somewhere — do write.
Usually a reply within a few days. No newsletters, nothing passed on.