Tailor
Tailor was an A/B testing tool built for a crowded category before enough buyer validation. Public founder interview evidence points to roughly 800 signups, six months of work, about $2k spent, and no revenue.
View original storyProduct snapshot
What it was
Tailor was an A/B testing software product for website owners who wanted to compare page variants and optimize conversion.
Who it was for
Problem / value
It helped website owners compare page variants and improve conversion through A/B testing.
Core workflow
Website owners created page variants, ran A/B tests, compared results, and used the experiment data to improve conversion.
Product form
Pricing model
No public pricing data found in the sources used.
Competitors or alternatives
What happened
Summary
The Failory founder interview describes Tailor as A/B testing software.
Outcome
Founder interview describes an A/B testing product with hundreds of signups but zero paying users after the founder built too much before validating paid demand.
Core risk
Overbuilding Before Paid Validation
Timeline
- Failory interview says Tailor was built for about six months and shut down after the founder realized he had built too much without validation.
- Founder reported about 800 signups but no paying users.
- Founder said he spent about $2k and earned no revenue.
Before you build
Why it matters
Tailor was an A/B testing tool built for a crowded category before enough buyer validation. The useful pre-build question is whether website owners, marketers, and growth teams will repeatedly use and pay for create A/B tests for web pages and Compare different page variants through a channel you can keep reaching.
Primary check
Collect paid commitments for a focused experiment workflow before expanding into a full A/B testing product.
Checklist
- Who owns the budget for this problem?
- What repeated event triggers the buyer to use this every week or month?
- Which channel reliably reaches website owners, marketers, and growth teams without a one-off launch spike?
- What evidence would show Overbuilding before Paid Validation before you build more?
- Define which segment among website owners, marketers, and growth teams pays first and why the problem is urgent now.
- Prove the workflow happens often enough to justify buying.
- Test one acquisition channel for website owners, marketers, and growth teams before relying on launch traffic.
- Write down why a buyer would switch from Google Optimize, Optimizely, and VWO.
Relevant if
- You are building a web app for website owners, marketers, and growth teams.
- The main value is specific: It helped website owners compare page variants and improve conversion through A/B testing.
- You have interest, signups, usage, or founder confidence but have not proven paid repeat use.
- Buyers can already use Google Optimize, Optimizely, and VWO or avoid switching altogether.
Less relevant if
- You already have paying website owners, marketers, and growth teams who repeatedly use the workflow and renew or expand usage.
- The product is an internal tool with a mandated user base and no external go-to-market risk.
Pre-build tests
- Run the workflow manually for a small group of website owners, marketers, and growth teams.
- Ask one buyer to pay, renew, or sign a dated pilot before building the next version.
- Test one non-launch acquisition channel and count qualified conversations, not page views.
- Put the offer next to Google Optimize, Optimizely, and VWO and ask what would make the buyer switch now.
Transferable lessons
- Validate paid demand before building a full-featured testing platform.
- Treat signups as weak evidence until users run experiments and pay.
- Differentiate against established tools before investing in core infrastructure.
- Keep the first product narrow enough to test one buyer segment.