I shipped a landing page, a waitlist, and a table with zero rows in it. That table is the only part I'd be upset to lose.
Here's the reasoning, in case it's useful to anyone else deciding what to build first.
Everyone sells the present
There's a healthy market for social media data. A dozen companies will sell you an API that answers what is trending right now — what's hot on TikTok, what's climbing on Reddit, which hashtags are moving.
They all answer the same question, and they answer it well. Which is why it's a price war: the cost per thousand profiles across that market ranges from about $0.18 to over $7, and the difference comes from packaging, not from anyone having a cheaper way to get the data.
Nobody sells the past.
- Was this topic bigger three months ago?
- Is this rising or already dying?
- When did it start moving?
You can't answer those by querying harder today. You can only answer them if you were recording yesterday.
History is the one advantage money doesn't buy
Most competitive advantages can be bought or copied. Better engineering, better design, more platforms, lower prices — all reachable by someone with more resources than me, which is nearly everyone.
An archive isn't. If I start recording today and someone with ten times my funding starts tomorrow, they are one day behind me. Forever. There is no way to buy a version of last month that you didn't record.
That property is rare enough that it decided my build order.
So I built it backwards
Normal order: figure out the product, get users, then instrument it.
I did the instrumentation first. Right now there's a job that wakes up, asks a few public APIs what rose in a set of niches, and writes down the title, the score, the comment count, and the rank. No product attached. No customer waiting for it.
The reason is that everything else costs the same later. The API, the docs, the pricing page, the marketing site — building those in three months costs what it costs today. The archive is the only piece that gets cheaper the earlier it starts, because what it produces is elapsed time.
Every day I don't run it is a day I can't get back.
What it deliberately doesn't record
It stores the title, the metrics, and the position. It does not store the author, the post body, the profile, or the photo.
That started as a legal decision — aggregate trend data isn't personal data, which keeps it well clear of GDPR and LGPD, and metrics aren't copyrightable, which keeps it clear of the copyright claims that have been landing on data companies lately.
But it turned out to be the right product decision too. "This topic grew 40% in two weeks" is more useful to someone deciding what to post than any individual post is. The safe version and the useful version were the same version, which doesn't happen often.
The uncomfortable part
I've been transparent about building this in public, so: as I write this, the archive has zero rows. The code is deployed and tested. Two environment variables are missing, so the scheduled job wakes up, gets a 401, and goes back to sleep.
Every day that continues is a day of the advantage I just spent 600 words explaining.
I'm leaving that paragraph in, because a post about the value of starting early would be a strange place to hide the fact that I haven't finished starting.
If you're building something similar
The question worth asking early: what does my product get better at by simply existing longer?
For a lot of software, the answer is nothing. It works the same on day one as on day five hundred, and every advantage is contestable.
If you can find something that compounds with time — an archive, a corpus, a set of measurements nobody else took — build that part first, even if it's the least interesting thing on your list and nothing can use it yet.
It's the only work you can't do faster later.
HonestHook tracks what's rising and dying in your niche over time, then hands you the post. The waitlist is open; the product is being built in public.