career/qwestly/2026-10-homepage-linkedin-name-lookup.md
Table of Contents
Let homepage visitors find their LinkedIn by name instead of pasting a link
Situation
The homepage's one call to action, the free LinkedIn review, only accepted a pasted LinkedIn link. Copying that link is awkward on a phone, and the review is where every Reddit ad click lands. In the 28 days before launch, www.qwestly.com had 599 homepage visitors and only 18 review submissions (about 3%). Adam's "See what your agent can do" redesign asked whether we could look people up by name at all, and how fast. We had no way to.
What I did
- Split the name lookup out of Adam's redesign ticket, then spiked four search options with real queries before designing anything. The obvious choice, DeepSeek's web search (already used by role-fit research), turned out to return zero LinkedIn profiles even for Satya Nadella. Its index simply has none. Perplexity's Search API found the right person first for 25 of 26 labelled people, in about 0.3 s, at about $0.005 a lookup; Tavily became the fallback.
- Wrote the plan and built the people-search endpoint in api-python: no model in the loop, never fetches linkedin.com, filters and ranks search results deterministically, logs no names. Set up a daily spend cap that fails open within 1.5 s. Released it the same day (api-python#232, release #233).
- Built a qwestly-internal test page for it (qwestly-internal#110).
- Wired it into the homepage box: several words are a name, the box shows "Which one is you?", and picking one continues exactly as a pasted link does. 10 searches a minute per IP plus the daily cap bound abuse at about $100 a day. Released the same day (public-site#211, release #212).
- Chose not to add Turnstile or a feature flag: the box is the homepage's main action, and the daily cap already bounds the cost of abuse.
- Turned the plan into a feature doc and archived it the same day.
Result
Pending. Shipped 2026-10-08. What to look for: more review submissions per homepage visitor, and a meaningful share of them arriving through name lookup.
Metrics
| Metric | Baseline (date) | Target | Latest (date) |
|---|---|---|---|
| Review submissions on www.qwestly.com, 28 days | 18 (url 7, username 11) on 599 homepage visitors / 812 views, 2026-09-10 to 2026-10-08 | Higher rate per visitor | n/a |
Share of submissions via name lookup (input_kind = lookup) |
0 before 2026-10-08 (1 on launch day) | n/a | n/a |
Pick rate: LinkedIn lookup person picked / LinkedIn lookup searched |
n/a | n/a | n/a |
Lookup cost per day (api-python usage_counters) |
n/a | under $100 (cap 20,000) | n/a |
| Right person first, name + company, 26-person bench | 25/26, p95 1.7 s (2026-10-08) | hold | 25/26 (2026-10-08) |
How to measure
PostHog, through the posthog skill (./posthog-cli api call execute-sql), production host only
(local, preview and staging send to the same project):
SELECT properties.input_kind AS kind, count() AS n
FROM events
WHERE event = 'LinkedIn grade submitted' AND properties.$host = 'www.qwestly.com'
AND timestamp >= now() - INTERVAL 28 DAY
GROUP BY kind
SELECT count() AS views, uniq(distinct_id) AS visitors
FROM events
WHERE event = '$pageview' AND properties.$host = 'www.qwestly.com' AND properties.$pathname = '/'
AND timestamp >= now() - INTERVAL 28 DAY
Pick rate: count LinkedIn lookup searched, LinkedIn lookup person picked and
LinkedIn lookup none picked on the same host. Cost: the linkedin_people_search:<day> documents
in the internal database's usage_counters, times about $0.005. The baseline window ends on
launch day, so it includes a few hours after launch.
Log
- 2026-10-08: spiked providers, built and released the endpoint, internal test page and homepage box; baseline taken from PostHog.