The problem
Most IT consultants start implementing before they understand.
The moment you describe what you need, most consultants are already deciding how to build it. They’re pattern-matching your situation to the last five engagements, mentally assembling a stack, and half-writing a proposal. Your specific context — the constraints, the history, the things that were tried and failed — gets filtered through the lens of what they already know how to sell.
This isn’t incompetence. It’s the natural incentive structure of billing by the hour or project. The faster they move to implementation, the sooner the work begins. Slowing down to question whether the implementation is the right one costs them time they can’t bill.
The result is systems that technically work but don’t quite fit. Integrations that required workarounds from day one. Platforms chosen for the wrong reasons. Technical debt that arrives with the invoice.
My approach is structurally different. The diagnostic phase isn’t a formality before the real work starts. It’s where the most important decisions get made. Sometimes the conclusion is that the project as described should be scoped differently, executed in a different order, or not done at all yet. That’s not a failure — it’s the value.
What I build
Architecture, integration, and advisory — in the right order.
- Architecture review and technical debt assessmentCurrent state mapping — what you're running, how it's connected, where the hidden risks are, and what the actual maintenance burden looks like before anything new gets added
- Tool selection and vendor evaluationIndependent assessment of whether a platform or tool genuinely fits the need — including the constraints nobody puts in the marketing material: data residency, export limitations, pricing at scale, GDPR compliance posture, and how the vendor behaves when you want to leave
- CRM and marketing automation implementationZoho One stack implementation — CRM, Campaigns, Books, Flow — with correct German accounting configuration (SKR03, IST-Besteuerung), GDPR-compliant double opt-in pipelines, and Deluge automation that actually works reliably rather than having race conditions at 2am
- FluentForms → CRM → email pipeline architectureGDPR-compliant form-to-CRM flows with race-condition-free orchestration, Contact-level segmentation anchors, and reliable double opt-in sequences — designed to survive edge cases and concurrent submissions
- Analytics and tracking architecturePrivacy-first analytics setup using PostHog or Matomo — server-side where appropriate, no cookie consent dependencies for basic analytics, correct subscriber identity bridging between tools
- Infrastructure rationalisationCutting the number of tools, reducing the number of SaaS subscriptions, and eliminating the integrations that create more problems than they solve — not everything that can be connected should be
- Pre-implementation challenge sessionsA structured conversation before a significant IT decision — buying a new platform, migrating a system, rebuilding infrastructure — designed to stress-test the plan and surface assumptions before they become expensive mistakes
Real examples
What this looks like in practice.
Example
Zoho One stack built for German SME reality
A solo operator running andredaus.com and LittleBig.Co needed a CRM and email automation stack that handled two distinct brands, German accounting requirements, and GDPR-compliant lead capture — without the data residency problems of US-based marketing platforms. Implemented Zoho One with separate CRM pipelines per brand, SKR03 chart of accounts in Zoho Books with IST-Besteuerung, ZeptoMail for transactional email, and a FluentForms → Zoho CRM → Zoho Campaigns double opt-in pipeline. The automation is Deluge-based with explicit race-condition handling — duplicate submissions and rapid sequential form fills don't produce duplicate contacts or missed opt-in confirmations.
Example
Stopping a platform migration that was already in motion
A business had committed to migrating from their current e-commerce platform to a new one, had already started evaluating developers, and brought me in to oversee the technical side. During the diagnostic phase it became clear that the migration was being driven by frustration with one specific feature — not a fundamental platform problem. The new platform had its own version of the same limitation, plus three new constraints that would surface post-migration. The migration was paused. The original platform's limitation was worked around with a targeted plugin. That conversation cost a fraction of what the migration would have.
Example
Analytics that don't require cookie consent for basic usage
A content-led WordPress site was running Google Analytics and seeing significant opt-out rates from cookie consent banners, making the traffic data unreliable. Migrated to a self-hosted Matomo instance with server-side tracking for core metrics — no cookies required for basic visitor analytics, cookie consent banner simplified to only cover advertising-related functions. Traffic data became usable again. Implemented FluentCRM subscriber ID bridging so email campaign conversions could be tracked without cross-site cookies.
Not right for
Who this doesn't suit.
- Businesses that have already decided on the solution and want someone to execute without questioning it
- Projects where the diagnostic phase is seen as a delay rather than the point
- Organisations that equate speed of implementation with quality of outcome
- Any engagement where "we've always done it this way" is an argument that ends conversations