Christian Gutermann

Software Engineer · Scrum Master · AI Enthusiast

Bruchsal, Germany

10+ years of building software, from engineer to Scrum Master. I stay close to the tech and still write code myself. What really drives me, though, is getting a team behind one goal, clearing blockers out of the way, and making sure we build the right things right.

Scrum Master & Software EngineerCAS Software AG
Co-founder & CEOTumbleTree Studios UG

Get in touch

Scroll

Scrum
AI-assisted Development
Product Management
Team Leadership
Full-Stack Development
Facilitation
Product Design
Kanban
Mobile Development
Roadmapping
DevOps
Mentoring
Agile Delivery
Stakeholder Management

01By the numbers

10+
Years of software engineering
At CAS Software AG since 2015
11
People in my team
Grown from four as Scrum Master, across Germany and Hungary
10+
Active projects I am responsible for
Including their budgets
2
Bachelor theses supervised
DHBW Karlsruhe, 2023 and 2024

02Selected work

Products I have built, and what I actually did on them.

Enterprise software for German companies and institutions, and a mobile game I built end to end through my own studio.

Organisations I have built software for

Dropigon
Client
TumbleTree Studios UG
Role
Concept, development, release
Year
2026
A drop-and-merge puzzle game, free on the App Store and Google Play. Built entirely on my own.
Read the case study
The constraint
Dropigon started as a feasibility test: how much work is it really, taking an app all the way into the stores? And honestly, I had simply always wanted an app of my own to share with friends. All of it had to happen in the evenings, next to a full-time job and a young family. Anything that did not move the game toward release was cut.
What I decided
Flutter with Flame and its Forge2D physics for the game, Firebase for the global leaderboard, ads through AdMob and an ad-free purchase through the stores. AI sat in almost every step: Copilot as the constant companion in the code (later Claude Code, after Copilot cut its quota overnight), graphics from Midjourney with manual rework, and the entire soundtrack from Suno.
What changed
The first playable prototype took a few days. The finish took far longer. AI-suggested physics values sounded plausible but felt wrong in play, so I tuned drop speed and merge behaviour by hand, test round after test round. The game has been live on both stores since January 2026, and I know first-hand where these tools carry and where they stop.
Stack
- Flutter
- Dart
- Flame
- Firebase
- AI-assisted
- Mobile App
- App Store
- Google Play
Mein Bioland
Client
Bioland
Role
Project lead, software engineer
The member platform for Germany's largest organic farming association.
Read the case study
The constraint
Mein Bioland is a long-lived platform serving an association of farmers, processors and retailers. Most of the work is evolution rather than greenfield: every change has to land in a system people already rely on for their daily work.
What I decided
I own this project end to end, including its budget, and I am the direct line for the customer. When Bioland has a technical question, my phone rings, not a ticket queue. That also means scoping changes with them before they become specifications.
What changed
It is one of the ten-plus active projects I am responsible for, budget included.
Stack
- Java
- Angular
- REST
- Kubernetes
- Jenkins
SmartWe App Store
Client
CAS Software AG
Role
Main developer
A cloud marketplace where CRM customers find and install applications for their own workspace.
Read the case study
The constraint
SmartWe customers needed to extend their CRM without a developer and without a deployment. Installation had to be self-service, reversible, and safe to run against live customer data.
What I decided
As main developer I designed the install flow and how extensions plug into the platform.
What changed
The App Store is now the route through which SmartWe customers extend the product themselves.
Stack
- Angular
- REST
- Docker
SAMPlus
Client
Daimler Truck
Role
Software engineer
Configure, price and quote for commercial vehicle sales, still in use today.
Read the case study
The constraint
Specifying a commercial truck is a combinatorial problem: options constrain one another, the valid combinations keep changing, and a wrong quote costs real money.
What I decided
I worked on introducing the CPQ solution that brought configuration and pricing onto one system, so the rules live in one place rather than in the experience of individual salespeople.
What changed
Sales configuration and pricing run through it, and it is one of the projects I still carry responsibility for.
Stack
- Java
- REST
- React
- Azure DevOps
E-Invoice for SmartWe
Client
CAS Software AG
Role
Software engineer
Creating, storing and sending legally compliant electronic invoices from inside the CRM.
Read the case study
The constraint
E-invoices in Germany follow a legally mandated format with structured fields that the system on the other end has to parse. Get a field wrong and the invoice is rejected.
What I decided
We built invoicing into SmartWe itself rather than bolting on an export, so an invoice is created, stored and sent from the same place the customer record already lives.
What changed
SmartWe customers can issue compliant electronic invoices without leaving their CRM.
Stack
- Java
- Angular
- XRechnung
- REST
Two-factor authentication
Client
CAS Software AG
Role
Software engineer
A companion authenticator app and a second factor on the CRM login.
Read the case study
The constraint
A CRM holds a company's entire customer relationship. A password alone is a single point of failure for all of it, and a second factor on the login path is a change every user sees at their next sign-in.
What I decided
I built the second factor as a cross-platform mobile app issuing time-based one-time codes, and wired it into the existing login flow. The rollout got as much care as the code, because if the second factor annoys people, they work around it.
What changed
Accounts are protected by something beyond a password, and the login path stayed usable enough that it did not generate its own support load.
Stack
- React Native
- Mobile App
- Security
- TOTP

03Skills

What I work with, and how it connects.

Grouped by what it is for, not by how well I know it. The lines show which of these actually touch in day-to-day work. Select a node to see where.

AI

Engineering

Delivery

Leadership

Select a node to trace its connections

AI
- Claude
  My daily driver since Copilot cut its quota overnight, mid-Dropigon. The lesson stuck: build your workflow so you can switch tools at any time.
  - TypeScript — Engineering
  - Flutter — Engineering
- ChatGPT
  Research, data preparation, first sketches. The everyday end of AI, well before any code.
  - SQL — Engineering
- GitHub Copilot
  Constant companion through most of Dropigon's code, and completion in the editor at work.
  - Angular — Engineering
  - Git — Delivery
- Midjourney
  Dropigon's graphics, from the app icon to the unlockable colour schemes, generated and then reworked by hand.
  - Flutter — Engineering
  - Figma — Delivery
- LM Studio
  Local models, run on my own hardware rather than someone else's.
  - Self-hosted LLMs — AI
  - Docker — Delivery
- Self-hosted LLMs
  Digitally sovereign models for processing documentation, the subject of a bachelor thesis I supervised.
  - LM Studio — AI
  - Thesis supervision — Leadership
  - Docker — Delivery
- AI music
  Dropigon's entire soundtrack comes from Suno. A solo developer cannot hire a composer, so AI covered that part.
  - Flutter — Engineering
Engineering
- TypeScript
  - Claude — AI
  - Angular — Engineering
  - React — Engineering
- Angular
  The bulk of the frontend work in the Appfactory.
  - GitHub Copilot — AI
  - TypeScript — Engineering
- React
  - TypeScript — Engineering
- Flutter
  Dropigon, and the children's learning app in progress.
  - Claude — AI
  - Midjourney — AI
  - AI music — AI
  - Store releases — Delivery
- SQL
  - ChatGPT — AI
  - Vaadin — Engineering
- Vaadin
  - SQL — Engineering
- CPQ
  Configure-price-quote: rule engines where a wrong answer becomes a wrong offer. Daimler Truck's SAMPlus.
  - Client contact — Leadership
  - E-invoicing — Engineering
- E-invoicing
  Structured, legally compliant invoice formats, a domain where 'nearly correct' means rejected.
  - CPQ — Engineering
Delivery
- Scrum
  Every ceremony, plus cross-team formats at department level.
  - Facilitation — Leadership
  - Jira — Delivery
  - Kanban — Delivery
  - Mentoring — Leadership
- Kanban
  - Scrum — Delivery
- Jira
  - Scrum — Delivery
  - Roadmapping — Leadership
- Jenkins
  CI/CD pipelines that keep development and deployment fast.
  - Docker — Delivery
  - Git — Delivery
- Docker
  Containerised environments across the Appfactory projects.
  - LM Studio — AI
  - Self-hosted LLMs — AI
  - Jenkins — Delivery
- Git
  - GitHub Copilot — AI
  - Jenkins — Delivery
- Figma
  - Midjourney — AI
- Store releases
  App Store and Google Play submission, review and release management. Done alone, for a real product.
  - Flutter — Engineering
- Conceptboard
  Where the remote workshops actually happen, with part of the team in Hungary.
  - Facilitation — Leadership
  - Distributed teams — Leadership
Leadership
- Facilitation
  Dailies, plannings, retros, reviews, and cross-team sessions.
  - Scrum — Delivery
  - Conceptboard — Delivery
- Mentoring
  Onboarding new team members, and supervising two bachelor theses.
  - Scrum — Delivery
  - Team growth — Leadership
- Roadmapping
  Keeping development aligned with business goals, presented to department leadership.
  - Jira — Delivery
  - Client contact — Leadership
  - Budget ownership — Leadership
- Client contact
  Direct line to customers from project start.
  - CPQ — Engineering
  - Roadmapping — Leadership
- Team growth
  Four people to eleven, across two countries.
  - Mentoring — Leadership
  - Distributed teams — Leadership
- Thesis supervision
  Two bachelor theses at DHBW Karlsruhe. Supervising research, not just reviewing code.
  - Self-hosted LLMs — AI
- Budget ownership
  Ten-plus active projects, budgets included.
  - Roadmapping — Leadership
- Distributed teams
  Germany and Hungary. Trust at a distance takes deliberate work.
  - Conceptboard — Delivery
  - Team growth — Leadership

04Timeline

From software engineer to Scrum Master, still writing code.

Oct 2025 — Now
Ongoing
Co-founder & CEO
TumbleTree Studios UG
Co-founded alongside my day job, mainly as a way to keep developing on real projects. I built and released our first game, Dropigon, on my own. A second product, a learning app for the whole family, is in development.
Co-founded the studio as a side venture, to keep growing on our own gaming and learning apps rather than only on someone else's roadmap.
Took Dropigon through the entire product lifecycle single-handed: concept, prioritisation, development, and launch on the App Store and Google Play in January 2026.
Used AI throughout the build: code, graphics, and the soundtrack.
Currently building the second product the same way: a learning app for the whole family.
Apr 2021 — Now
Ongoing
Scrum Master & Software Engineer
CAS Software AG · Appfactory
Took on a newly formed team and grew it from four people to eleven across Germany and Hungary. I own the roadmap, present it to department leadership, keep the direct line to customers, and still write code. That is what lets me talk to developers as a peer.
Took the Scrum Master role for a newly formed team, introduced agile practice, and built a working foundation for collaboration and delivery.
Stayed a software engineer in the same team, to keep close to the technical realities rather than managing them from a distance.
Grew and scaled an international team from four developers to seven developers, three working students and a QA tester, across Germany and Hungary.
Completed a two-year internal leadership programme alongside the role.
Own project roadmaps that tie development to business goals, and present them regularly to department leadership.
Direct customer contact from project start: gathering requirements and making sure the technical need is genuinely understood.
Supervised two bachelor theses, including one on configuring and evaluating a self-hosted, digitally sovereign large language model for processing documentation.
Responsible for more than ten active projects and their budgets, among them Bioland, Daimler Truck and Deutsche Bahn Energie.
Run every Scrum ceremony, and facilitate department formats such as cross-team reviews.
May 2020 — Apr 2021
Completed
Software Engineer
CAS Software AG · Appfactory
Frontend work, mostly Angular, plus Docker and the CI/CD pipelines. Mentored new joiners and stood in as deputy Scrum Master, which is how the later role started.
Worked across a range of frontend projects, predominantly Angular, with a clear focus on modern web application development.
Containerised environments with Docker and maintained the CI/CD pipelines to speed up development and deployment.
Mentored several new team members through onboarding and knowledge transfer.
Took on deputy Scrum Master duties: facilitating ceremonies and holding the team's organisation together in the Scrum Master's absence.
Oct 2018 — May 2020
Completed
Software Engineer
CAS Software AG · Education
Full-stack work on student administration systems for universities: enrolment, grades, and communication with students. Helped modernise the department's technology stack.
Started my engineering career in full-stack work, building and maintaining frontend and backend components for web applications.
Specialised in student administration systems for universities: administrative processes, enrolment, grade management and student communication.
Contributed substantially to modernising the department's technology stack, introducing current frameworks and tooling for better performance and a more intuitive interface.
Started running smaller team ceremonies like dailies and retrospectives on my own initiative, which improved how the team communicated.
Sep 2015 — Oct 2018
Completed
BSc Computer Science · Dual studies
DHBW Karlsruhe & CAS Software AG
Three years of writing production code and sitting exams in the same week. Theory and practice were never separate things for me. Graduated with a 1.7.
Three-year dual degree, 210 ECTS, with continuous hands-on development work in the department throughout.
Built a UI test automation framework to replace an expensive licensed tool. It saves several thousand euros a year and is still in production today.
Wrote my bachelor thesis on a framework prototype for Angular apps embedded in SmartWe, a modular CRM cloud platform.
Graduated with 1.7.

05How I work

Four things I believe about how software gets built.

I learned all four the hard way, on real projects.

What a customer wants is mostly not what they need
Working out the difference is the actual engineering. A request arrives already shaped as a solution, and building exactly that is the easy path. It just leaves the real problem where it was. So I stay in the conversation until the need underneath is clear. When Bioland or Daimler Truck has a technical question it comes to me directly, and it is rarely the first answer that turns out to be the one worth building.
A standup that reports status is a meeting, not a tool
A standup is for the day ahead: everyone knows their plan, the plan is actually good to go, and whatever stands in its way gets cleared up front, whether that is an open question or an impediment. Reporting yesterday's status just drops that goal. And trust cuts the other way too: “I have been stuck since Monday” should never have to wait for a standup. I want to hear it on Monday.
You only learn where AI stops helping by shipping with it
I did not learn the limits of these tools from slides. I built and released a game with them (code, graphics, even the music) and learned which parts hold up under real deadlines and which are a waste of an evening. The interesting work now is getting requirements sharp enough that an agent can actually act on them.
Most engineering problems are coordination problems
This is what the last ten years keep coming back to, and the reason I moved from writing software to being responsible for how it gets written. When a project stalls, it is rarely because nobody could solve the technical problem. Usually two people each solved half of it. Or someone spent a week waiting on an answer no one knew they owed. Or everyone was working from assumptions that were never said out loud. Fix how the work is coordinated and a surprising number of technical problems stop happening in the first place.

06Currently

What I am building right now.

Two projects in the evenings: one with the studio, one on my own. Neither is finished yet.

TumbleTree App
In development
TumbleTree Studios UG
A kid-safe learning app built around games and stories, with difficulty that adapts to the child. The second TumbleTree product.
Same approach as Dropigon: Flutter, AI in the loop for code and assets, and small evening increments.
- Flutter
- Firebase
- Flame
- AI-assisted
The second product
The TumbleTree App is the studio's second product: a kid-safe learning app for the whole family, built around games and stories, with difficulty that adapts to the child. Same working model as Dropigon: evenings, small increments, AI in the loop for code and assets.
Built to work offline
The app is offline-first: everything lives in a local database on the device, and a sync service reconciles with the cloud when a connection is there. A kid on the back seat of a car does not care about coverage.
Built to fit into evenings
The development flavour runs entirely without Firebase: mock sign-in, local data, no cloud setup. An evening session starts in seconds. Real screenshots will follow once the app looks like something. Until then the architecture is the honest picture.
How it is put together
Presentation
Screens & Flame games
Riverpod state
Domain
Entities
Repository interfaces
Data
Drift · local database
Source of truth
SyncService
Firebase
Auth
Firestore
App Check
Clean Architecture: dependencies only point inward, and the dev flavour runs without any cloud at all.
Connections
- Screens & Flame games → Riverpod state
- Riverpod state → Repository interfaces (inward only)
- Repository interfaces → Drift · local database (implemented in data)
- Drift · local database → SyncService (queued changes)
- SyncService → Firestore (when online)
- Auth → Screens & Flame games (sign-in)
Tradebot
Paper trading
A trading bot for Interactive Brokers: AI models summarise news and fundamentals, a deterministic scoring algorithm makes the actual buy or sell decision.
Only the execution layer may talk to the broker (a check fails the build if anything else tries), and every position gets a stop order at the broker, so it holds even if the bot crashes. Backtests replay ten years of prices in about a minute. Still paper trading: simulated money until the results justify real money.
- Python
- FastAPI
- React
- TimescaleDB
- Groq
- Gemini
Why this exists
I wanted to know whether a bot can analyse stocks on its own and trade on the result, with decision-making I can actually read. So the AI models summarise news and figures and explain their view in plain language. The buy or sell itself comes from a fixed, traceable algorithm that adds up price signals, fundamentals and news sentiment.
What worked and what didn't
The AI wiring was the fast part: fetching data, sending it to the APIs and sorting the answers all ran smoothly from the start. And because analysis and execution are strictly separated, I could experiment freely on the AI side, even switch providers, without the trading logic ever noticing.
The first AI analyses themselves were poor. They matched neither the actual price action nor what real analysts said about the same stocks. Most of the fix was better input data. The prompt came second.
Tested by pulling the plug
I tested the safety layers with chaos drills: pulling the ethernet cable mid-position, killing the bot mid-order. Those drills found real bugs while the money was still fake.
If I started again, I would build the checks that compare a result against something real before building the feature itself. And with money involved, the rule stands: the AI explains. It never decides.
- Analysis view
- Paper trading
- Backtesting
How it is put together
Ingest
Prices · News · Fundamentals
Politician & insider trades
AI
Groq & Gemini
Explanation only
Analysis dashboard
Analysis
Scoring engine
Deterministic
FinBERT sentiment
Backtest
Replay
Ten years ≈ one minute
Simulated broker
Strategy
Trading strategies
Execution
Risk engine
Order router
Broker
Interactive Brokers
Stop orders live here
Only the execution layer may talk to the broker. A check fails the build if anything else tries.
Connections
- Prices · News · Fundamentals → Scoring engine
- Politician & insider trades → Scoring engine
- FinBERT sentiment → Scoring engine
- Scoring engine → Groq & Gemini (recommendation)
- Groq & Gemini → Analysis dashboard
- Scoring engine → Analysis dashboard
- Scoring engine → Trading strategies (signal)
- Replay → Trading strategies (same logic)
- Trading strategies → Simulated broker (test run)
- Trading strategies → Risk engine (order intent)
- Risk engine → Order router
- Order router → Interactive Brokers

07Off the clock

The rest of the week

Mali, a black and white border collie, sitting on a tree stump in a sunlit orchard meadow.

Most weeks it's out with Mali, our border collie: training or a proper hike. The best way I know to stay active together and clear my head.

Christian with his wife and their young daughter, smiling, among tropical plants.

Since April 2025 we are a family of three. Our daughter keeps my wife and me properly on our toes. Honestly, it is the best chapter of my life so far.

Build schematic of a self-assembled gaming PC: open tower with GPU, tower cooler, fans and airflow lines.

Gaming is where I switch off and push myself at the same time: there is always one more mechanic to master or a smarter strategy to find. The hardware is part of it, and I plan and build my gaming PC myself.

08Contact

Say hello.

Always happy to talk about software, teams, or what AI is actually good for. Email reaches me fastest.

christian.gutermann95@gmail.com

Christian Gutermann

By the numbers

Products I have built, and what I actually did on them.

Dropigon

Stack

Mein Bioland

Stack

SmartWe App Store

Stack

SAMPlus

Stack

E-Invoice for SmartWe

Stack

Two-factor authentication

Stack

What I work with, and how it connects.

AI

Engineering

Delivery

Leadership

From software engineer to Scrum Master, still writing code.

Co-founder & CEO

Scrum Master & Software Engineer

Software Engineer

Software Engineer

BSc Computer Science · Dual studies

Four things I believe about how software gets built.

What a customer wants is mostly not what they need

A standup that reports status is a meeting, not a tool

You only learn where AI stops helping by shipping with it

Most engineering problems are coordination problems

What I am building right now.

TumbleTree App

The second product

Built to work offline

Built to fit into evenings

How it is put together

Tradebot

Why this exists

What worked and what didn't

Tested by pulling the plug

How it is put together

The rest of the week

Say hello.