Project Partner

The most common engagement format. I join a project as a partner, not a contractor. The difference is fundamental: a contractor delivers the spec and signs the act. A partner is accountable for the system working and solving the business problem. If it turns out mid-project that the original spec is wrong — a contractor continues per plan; I stop and redesign.

In practice: a company comes with a task — say, launching a CRM ecosystem for a bank. I start with an assessment: understanding how the business works, where clients are being lost, what systems already exist. I design the architecture, define phases, assemble the team. I run the project by milestones: every 2–4 weeks — a demonstration of working functionality to the client. Not a progress report, but a working module you can touch.

The team is assembled for the specific project from verified specialists. No inflated headcount, no people “on the bench.” Every person on the team is needed, everyone knows their area of responsibility. If the client has their own developers — I integrate them, not replace them. The goal is not to create dependency on me, but to hand over a working system and the knowledge to run it.

The project doesn’t end with a sign-off act. After launch — 1–2 months of stabilization where I’m available for questions, fixes, and fine-tuning. The client team is trained, documentation transferred, runbooks described. The client can live without me — that’s the success criterion.