Tag: A/B testing

  • Build vs. Buy in Experimentation: Why Embracing Vendors Accelerates Real Innovation

    Build vs. Buy in Experimentation: Why Embracing Vendors Accelerates Real Innovation

    For much of my career, I reflexively favored building experimentation tooling in-house. Over the last few years, I’ve changed my mind. The ecosystem has matured, the bar for statistical rigor has risen, and the opportunity cost of reinventing the wheel has become too high to ignore. Read why the industry has changed to more broadly embrace vendor solutions—and why that's a good thing for innovation.

    The short version: buying core experimentation capabilities increasingly lets us learn faster, reduce risk, and focus scarce engineering cycles on true differentiation. I still believe in building when it creates competitive advantage, but I’ve seen too many teams burn time on “table stakes” infrastructure instead of delivering outcomes that matter.

    When I evaluate build vs. buy, I start with two questions: Is this capability a point of parity or a source of competitive differentiation? And what is the real total cost of ownership over three years, including staffing, maintenance, on-call, compliance, roadmap drag, and delayed time-to-learning? Most experimentation platforms are now points of parity; the differentiation is how quickly and responsibly we learn, not whose statistics package we forked.

    Modern experimentation isn’t just a split URL test. It demands identity resolution across devices, reliable bucketing, exposure logging at scale, edge delivery for flags, guardrail metrics, and rigorous methods like minimum detectable effect (MDE), CUPED, and sequential testing. Add privacy requirements, data governance, and auditability, and the platform burden grows beyond a “quick internal tool.” This is exactly where vendors have pulled ahead, baking in best practices we’d otherwise relearn the hard way.

    There are still good reasons to build. If you operate under unique latency constraints (e.g., sub-20ms decisions at the edge), have non-negotiable regulatory boundaries, or your experimentation model is deeply coupled to proprietary ML systems, bespoke tooling can be justified. I’ve supported builds in those cases—but only with a clear plan for long-term ownership, documentation, and explicit trade-offs.

    More often, buying is the sane default. Vendor solutions give us hardened SDKs, consistent flagging, proven stats engines, and integrations with analytics—freeing teams to spend their energy on high-quality hypotheses and better product discovery. Connecting experiment outcomes to a unified analytics platform (and tools like Amplitude analytics) helps us align on source-of-truth metrics, tighten feedback loops, and empower product trios to make confident, outcome-driven decisions.

    A hybrid approach frequently wins: buy the platform core, then extend it. Build custom decisioning services where needed, enrich telemetry, and add domain-specific metrics on top. I’ve had success pairing vendor platforms with forward deployed engineers and thoughtful developer evangelism to create the best of both worlds—speed from the vendor, nuance from our domain.

    If you’re considering a shift, here’s the adoption playbook I use: – Define success upfront: decision latency targets, MDE guidance, guardrail metrics, governance needs, and privacy constraints. – Run a time-boxed pilot with an A/A test and a handful of A/B testing use cases. Validate exposure logging, bucketing stability, and metric parity against your analytics stack. – Align on outcomes vs output OKRs, so “more experiments” is never the goal; better decisions are. – Establish data governance and metric definitions before full rollout. Treat metrics as a product, not a spreadsheet. – Invest in enablement: in-app guides, product tours, and training for PMs, engineers, and analysts. Proactive stakeholder management is what separates a successful rollout from shelfware.

    AI is accelerating this shift. Gen AI for product prototyping and agentic AI assistants can help generate hypotheses, auto-suggest experiment designs, and flag risky rollouts in real time. Pairing AI with a robust experimentation backbone improves both velocity and quality—without asking teams to become statisticians overnight.

    My bottom line: the industry’s embrace of vendor experimentation platforms is not a retreat from craftsmanship—it’s a strategic allocation of talent. By buying where the market is excellent and building where our differentiation truly lives, we learn faster, reduce risk, and compound innovation. If you haven’t revisited your build vs. buy calculus recently, now is the time. Your customers don’t reward you for owning a stats engine; they reward you for shipping better outcomes, sooner.


    Inspired by this post on Amplitude – Perspectives.


    Book a consult png image
  • Stop Trusting Static A/B Test Calculators: Why You Need Dynamic MDE Curves Over Time

    Stop Trusting Static A/B Test Calculators: Why You Need Dynamic MDE Curves Over Time

    After years of running experiments at scale, I’ve learned that the quickest way to stall product momentum is to rely on static A/B test calculators that promise certainty from a single sample size number. Real-world data rarely behaves like those calculators assume, and that gap quietly erodes decision quality, speed, and stakeholder trust.

    Read about the issues with current A/B test calculators and why experimenters need to see a range of MDEs over time, not a static sample size

    Most calculators hard-code fragile assumptions: a constant baseline conversion rate, balanced traffic allocation, independent and identically distributed sessions, no seasonality, no peeking, no novelty effects, and a fixed-horizon stop. They often use normal approximations that break at low counts and ignore the realities of traffic ramping, SRM (sample ratio mismatch), and mid-test product updates. The result is a deceptively precise sample size that fits the math, not the environment.

    In practice, product teams peek, traffic fluctuates by day of week, acquisition mixes shift, and funnel variance changes as users move from click to activation to retention. These conditions make “the” required sample size a moving target, not a constant. Treating a static figure as a guarantee leads to underpowered tests, false confidence, and rushed stops that inflate false positives.

    The alternative is to manage Minimum Detectable Effect dynamically. Instead of anchoring on a single number, I plan with a range of MDEs over time—power curves that show what lift we can reliably detect after 3, 7, 14, and 28 days as traffic accrues. This reframes the question from “How big should my sample be?” to “What effect sizes can we detect at each decision point given our forecasted traffic and variance?”

    At HighLevel, this approach changed our experimentation culture. For example, an onboarding flow test initially “required” three weeks according to a static calculator. Our MDE-over-time view showed we could detect a meaningful 4–6% lift within a week under expected weekday traffic, but only 8–10% on weekends due to volatility. We set a sequential schedule for interim checks, aligned stakeholders on stopping rules, and made a confident call in nine days—saving a sprint and avoiding a premature rollback.

    Implementing dynamic MDEs is straightforward: forecast traffic by day, estimate variance from historical data, and simulate power curves across relevant effect sizes. Layer in sequential testing or Bayesian monitoring to avoid p-hacking, include guardrail metrics (e.g., latency, error rates, SRM), and publish an MDE band that updates as data arrives. This transforms your “calculator” into a living decision tool rather than a one-time estimate.

    For teams using a unified analytics platform or tools like Amplitude analytics, it’s simple to automate: generate daily MDE curves, annotate ramp changes and seasonality, and expose a dashboard that tracks detectable lift as a function of time and traffic. Pair this with pre-registered stopping rules and a simple communication routine so stakeholders know exactly when and why you’ll decide.

    Beyond top-of-funnel conversion, this mindset is critical for retention analysis and revenue outcomes where effects materialize over weeks or months. Plan MDE bands per horizon—early activation, Day-7 retention, and longer-term LTV—so product discovery and product-led growth bets aren’t prematurely judged on the wrong timeline.

    The takeaway is simple: retire the illusion of a one-number sample size. Embrace dynamic MDE curves that reflect how your data actually behaves, make faster and more confident calls, and keep empowered product teams focused on outcomes over outputs. Your experiments—and your roadmap—will move with more speed, less drama, and far better signal.


    Inspired by this post on Amplitude – Perspectives.


    Book a consult png image