Engagement Model
Engagements are structured through defined responsibility tiers. Expanding responsibilities beyond the agreed tier constitutes a contractual scope change and requires an explicit tier upgrade.
Tier I — Senior Engineer
Stable extended-team contribution within a defined scope.
- Feature development within an agreed scope
- Code ownership inside existing architecture
- Architecture contribution (non-mandate)
- No team management
- No release ownership
Tier II — Technical Lead (Scope-bound)
Technical alignment under a defined mandate, without implicit operational expansion.
- Architecture direction and technical decisions within a mandate
- Code reviews, governance, technical quality bar
- Cross-team technical alignment (interfaces, contracts)
- No 24/7 firefighting expectation
- No implicit operational overload
Tier III — Strategic Platform Mandate
Time-bound premium mandate for platform-level stability and modernization.
- System redesign and modernization strategy
- Migration strategy and risk containment
- Release stabilization and governance
- CI/CD restructuring (mandate-driven)
- Technical debt containment as an operational strategy
Tier IV — Module Ownership Mandate
End-to-end delivery of a defined module or feature slice, owned as a mini-engagement.
- Clear module boundaries and interfaces (contracted scope)
- Backlog ownership for that slice (refinement, sizing, delivery plan)
- Quality gates: tests, CI checks, release notes for the module
- Handover pack: docs, runbook, and knowledge transfer
- Best fit when the client can delegate a bounded area and expects accountable delivery
Scope clause
Expansion of responsibilities beyond the agreed tier constitutes a contractual scope change. Tier changes are agreed explicitly before responsibility expands.
No agency rotation
- Direct engineer communication
- No staff changes every 6 months
- No hidden junior substitution
- Explicit responsibility boundaries
B2B via Malit d.o.o. • remote-first • EU/DACH • Angular & Java only.
Open contract model