Sven Habex

How I work

1. Ownership

   End-to-end ownership

   From the first conversation to running software: scoping a feature with the business, modelling the data, building the API and the interface, and releasing it.

   Product thinking · Stakeholder communication · End‑to‑end delivery

   For example

   A thin working slice early over a complete spec up front.

   Real feedback beats assumptions, and it shows where the hard parts are.

2. Architecture

   The right decision for the circumstances

   There is rarely one correct architecture, only the right one for this team, budget and timeline. Making the trade-offs explicit means everyone knows why a choice was made, and it can be revisited when the circumstances change.

   Trade‑off analysis · Modular design · Explicit boundaries

   For example

   A modular monolith over microservices.

   Until team size or scale makes the split pay for its operational cost.

3. Domain-driven design

   Software shaped around the business

   It starts with a ubiquitous language: the same words in conversations with the business as in the code. Bounded contexts, aggregates and domain events then keep complex systems understandable, and event-driven messaging decouples modules, so one part can change without breaking the rest.

   Ubiquitous language · DDD · Event‑driven architecture · Domain events · Queues & background jobs

   For example

   A rich domain model over plain CRUD everywhere.

   Where the business rules are complex. Where they are not, CRUD is the better tool.

4. Delivery

   Shipping is part of the job

   Automated pipelines, containerised deployments and infrastructure as code make every release routine. In regulated environments, with the traceability and audit trail to prove it.

   CI/CD · Docker · Terraform · Azure DevOps · GitLab · Azure

   For example

   A pipeline on day one over automating after the first release.

   It is never cheaper to set up, and every change after it ships safer.

5. AI

   Faster with AI, without losing quality

   Agents and LLMs are part of the daily toolkit to explore, scaffold and review faster, and to build with: RAG and multi-agent systems. Tests, types and code review still decide what ships.

   Coding agents · LLM APIs · RAG · Multi‑agent systems

   For example

   Letting AI draft the first version over writing everything by hand.

   But never at the cost of tests, review or code the team can maintain.

6. Learning

   Always getting better at the craft

   I actively follow new tools and features and try them out myself, so I can judge whether they are worth applying in other projects. I also enjoy learning from colleagues, and sharing what I know just as much. Through code reviews, coaching team members or solving a problem together, the whole team gets stronger.

   Following new tools · Knowledge sharing · Learning from colleagues · Coaching

   For example

   Sharing knowledge with the team over solving everything myself.

   That way the knowledge doesn’t depend on one person.

Have something that needs to be built properly? Let’s talk.