A sanitized engineering case study in event-driven customer acquisition.
Kevin Doherty
EDGE | AGENCY · AI Systems Engineer · Automation Architect · Full-Stack Product Builder
Portfolio boundary: This repository is a public, high-level case study—not the production codebase. It intentionally excludes implementation source, production URLs or endpoints, credentials, secrets, internal workflow definitions, request or webhook payloads, database schemas, proprietary business logic, and commercial formulas. The architecture shown is conceptual and is not a deployment map.
I designed and built a production-grade lead generation and customer acquisition platform that connects a modern marketing experience to lead capture, payment processing, event validation, CRM integration, enrichment, automated outreach, and administrative reporting.
The system is presented here through its architecture, engineering trade-offs, operational goals, and lessons learned. It demonstrates how I approach an end-to-end product problem: separate responsibilities, treat external events as untrusted until verified, coordinate asynchronous work, and make operational status visible—without exposing the implementation that powers a live business.
My role: AI Systems Engineer · Automation Architect · Full-Stack Product Builder
Project type: Production platform, documented as a sanitized portfolio case study
Primary themes: Event-driven design · API integration · workflow automation · reliability · operational visibility
Businesses were manually collecting leads, tracking payment status, and managing follow-up across disconnected tools. The handoffs made it harder to keep customer context current, confirm transaction state consistently, coordinate timely outreach, and understand operational status in one place.
I designed and built an event-driven customer acquisition platform that connects lead capture, payment processing, webhook-driven event verification, CRM automation, enrichment, email follow-up, and administrative reporting. The system coordinates these stages through clear service boundaries and automated workflows while keeping payment verification and downstream side effects explicit.
This portfolio describes the system’s responsibilities and design rationale only. It does not expose the internal rules, endpoint contracts, event formats, data structures, or production workflow implementation.
| Product capability | Engineering concern addressed |
|---|---|
| Lead capture | Convert a visitor’s intent into a structured, consent-aware acquisition process. |
| Payment processing | Integrate a third-party payment provider without treating a browser redirect as proof of settlement. |
| Event verification | Validate provider-originated events before triggering downstream business actions. |
| CRM integration and enrichment | Keep customer context useful and consistent across connected systems. |
| Automated outreach | Coordinate follow-up through configured email automation with clear operational boundaries. |
| Administrative reporting | Give operators a consolidated view of system activity and business-process status. |
| Workflow automation | Reduce avoidable manual handoffs across the customer acquisition journey. |
The diagram below describes logical responsibilities and the high-level flow of information. It deliberately omits network topology, endpoints, event schemas, storage layout, internal rules, and implementation-specific workflow details.
Flow: Visitor → Marketing website → Lead capture → Payment processing → Event verification → Business logic and orchestration → CRM and enrichment → Automated outreach → Administrative reporting.
The editable, high-level diagram source is diagrams/architecture.dot.
| Layer | Technologies | Responsibility in the case study |
|---|---|---|
| Edge application and integration | Cloudflare Workers | Lightweight, globally distributed request handling and integration boundaries. |
| Edge data capability | Cloudflare KV | A managed edge data primitive for suitable low-latency, non-relational use cases; exact keys and data model are intentionally not disclosed. |
| Application services | Python | Supporting business-process and integration tasks where a general-purpose service runtime is appropriate. |
| Service contracts | REST APIs and webhooks | Explicit synchronous and event-driven boundaries between the web experience, platform services, payment provider, CRM, and supporting services. |
| Payment provider | PayPal integration | Third-party payment processing with a separate verification step before downstream fulfillment. |
| Communication | Email automation | Event-coordinated customer follow-up. Provider configuration and message content are not included. |
| Product experience | Modern web frontend | Responsive customer-facing acquisition experience and an administrative reporting surface. |
| Engineering workflow | GitHub | Version control, reviewable change history, and a foundation for automated delivery checks. |
This stack summary is intentionally descriptive. It is not an exhaustive bill of materials, dependency list, deployment manifest, or disclosure of production topology.
Payment providers and distributed integrations can redeliver notifications, while retries may occur after partial success. The platform treats duplicate delivery as a normal condition and is designed to avoid repeating consequential business actions when processing the same logical event more than once. Specific identifiers, persistence strategies, and deduplication rules remain private.
A browser redirect or client-side confirmation is not equivalent to verified payment. The platform distinguishes the customer-facing payment experience from provider-event validation and downstream progression, reducing the chance that an untrusted or incomplete signal advances the acquisition process.
Lead capture, payment processing, CRM enrichment, and email automation operate across different systems and failure boundaries. An orchestration layer coordinates responsibilities and makes the flow easier to reason about without coupling every integration into one opaque component.
Automated processing still needs an operational view. Administrative reporting brings process status and relevant outcomes into a more coherent workspace so operators can monitor activity and identify work that needs attention without relying on ad hoc manual checks.
Delayed events, timeouts, and temporary service failures are expected in distributed systems. Retry and recovery behavior are treated as design requirements, with visibility into processing outcomes; production-specific policies and implementation details are intentionally excluded from this public case study.
- Verify at trust boundaries. Treat client-side state as context, not authoritative payment confirmation; verify relevant provider events before consequential downstream work.
- Separate orchestration from integration details. Keep cross-system coordination distinct from provider-specific adapters so changes can be bounded and reviewed.
- Design for at-least-once realities. Assume asynchronous delivery can repeat or arrive at inconvenient times; define safe duplicate handling and observable recovery paths.
- Use the edge where it fits. Apply Cloudflare Workers for lightweight request handling and integration boundaries; reserve other service work for the runtime and operational needs it actually requires.
- Choose storage by access pattern. Use Cloudflare KV only for suitable workloads, and avoid treating an edge key-value store as a substitute for every persistence requirement.
- Make operations a product feature. Include an administrative reporting surface and useful process status instead of relying exclusively on logs or engineering intervention.
- Keep the public artifact abstract. Share the reasoning and system shape; do not publish live endpoints, schemas, payloads, credential formats, commercial rules, or production code.
The platform’s value is in joining formerly separate steps into a coherent acquisition operation. At a qualitative level, the design supports:
- Fewer manual handoffs by coordinating capture, verification, CRM context, and follow-up through automated workflows.
- More dependable processing by distinguishing payment initiation from verified payment events and planning for duplicate or delayed delivery.
- A more consistent customer journey through connected lead capture, enrichment, and timely outreach.
- Better operator visibility through centralized administrative reporting and clearer process status.
- A more adaptable foundation because external services and business-process stages meet at explicit integration boundaries.
No revenue, conversion, cost-saving, throughput, or latency figures are claimed in this public case study. Quantitative results are omitted unless independently approved for disclosure.
Production screenshots are intentionally not included in this public case study. Use only approved, redacted captures with synthetic or blurred customer information; remove browser addresses, account identifiers, payment details, internal dashboards, and any confidential data before publication.
| Slot | Intended view | Status |
|---|---|---|
screenshots/01-marketing-experience.png |
Public-facing acquisition experience | Placeholder — add an approved, sanitized capture. |
screenshots/02-lead-journey.png |
Conceptual lead journey or product interaction | Placeholder — use synthetic data and exclude workflow internals. |
screenshots/03-operations-reporting.png |
Administrative reporting surface | Placeholder — redact all live customer and business information. |
See screenshots/README.md for safe replacement guidance. These placeholders are not screenshots of the live system.
- Payment success is a lifecycle, not a page state. Keep user experience, provider confirmation, and fulfillment responsibilities distinct.
- Integration boundaries are leverage. Stable contracts and clear ownership reduce the cost of changing a provider or downstream process.
- Reliability must include recovery. Retries, duplicates, late events, and partial failures are normal conditions in distributed workflows—not exceptional afterthoughts.
- Observability belongs in the product plan. Operators need answers without asking an engineer to inspect internal state manually.
- Automation should reduce complexity for people. The goal is a dependable operating process with sensible visibility, not simply more automated steps.
- Public documentation needs a threat model. A compelling portfolio story can explain the design while deliberately withholding the details an attacker or competitor would find useful.
- Expand service-level monitoring and operational health views at an appropriate, non-sensitive level.
- Add stronger automated contract and integration testing around external-service boundaries.
- Improve replay and recovery tooling for authorized operators, with auditability and scoped permissions.
- Refine privacy-aware reporting and retention practices as business and regulatory needs evolve.
- Document resilience expectations and dependency failure modes with service-level objectives where appropriate.
- Add only approved, sanitized product screenshots and anonymized impact measures when available.
lead-automation-platform-case-study/
├── README.md
├── assets/
│ └── lead-automation-platform-icon.png
├── diagrams/
│ ├── architecture.dot
│ └── lead-automation-architecture.png
├── docs/
│ ├── engineering-decisions.md
│ └── security-and-privacy.md
└── screenshots/
└── README.md
This portfolio artifact describes system design and engineering judgment at a high level. It is not source code, an installation guide for the production platform, a deployment recipe, a security assessment, or a guarantee of specific business results. Do not infer production endpoints, internal policies, data schemas, or commercial logic from the conceptual diagrams.
EDGE | AGENCY · AI Systems Engineer · Automation Architect · Full-Stack Product Builder