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
A/B testing and optimization tools look technically approachable, but Tailor shows how quickly builders can collect interest without validating purchase urgency in a crowded software category.
Primary check
Collect paid commitments for a focused experiment workflow before expanding into a full A/B testing product.
Checklist
- Can you name the first buyer segment and the repeated job they need solved?
- Can you reach that segment without relying on one fragile channel?
- What evidence would disprove the overbuilding before paid validation risk?
- 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.
Relevant if
- You are building a similar web app with public-source distribution risk.
- You need to validate who will repeatedly pay before investing in product polish.
Less relevant if
- You already control a reliable acquisition channel for the exact buyer segment.
- The product is an internal tool with no need for public distribution.
Pre-build tests
- Run a landing-page or concierge test with the narrowest buyer segment before building the full workflow.
- Ask users to commit to a paid pilot, not only to join a free waitlist.
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.