Before You Build
Web AppShut Down

HeadReach

HeadReach had real early traction, but its lead-discovery value depended on fragile third-party search/data infrastructure. When Google Site Search changed, the product became hard to sustain without its own durable data layer.

View original story

Product snapshot

What it was

HeadReach was a micro-SaaS sales prospecting tool that helped users find targeted leads with email addresses and social profiles.

Who it was for

sales teamsmarketerscontent marketersfounders doing outboundB2B prospectors

Problem / value

It reduced manual prospecting work by helping sales and marketing users find the right people and contact data faster.

Core workflow

Users searched for targeted prospects, gathered email addresses and social profiles, and built outreach lists for sales or content promotion.

Core dependency

Large-scale lead discovery depended heavily on Google Site Search and third-party data access.

Product form

web appsales prospecting SaaS

Pricing model

The founder story mentions a $49/month plan for early paying customers; full historical pricing is not disclosed in the sources used.

Competitors or alternatives

LeadFuzeFindThatLeadsales prospecting databasesemail-finder toolsmanual LinkedIn prospecting

What happened

Summary

HeadReach was a micro-SaaS with early organic traction. According to the founder's postmortem, the product became difficult to keep investing in after a critical third-party API and data-indexing dependency changed.

Outcome

The product moved into sunset mode and later sold its user base and marketing assets.

Core risk

The core lead-discovery workflow relied heavily on Google Site Search and became hard to sustain after that dependency changed.

Timeline

  • The founders launched publicly around November 2016.
  • Within roughly three months, the founder reported a few thousand users and nearly $2,000 MRR.
  • Google's Site Search API closure created a major technical dependency shock in 2017.
  • The team put HeadReach into sunset mode in August 2017, meaning it was kept alive without continued active product investment.
  • The user base and marketing assets were sold to LeadFuze in summer 2018.

Before you build

Why it matters

HeadReach had real users, revenue, registrations, and early MRR, but its core value depended on search/data infrastructure outside the builder's control. For indie builders, the available evidence points less to zero demand and more to technical and data dependency risk.

Primary check

Validate lead-data access, enrichment quality, and platform terms before selling prospecting automation.

Checklist

  • What API, data source, or platform is truly core to the product?
  • What happens if that API closes, rate-limits, changes pricing, or blocks your use case?
  • Can you build a backup data source, proprietary data layer, or narrower workflow?
  • Are users paying for your product, or for temporary access to someone else's infrastructure?
  • If the product becomes hard to maintain, what asset value remains: users, content, data, SEO, or brand?

Relevant if

  • You are building a lead-generation, email-finder, sales prospecting, data enrichment, search, scraping, or API-wrapper product.
  • Your product's core value depends on a third-party API, index, search endpoint, platform workflow, or external data source.
  • You can launch with a shortcut, but long-term data access or indexing economics are still unclear.

Less relevant if

  • You own the core data source or can legally and economically build it yourself.
  • Your product can still deliver value through a manual service, proprietary workflow, or narrow niche if the third-party source changes.
  • The third-party platform is only a convenience layer, not the product's core value.

Pre-build tests

  • Price the backup path before building: alternate APIs, proprietary index, manual enrichment, or narrower data source.
  • Run a small data coverage test to see whether the product can deliver useful results without the single most fragile dependency.
  • Estimate the cost and operational burden if the third-party source rate-limits, changes pricing, or blocks the workflow.
  • Test whether customers still care about a narrower version that does not depend on broad third-party search coverage.

Transferable lessons

  • Validate the long-term defensibility of the technical substrate, not only the initial product demand.
  • Treat third-party APIs and data access as business risks, not just implementation details.
  • A product can have revenue and users but still be a poor long-term fit if the core infrastructure is fragile.
  • Sunset mode or asset sale can be a rational closure path when the founder decides maintenance risk exceeds upside.