Scale Product-Led Growth Without Drowning in Tooling

Hummingbirds x Optiblack x Customer.io
A Growth Stack Story

When the Hummingbirds team first reached out to Customer.io and Optiblack, they weren’t shopping for yet another tool or a few weeks of consulting. They were trying to escape a fragile growth engine held together by HubSpot hacks, manual workflows, and more operational risk than they were comfortable with.

They wanted something different: a growth stack they could actually own—a system where product behavior, communication, and analytics spoke the same language.

This is the story of how they got there.

Act I: Outgrowing HubSpot

For a long time, HubSpot sat at the centre of Hummingbirds’ world. It was the system of record for brand communication and email. Creators received welcome flows, Instagram connect prompts, and engagement nudges. But underneath, the machinery was clunky.

Critical emails were driven by CRM properties and brittle workflows instead of what really mattered: what creators did in the product.

Three problems kept surfacing:

1. Limited leverage from product data
   Lifecycle flows couldn’t react in real time to behavior in the marketplace. A creator could sign up, explore campaigns, even upload content, and HubSpot would still be looking at static fields.
   
   
2. Scaling risk
   Every time the marketplace grew, HubSpot grew more fragile. Each “quick fix” workflow added another layer of complexity. Over time, optimizations started to feel like surgery.
   
   
3. A split view of the customer
   Product behavior lived in Redshift and ad‑hoc dashboards. Communication lived in HubSpot. There was no single, trustworthy picture that combined the two.
   
   

Hummingbirds knew this wouldn’t scale past 40,000+ creators.

Customer.io emerged as a candidate to replace HubSpot for engagement. Mixpanel was chosen to own behavioral analytics. And Optiblack was brought in to design and implement the connective tissue between all of it.

The mandate was clear: build a stack that could power event‑driven growth at scale—without turning the team into permanent tool operators.

Act II: Choosing the Right Stack (and Avoiding Expensive Mistakes)

The journey began with exploration, not implementation.

Early Customer.io conversations focused on a flexible trial: how to test the platform safely with dummy data, small amounts of real data, or synthetic CSV uploads. Meanwhile, Hummingbirds’ tech lead, Nick, dug into integration requirements across their Zero Data Platform (ZDP), Mixpanel, and even Amplitude.

In the background, a bigger decision loomed: which CDP should sit at the center of the data layer?

Customer.io’s own CDP, Segment, and RudderStack were all on the table. After weighing cost, flexibility, and ownership, the team aligned on a simple hierarchy:

CDP → Analytics → Engagement
RudderStack (open‑source) → Mixpanel → Customer.io

This order of operations mattered. It meant:

• Events would be modeled once and reused everywhere.
• Future tools—additional analytics, ad platforms, new destinations—could be plugged in with minimal rework.
• Hummingbirds would avoid building fragile, bespoke integrations for every new tool.

The second decision was about speed.

Hummingbirds lacked the spare engineering capacity to architect and ship this foundation quickly. Optiblack proposed a focused, 5–6 week project that combined:

• Tracking plan and taxonomy design
• Implementation across Customer.io, Mixpanel, and open‑source RudderStack
• Weekly progress reporting and a managed Slack channel
• Knowledge transfer and handoff training for the internal team

After a series of scoping and negotiation calls, the teams landed on a $6,500 implementation, partially offset by Customer.io partner credits. The SOW was clear and bounded:

• Infrastructure setup
• Event schemas
• RudderStack deployment on Hummingbirds’ own servers
• A capped event scope (50 events, with 30–40 expected in practice)

For Hummingbirds, the business case was easy to justify: compress months of design and implementation into a few weeks, and ship a growth stack that would otherwise be perpetually “in progress” alongside product work.

Act III: Architecture Reality Check

The first real friction point came early—and it had nothing to do with tools.

Optiblack’s preferred working model was to get branch‑level access to Hummingbirds’ codebase so they could wire in event instrumentation directly. Hummingbirds, however, had assumed a cleaner separation: Optiblack would handle the external tools, and their own engineers would handle emission of events from the app.

This misalignment forced a tough choice:

• Grant Optiblack deeper access and move faster, or
• Keep event instrumentation in‑house and accept more engineering effort.

Rather than lurch to one extreme, they settled on a hybrid.

Optiblack would:

• Define SDK usage and tracking patterns
• Design event schemas and governance
• Own the infrastructure around RudderStack, Mixpanel, and Customer.io

Hummingbirds’ engineers would:

• Own the actual placement of events in the React + Next.js frontend and TypeScript + Express API backend
• Implement patterns and SDK calls following Optiblack’s guidance

The result was a governance win: Hummingbirds retained control of their product code while fully leveraging Optiblack’s architecture expertise.

Confronting Ad Blockers and Data Loss

Because most creator behavior happens in the Next.js web app, the team had to face a tough reality: client‑side tracking is fraught.

Two issues stood out:

• Ad blockers (Brave, uBlock, etc.) silently block third‑party tracking calls.
• Mixpanel’s AutoCapture can misattribute events and pollute the dataset.

Optiblack recommended a more deliberate approach:

• Move away from AutoCapture to explicitly defined events that matched the tracking plan.
• Put an NGINX reverse proxy in front of RudderStack on the hummingbirds.com domain to present first‑party, less blockable requests.

The team accepted that some client‑side data loss (10–30%) was inevitable, but they also understood the trade‑offs: this architecture significantly reduced risk while staying achievable within their Q4 timeline. More advanced server‑side cohort events could wait for a later phase.

For Hummingbirds, this phase transformed analytics from a black box into a set of conscious, documented trade‑offs.

Act IV: Evolving the Data Strategy

Initially, Mixpanel’s native SDK seemed like the natural default for client‑side tracking.

But as the architecture sharpened, Optiblack surfaced a crucial detail: Mixpanel’s out‑of‑the‑box integration with Customer.io syncs cohorts, not raw events. If Hummingbirds wanted Customer.io to power truly event‑driven lifecycle automation, they would eventually face a nasty surprise—duplicating event implementation just to feed Customer.io.

Instead of walking into that trap, they changed course.

RudderStack became the primary event pipe:

• One implementation of events → multiple destinations (Mixpanel, Customer.io, Redshift).
• Attribution and logic consolidated in a single CDP layer.
• Cleaner extensibility for future tools and warehouses.

This decision protected Hummingbirds from exactly the sort of long‑term technical debt many teams only notice once they’re deep into a second or third integration.

A Layered Data Flow

Over time, the architecture matured into a pragmatic, layered system:

• Real‑time path: RudderStack → Customer.io for time‑sensitive triggers (e.g., signup emails within minutes).
• Behavior and analysis path: RudderStack → Mixpanel for event analytics and dashboards.
• Enrichment path: Redshift → Mixpanel, enriching profiles with cohort status and performance segments.
• Cohort sync path: Mixpanel → RudderStack (transform) → Customer.io to use behavioral cohorts as campaign triggers.

This layering introduced some latency—up to ~24 hours for derived properties—but that was an acceptable trade‑off. Most of Hummingbirds’ communications were lifecycle‑oriented, not ultra‑time‑sensitive transactional alerts.

The payoff was meaningful: Customer.io could operate with rich, behavioral context without corrupting the integrity of the analytics layer.

Act V: Email Migration and Growth Operations

With the data plumbing in place, the team could finally address one of the most visible wins: moving creator email flows from HubSpot to Customer.io.

They started with the most impactful pieces:

• Migrating 10 event‑based workflows—welcome flows, Instagram connect prompts, and other core lifecycle emails—into Customer.io.
• Using placeholder triggers and dummy events so flows and templates could be built before all production events were fully wired.

But the biggest risk wasn’t technical. It was reputational.

Hummingbirds had ~36.7k contacts to move and a domain reputation to protect. A clumsy migration could easily tank deliverability.

Together, the teams designed a phased domain warm‑up strategy:

• Sequence contacts by last email open date.
• Start sending from Customer.io to the most engaged users first.
• Gradually increase volume, watching reputation and engagement metrics closely.

This careful choreography preserved a healthy sending domain while unlocking Customer.io’s full capacity for 2026.

Act VI: Making the Data Usable

With events flowing and infrastructure humming, the next challenge was deceptively simple: make the data usable to humans.

A Shared Language for Events

Optiblack and Hummingbirds invested heavily in the upfront tracking plan and taxonomy:

• Defining core user types—admin, customer (brand), bird/creator.
• Aligning naming conventions so product, growth, and analytics all spoke the same language.
• Prioritizing events around the core user journey: sign‑up, onboarding, discovery, participation, and content contribution.

Perfection was explicitly off the table. The goal was to get to “close enough” fast, with a framework that would age well as the product evolved.

From there, Optiblack shipped:

• A fully documented Mixpanel Lexicon with event and property definitions, descriptions, and screenshots.
• Foundational dashboards for creator funnel health, acquisition, activation, and engagement.
• Community dashboards focused on marketplace health and creator behavior.

The result was a step‑change in autonomy: Jordan, Callie, and the broader growth team could answer their own questions without queuing up requests for engineers or consultants.

Wrestling with Data Quality

No real‑world implementation is perfect, and Hummingbirds’ was no exception.

Several integrity issues surfaced:

• Discrepancies between Mixpanel and internal Superset metrics, driven largely by ad blockers and client‑side tracking gaps.
• Roughly 33k creators were missing a critical profile_type = bird tag in Mixpanel.
• UTM parameters were being captured at the event level but not persisted to profiles, limiting attribution.

Rather than sweep these under the rug, the team tackled them openly:

• Defining a VLOOKUP‑based remediation process to retroactively tag users from HubSpot into Mixpanel via email-to-distinct_id mapping.
• Scoping code changes to persist UTMs at the profile level going forward.
• Deciding to simply discard a small, problematic 2‑week dataset that would have required ~4 days of engineering effort to fix with minimal business benefit.

By the end of this phase, the data was directionally trustworthy and explainable. Everyone understood the limitations, and those limitations were documented—not hidden.

Act VII: Handover and Internal Ownership

By January, the narrative shifted from “build and fix” to “enable and own.”

Hummingbirds made a strategic call: this system would not live perpetually in a consultant’s notebook. It would be owned in‑house.

The plan for the final stretch was straightforward:

• Optiblack would finish the community dashboards and deliver a robust enablement training.
• The engagement would wrap, with Optiblack offering a free post‑completion audit once Hummingbirds’ engineers finished remaining tasks.

Optiblack’s final deliverables included:

• Curated dashboards for user, acquisition, and engagement analysis.
• Event and property documentation directly inside Mixpanel.
• Hands‑on training for advanced reporting—funnels, insights, custom groupings—rooted in Hummingbirds’ real questions.
• A practical handover guide on how to extend the tracking plan and add events for new features.

By the end of the engagement, Hummingbirds had:

• A working growth stack: RudderStack → Mixpanel → Customer.io → Redshift, all talking to each other.
• Documented analytics: a living Lexicon, vetted events, and usable dashboards.
• Operational autonomy: growth and product teams could ask and answer their own questions, and extend the system without re‑engaging consultants for every change.

Results in Numbers

Behind the story, the numbers tell their own version:

• Engagement duration: August 2025 – January 2026 (6 months)
• Implementation window: 5–6 weeks for core rollout
• Live users tracked: 40,000+ creator profiles
• Custom events in production: 11 key user and engagement events
• Email flows migrated: 10 transactional workflows from HubSpot to Customer.io

On the technical side, the architecture now looks like this:

• Frontend: React + Next.js
• Backend: TypeScript + Express API
• Transactional database: Postgres
• Analytics warehouse: Redshift (500+ GB, daily deltas synced to Mixpanel)
• Event router: RudderStack (open‑source, self‑hosted on AWS)
• Event proxy: NGINX reverse proxy on hummingbirds.com (via Cloudflare/AWS) to mitigate ad blockers
• Analytics: Mixpanel (real‑time events, cohorts, dashboards)
• Engagement: Customer.io (email campaigns, event‑triggered automation, Mixpanel cohort webhooks)

The tracked events capture the full creator lifecycle—from sign‑up and profile completion, through campaign discovery and participation, all the way to content uploads, payments, and email engagement.

Segmentation now includes:

• Active creators
• Dormant users
• Power users (5+ campaigns, 50+ uploads)
• Acquisition cohorts by signup month
• Geographic segments by location

With 95%+ profile integrity and retroactively corrected tags, Hummingbirds finally had a single, reliable user definition across tools.

Key Learnings

Looking back, several lessons stand out:

1. CDP first, not SDK‑native
   Routing all events through RudderStack instead of direct SDK integrations avoided duplicated work for Customer.io and simplified future tool additions.
   
   
2. Ad blocker mitigation is not optional
   The NGINX reverse proxy on the company domain captured meaningful behavior that would otherwise be invisible.
   
   
3. Data reconciliation at scale matters
   One missing tag affected 33,000 profiles. Fixing it was non‑trivial, but it proved the value of governance from day one.
   
   
4. Phased implementation beats perfection
   Launching with Q4 client‑side events and deferring backend cohort events unblocked critical value weeks or months earlier.
   
   
5. Documentation drives adoption
   A rich Lexicon with screenshots and sample values was the difference between “we have Mixpanel” and “the team actually uses Mixpanel.”
   
   

Conclusion

Hummingbirds’ journey was never just about replacing HubSpot.

It was about transforming how growth itself was instrumented, measured, and automated—and making sure the company, not its vendors, owned that capability.

By January 2026, Hummingbirds had:

• Fully operational analytics and dashboards for acquisition, activation, and engagement.
• Event‑driven, cohort‑aware email workflows running on Customer.io.
• A sustainable, CDP‑first architecture built on RudderStack, Mixpanel, Customer.io, and Redshift.
• An internal team confident enough to drive and extend the system on their own.

The payoff was substantial: reduced dependency on HubSpot, actionable growth insights at their fingertips, and a scalable growth stack ready for the next stage of the marketplace.

In story terms, Hummingbirds didn’t just install tools. They rewrote the operating system for how their marketplace grows.