I build software that solves my own problems.
Information Systems student from Cologne. I build websites, apps and automations that solve concrete problems - from productivity tooling to fueling for endurance athletes.
A few things I have built - from the first problem to a running app.
Projects
- Platforms (backend, web, iOS)
- 3
- Lines of Python (backend)
- ~16,100
- Lines of Swift (iOS)
- ~17,200
- Commits
- 269
- Database tables
- 13
- CI workflows
- 5
fuelivo
LiveFueling for endurance athletes - concrete strategies from a few inputs.
Endurance athletes have to take in carbohydrates, fluid and electrolytes deliberately in training and competition - too little causes a performance drop, too much or the wrong thing causes GI trouble. The right amount depends on many factors at once: duration, intensity, sport, heat, gut tolerance. Blanket rules of thumb like '60 g of carbs per hour' ignore that, generic nutrition apps track daily balances instead of sessions, and AI coaches hand out recommendations you can't reason about.
Everything - the idea, domain research, the calculation logic, design, backend, web frontend and the native iOS app. AI was a development tool here, not an autopilot.
- For the first time I combined a backend, a web frontend and a native iOS app in one project. The clean layering paid off with the second client: the logic was reusable, only the transport layer was new.
- Payments across two worlds - Stripe on the web and Apple StoreKit on iOS - behind a single entitlement service: one source of truth for feature flags.
- A versioned mobile API with OpenAPI and a contract check in CI is the point where 'backend and app drift apart' stops being a problem.
- The first project that grew beyond a single Python script with a README - including its own domain, DNS, CI/CD and deployment.
- Next time: one clear deployment path instead of Docker and Vercel in parallel, and shared types between backend and iOS earlier.
Aurelian
MVPDaily stoic reflection in under two minutes - grounded in your actual day.
Stoicism apps serve generic quotes with no bearing on everyday life, journaling apps demand too much input and feel like work, and AI reflection tools invent quotes - with philosophical sources that destroys credibility instantly. Ambitious users want a short, practical moment of clarity before the day: no to-do list, no coach tone, no made-up wisdom.
Everything end-to-end - product definition and PRD, a modular local-first architecture, the SwiftUI frontend, domain and application logic as a Swift package, curating the vetted quote database, the hardened Node backend endpoint for the AI generation, plus deployment, App Store preparation and test strategy.
- A port-based, modular architecture keeps product rules testable independently of SwiftUI and SwiftData - the domain layer depends on nothing and can be checked without an iOS simulator.
- Quote hallucinations are not a prompt problem but an architecture problem: solved with a deterministic selection policy that hands the AI only permitted candidates - the AI picks, it never invents.
- Moving generation from the client to a stateless server endpoint protects the API key, caps the cost (one output per user per day) and still allows a local offline fallback.
- Text-input latency on iOS is real: a dedicated investigation and buffering of the input kept the Today screen smooth.
DevBlueprint
LiveA reusable engineering setup for new projects - a professional process from commit one, with no lock-in.
Every new project starts without a process: the git workflow, quality gate, conventions and AI guardrails get reinvented every time or skipped entirely - especially solo. Running several AI sessions in parallel adds a second problem: the chats keep switching each other's branch. Ready-made frameworks and template repos only solve it at the price of permanent lock-in.
Everything - the idea, extracting the process from a real production codebase, the stack-agnostic core docs, the Bash CLI, the nine stack variants, the bats test setup and the agent integration (CLAUDE.md, --json, setup skill).
- A reusable setup must not be a framework: documentation-first, plain files and no runtime beat any template repo, because the project stays the owner and nothing is tied to DevBlueprint.
- The worktree-per-task approach is the point where parallel AI sessions stop pulling each other's branch out from under them - a single wt script carries the whole workflow.
- Separating a shared core from thin stack overlays (core/ vs. variants/) keeps nine stacks maintainable: you change the process in one place, and only the stack-specific bits live per variant.
- For an agent to operate a tool it needs machine-readable state (--json) and a dry run (plan == init --dry-run) - only then can it confirm reliably before writing.
- Applying the setup to itself (dogfooding) surfaced the gaps fastest.
Code, Sport, Sleep, Repeat.
I study Information Systems in Cologne and build the things I wish I'd had on the side. My biggest project so far is fuelivo, an app that turns a few inputs into a concrete fueling recommendation for endurance sport. I'm driven by planning ideas and carrying them all the way to a finished application.
Alongside my studies I do a lot of sport - hockey, running, the gym and whatever else I feel like. It helps me focus and pushes me to finish things properly.
Experience
- since October 2024current
Information Systems
University of Cologne
Data analysis, process optimization, software development, product management and AI applications - focused on working more efficiently with AI.
- since March 2025current
Working student
Institut der deutschen Wirtschaft
Work on a patent-database project: data analysis and process optimization.
Skills
- Languages & data
- Python
- Java
- SQL
- D3
- Practice
- App development
- Web development
- API work
- Process optimization
- Tools & topics
- Git
- Excel
- AI tools
- Local AI
- Product & process
- Process analysis
- Product thinking
- Data modeling
- Requirements
- Documentation
A year of commits, straight from GitHub - not guessed, not curated.