ddi
Made in the European Union
Consulting · booking through 2026 Q3

Plan-aware Java
done right.

Direct, code-level work with your engineers. No slide decks, no audits-for-the-sake-of-audits — just landing pricing-, quota- and tenant-aware injection in the codebase you actually have.

Author of the library 20+ years Java in production 🇪🇺 Independent · EU-based Reply within 2 business days
What I do

Six places where consulting moves the needle

Pick one focused area or combine them. The deliverable is always code in your repository — never a 40-page document nobody reads.

01

Pricing-tier extraction

Pull if (user.plan == PRO) branches out of your services and put them where they belong — into a resolver. We map your existing plan rules to ClassResolvers and land the refactor behind tests.

Best for: SaaS teams with plan logic scattered across services
02

Quota- & limit-aware design

Replace inline rate-limit checks with degradation impls (Throttled…, ReadOnly…) injected by a resolver. Cleaner code, deterministic behaviour, easier to test.

Best for: products with usage-based pricing
03

Multi-tenant routing

Tenant-specific implementations without copy-pasted services or per-tenant modules. Resolver reads the tenant context, hands out the right impl — works with your existing Spring or Quarkus stack.

Best for: B2B platforms with per-tenant customizations
04

Spring / Guice → DDI migration

Carve out a part of your codebase where you actually need runtime-dynamic DI — CLI tools, Lambda handlers, batch jobs — and run it on DDI without rewriting your main app.

Best for: teams with a small, hot module fighting their container
05

Test-strategy overhaul

Replace Mockito mountains with resolver-based test impls. Real types, real behaviour, deterministic test setup. We typically pair this with raising PIT mutation scores into the 80–90 % range.

Best for: teams whose tests pass while mutants survive
06

Architecture review

Pre-launch or pre-refactor look at your service: where pricing / role / tenant logic leaks into services, where DI is fighting the domain, where a small resolver layer would buy a lot of clarity. Written report plus walkthrough call.

Best for: teams planning a larger refactor
How it works

From first email to follow-up — four steps

1

Initial call (free, ~30 min)

Quick scope alignment. What's the codebase, what's the DI posture today, what plan/role/quota logic is bleeding into services. We decide together whether consulting is the right shape — or whether a self-service tour of the docs is enough.

2

Written proposal

Concrete deliverables, time estimate, fixed budget or hourly rate. You decide: one-shot review, defined sprint, or on-demand support.

3

Engagement

Pair-programming sessions, async PR reviews or workshop days — whichever fits your team. Output is your code in your repo plus a short written summary at the end.

4

Follow-up

One free 30-min check-in 4–6 weeks after delivery. Make sure the patterns stuck and answer any follow-up questions that came up during real use.

Engagement formats

Pick the shape that fits

📋

Code review

Fixed-scope review of an existing module or planned design. Written report plus walkthrough call.

Typically: 3–5 days
Most popular

Resolver sprint

1–2 weeks of focused refactoring — extracting plan/role/tenant logic into resolvers, landing the change behind tests, together with your team.

Typically: 1–2 weeks
📞

On-demand support

Retainer for ad-hoc questions, PR reviews, and refactor support. Slack, email, or PR comments.

Typically: monthly retainer
🎓

Workshop

On-site or remote workshop on policy-driven DI for your engineering team. Hands-on, code-driven, your codebase as material.

Typically: 1–2 days
Why me

Direct line to the author

1
Author of the library

I built DDI. I know its sharp edges and the design choices behind them, because I made them.

20+
years of Java in production

Long track record across enterprise systems — from small services to large platforms with strict audit and reliability requirements.

0
vendor agenda

Independent, EU-based. No platform upsell, no SaaS lock-in story. Sometimes the right answer is "stay with what you have" — and I'll say so.

Let's talk

Drop a short email

No long form. Send three things and I'll come back with a concrete next step.

  1. 1. A one-paragraph description of your application.
  2. 2. The current stack — JDK version, Spring / Quarkus / vanilla, where plan or tenant logic lives today.
  3. 3. What you'd like to achieve in the next 4–8 weeks.
contact@sven-ruppert.com

I usually reply within two business days.