How I Structure Technical Consulting Engagements

The Philosophy

When a client says "I need to migrate to Shopify," the instinct of a developer is to start migrating. The instinct of a consultant is to ask: "Why do you think that?"

One engagement began with exactly that question. The client had watched competitors move to Shopify and assumed the platform was the differentiator. The actual diagnosis revealed the gap was in marketing (traffic generation, newsletter automation, ad funnel optimization) rather than technology. But the migration still made sense, for a different reason: it would free the founder's limited bandwidth from infrastructure maintenance and redirect it toward the marketing work that would actually move the needle.

That reframe changed the entire project. Instead of a "migration project," it became a "business modernization engagement" with the migration as one component among five modules spanning infrastructure, operations, integrations, and growth.

Engagement Structure

Discovery before proposals. The first interaction was an in-person meeting covering workflow, team structure, competitive landscape, pain points, and aspirations. No pricing was discussed until the problem was understood. When a client has a history of negative experiences with previous technical partners, trust needs to be built before any technical access is exchanged.

Phased delivery with soft milestones. UAT checkpoints were defined, each gating a set of deliverables. But these were structured as "show and tell" sessions, not contractual gates. The relationship runs on communication cadence, not penalty clauses.

Billing that scales with value. Starting at a lower rate and scaling as scope expands. Platform costs absorbed during trial period and billed only after launch. No surprises. Every cost communicated before incurred.

Ownership stays with the client. All accounts provisioned under the client's credentials. All code in version control. All DNS and domain registrations in the client's name. If the engagement ends, the client walks away with everything.

Key Principles

Scope discipline over scope creep. The temptation in early engagements is to overdeliver by expanding scope. The discipline is to overdeliver within scope. When ambition outpaced runway relative to deadlines, the response was to flag it, re-prioritize, and protect the commercial milestone over feature completeness.

Build for the operator, not the developer. Every technical decision was filtered through: "Can the client, who is not a technical user, manage this?" If the answer was no, the solution was either simplified or wrapped in a dashboard interface that abstracted the complexity.

Transparent about trade-offs. When the client asked whether to stay on WordPress or move to Shopify, the response wasn't a recommendation. It was a comparison document with pros, cons, and the honest admission: "This is ultimately a business decision, not a technical one." The consultant's role is to illuminate the decision space, not to make the decision.

Communication as a deliverable. Weekly updates. Batched questions. Meeting the client where they are, not where the consultant is comfortable.

Illustrated through a real engagement. See also: Platform Migration and Edge Admin Dashboard.