AnchorGrid Linked to Their API Docs on HN Instead of Their Homepage. It Got 106 Points. That's the Strategy.

The Play

AnchorGrid posted on Hacker News today. The link they shared wasn't their homepage. It wasn't a blog post. It was their API documentation page for door detection in construction floor plans.

It hit 106 points.

This is not an accident. It is a repeatable distribution strategy that almost no developer tool uses intentionally.

Why This Works on HN

Hacker News culture actively dislikes marketing. The community will downvote a polished product landing page with enthusiasm. They tolerate Show HN posts, but they reward posts that treat them as developers rather than consumers.

A link to your API docs does three things that a homepage link cannot.

First, it signals technical confidence. You're not hiding your implementation behind vague feature descriptions. You're showing the request parameters, the response shapes, the error codes. If your API is poorly designed, this is immediately obvious. If it's well designed, it's immediately credible.

Second, it filters for the right audience. A developer who clicks through to API docs and reads them is pre-qualified. They have a use case in mind. They're evaluating whether your product solves their problem. Compare this to someone who clicks a homepage link, reads three bullets, and bounces — that traffic has near-zero conversion value.

Third, it starts the relationship in the right mode. The first interaction a developer has with your product shapes their mental model of it. If the first interaction is a marketing page, they categorize your product as "another SaaS tool." If the first interaction is your API documentation, they categorize it as an engineering tool that happens to have a business attached to it.

The Documentation Quality Signal

AnchorGrid's door detection endpoint documentation shows something specific. The response format returns stable identifiers (door_" + 12 hex chars), bounding boxes in PDF coordinate space, and page-level metadata. There are notes about billing precision ("Credits are charged on submission based on page count — not on pages that actually contain doors"). There are code examples with real curl commands.

This documentation tells a developer several things without stating them explicitly:

The team thought about edge cases (empty pages still get charged if submitted, so the docs warn about valid page indices). The response format was designed for integration, not for display (stable identifiers with consistent prefix patterns). The billing model is transparent and predictable.

None of this is on a marketing page. All of it matters to a developer deciding whether to integrate your API.

How to Steal This

The tactic is simple. Most founders never do it because they build their marketing site before they finish their API, and by the time the docs are complete they've already formed the habit of linking to the homepage.

Write your documentation to the standard where you'd be comfortable sharing it with a senior engineer as their first impression of your engineering culture. Not "good enough for users who already decided to integrate." Good enough to convince a skeptical developer that your team takes their API seriously.

Then choose the right endpoint to share. Not your root documentation page (too generic). Not your getting-started page (too basic). The endpoint that represents your core value proposition, with the most interesting response shape and the clearest demonstration of what makes your API different.

Pair it with a short narrative blog post or changelog entry that explains why this problem is hard. AnchorGrid's companion piece explains why construction drawings are "data prisons" — this gives HN commenters something to discuss beyond the technical implementation.

The Conversion Path That Works

Developer reads docs on HN → understands the technical approach → clicks "Get API Key" → signs up → integrates in a weekend → becomes a paying customer.

This funnel works because it never breaks the technical frame. The developer stays in evaluation mode the entire time. They're not being sold to. They're deciding whether the tool solves their problem. When it does, they sign up.

The homepage funnel breaks the technical frame at step two. The developer clicks from HN to a marketing page, shifts mental modes from engineer to consumer, and evaluates based on marketing copy rather than technical merit. Most developers find this mode shift uncomfortable and bounce.

When This Doesn't Work

This tactic requires actually having well-designed API documentation. If your API is messy, if the response shapes are inconsistent, if the error handling is undocumented — sharing your docs on HN will generate the opposite effect. Developers will find the problems and comment on them.

This is useful signal if you're early. It's painful if you're trying to convert customers.

The bar: your documentation should be the kind you'd be proud to show a senior engineer at a company you respect. If you'd be embarrassed to have them read it, write it better before you post.

AnchorGrid chose their documentation page as their HN launch asset. That choice is a bet that their implementation is worth reading. The 106 points suggest the bet paid off.