--- title: "A/B Testing for Solo Next.js Developers and Indie Hackers" description: "You don't have a growth team, you don't want a second dashboard, and you definitely don't want to hand-write variant B. Here's a realistic A/B testing setup for one person." canonical: https://landtest.dev/blog/ab-testing-solo-nextjs-developers last-updated: 2026-10-30 --- # A/B Testing for Solo Next.js Developers and Indie Hackers > You don't have a growth team, you don't want a second dashboard, and you definitely don't want to hand-write variant B. Here's a realistic A/B testing setup for one person. A solo Next.js developer can run a real A/B test on a landing page with three things: a way to generate a second variant without hand-writing and maintaining it, a split that doesn't add a third-party script to the page, and stats that tell you when you actually have a winner instead of eyeballing a conversion percentage after 40 visitors. Most A/B testing tools are built for a growth team with a dedicated analyst — as a solo developer, the cost that matters isn't the subscription price, it's the hours spent wiring up a tool instead of shipping the product. ## Why most A/B testing advice doesn't apply to you The standard CRO playbook assumes someone's job is running experiments: a growth engineer builds variant B by hand, a PM reviews the hypothesis, an analyst checks significance weekly. As a solo developer or indie hacker, you are all three roles, and the honest tradeoff is that most experiments aren't worth running if building the variant takes longer than just shipping your best guess and moving on. The tests worth running solo are the ones where the variant is cheap to generate and the traffic is real enough that a result means something — typically headline/subhead framing, CTA copy, or pricing page layout on a page that already gets a few hundred visitors a week minimum. Below that, you're testing noise. ## What "cheap to generate" actually requires Hand-writing a second landing page variant costs real time: a new component, new copy, a way to route traffic to it, and a way to tear it back out later. Landtest's approach is to generate the variant as a branch against your actual repo — you review it as a live preview before it ships, the same way you'd review a PR. For a solo developer, the time cost of a test collapses to "review a diff and approve it" instead of "build a second landing page." ## Avoiding small-sample false positives With low traffic, the biggest risk isn't running the wrong test, it's declaring a winner too early off a naive percentage comparison. If variant B is at 8% conversion versus variant A's 5% after 60 visitors total, that's not a result — it's noise that happens to look directionally interesting. See [how to get statistically significant results from a small traffic landing page](/blog/small-traffic-statistical-significance) for the full breakdown. The short version: use sequential testing (mSPRT) rather than a fixed-sample z-test, since a fixed-sample test run at low traffic will either never reach significance or get "peeked" into a false positive when you check it daily, and check for sample ratio mismatch (SRM) before trusting the split at all — a broken 50/50 split is a more common bug than people expect, and it silently invalidates results. ## What to skip as a solo developer Skip anything that requires a second dashboard you'll stop checking after week two. Skip multivariate testing — one variable at a time is both easier to reason about and gives you a result you can actually act on. Skip a tool that requires you to maintain feature-flag code in your app after the test ends; at solo-developer scale, an abandoned flag check three months later is technical debt nobody's going to notice until it breaks something. ## A realistic setup Connect your repo, let the AI propose a variant against a specific hypothesis (a different headline, a shorter form, a repositioned CTA), review the preview like you'd review any other PR, and let it run until either mSPRT calls a winner or you hit a time-box you set in advance (two weeks is a reasonable default for most indie landing pages). Declare the winner, get the cleanup PR, merge it, move on to the next thing you're actually building. ## FAQ **How much traffic do I need to A/B test as a solo developer?** There's no hard minimum, but below a few hundred visitors a week per variant, a test will rarely reach significance in a reasonable timeframe with a fixed-sample test. Sequential testing (mSPRT) shortens that in practice by letting you stop as soon as the evidence is strong enough, rather than waiting for a pre-committed sample size. **Do I need to know statistics to run an A/B test?** No, but you should trust that the tool is using sequential testing (mSPRT) rather than a naive z-test, and that it checks for SRM — those two things prevent the most common false-positive traps at low sample sizes. **What's the minimum viable A/B test for an indie landing page?** One variable, one hypothesis, a time-box you commit to in advance, and a variant that's cheap enough to generate that building it doesn't eat the time you'd otherwise spend shipping product. --- Related: [Best A/B testing tools for Next.js developers](/blog/best-ab-testing-tools-nextjs-developers) · [A/B test without middleware conflicts](/blog/ab-test-nextjs-landing-page-without-middleware-conflicts) · [Landtest for A/B testing](/ab-testing)