As a Shopify developer, you’re often asked to build features for A/B tests. But how should you approach coding something that has a high chance of being thrown away?
If you build it with production-level quality—perfectly integrated settings, sleek animations, and flawless code—you risk wasting days of effort on a losing variation. But if you do it too hastily, you might not get a clean result.
There’s a pragmatic middle ground, a philosophy you can adopt for A/B test development: Quick, Ugly, and Out the Door.
It’s not about writing bad code. It’s about writing the right amount of code to validate a hypothesis, and nothing more. Here’s how to do it effectively.
The Golden Rule: If the Tool Can Do It, Let It
Before you write a single line of code, check your client’s A/B testing tool (like Optimizely, VWO, or Intelligems). Most simple tests can be built directly in the visual editor:
- Hiding or showing elements
- Swapping out text and images
- Changing colors, fonts, and other CSS properties
Only when the test requires bigger changes to functionality—like altering the add-to-cart logic or re-structuring a component’s HTML—should you turn to custom code.
The “Quick and Ugly” Development Principles
Because most A/B tests fail, your primary goal is speed and isolation. The code should be easy to implement and even easier to remove.
1. Focus on the MVP (Minimum Viable Product)
Your mission is to test a hypothesis, not to build a polished, permanent feature. Any extra time spent on perfection is wasted if the test loses.
- Hardcode Everything: Don’t build out theme settings for text, colors, or URLs. Hardcode them directly in your test-specific code.
- Inline Your CSS: Instead of creating new stylesheets, use
<style>tags directly in your Liquid snippet or even inline styles. It’s messy, but it’s self-contained. - Keep It Simple: Forget the fancy animations or edge-case handling for now. Build the simplest possible version of the feature that allows you to test the core idea.
2. Separate Your Code Religiously
When the test is over, you’ll need to either remove the code completely or refactor it into a permanent feature. Make this easy on your future self.
- Create Test-Specific Snippets: Isolate all your A/B test code (Liquid, CSS, and JavaScript) into a separate snippet.
- Use a Naming Convention: Name your snippet with a unique key for the test, for example,
ab-test-split-cta.liquid. This makes it instantly identifiable and searchable. - Render It in One Place: Call your new snippet from the main theme file (e.g.,
main-product.liquid) with a single{% render 'ab-test-split-cta' %}tag.
3. Hide It by Default
Your new feature should not be visible to regular users. The code should exist on the page, but be hidden by default. The A/B testing tool will be responsible for revealing it to the test group.
This is easily accomplished with CSS:
{% comment %} In your ab-test-split-cta.liquid snippet {% endcomment %}
<style>
.ab-test-split-cta-wrapper {
display: none;
}
</style>
<div class="ab-test-split-cta-wrapper">
<!-- Your new feature's HTML goes here -->
</div>Then, in your A/B testing tool’s variation, you simply add a piece of CSS or JavaScript to show the element:
/* In your A/B testing tool's custom CSS */
.ab-test-split-cta-wrapper {
display: block !important;
}When NOT to Be Quick and Ugly
This approach is perfect for small, iterative tests. However, for large-scale changes like a complete homepage redesign or a new navigation menu, “quick and ugly” may not be the right strategy.
In these cases, it’s crucial to have a conversation with your client to understand the real goal.
- Is this a true test, or a phased rollout? If they plan to launch the new design regardless of the test results, it’s better to build it properly from the start.
- What’s the post-test plan? Are they prepared to invest additional time to refactor and polish a winning variation?
Understanding the “why” behind the test will help you make the right technical decisions.
Final Thoughts: Smart Development for Faster Insights
Coding for A/B tests isn’t about technical elegance; it’s about enabling smart, fast business decisions. By embracing the “Quick, Ugly, and Out the Door” mindset, you can deliver testable features rapidly, keep your theme’s codebase clean, and save yourself and your client countless hours of wasted effort.
It’s the pragmatic approach to finding out what works, and just as importantly, what doesn’t.
❓ How do you approach coding for A/B tests? Share your strategies!