A tech-book ranking site built from 300,000 Qiita articles hit 100,000 yen in revenue three weeks after launch

Indie development stories tend to cluster at two extremes: founders who raised eight-figure funding, or sites that stalled at zero revenue and stopped. A Qiita post from May 2018, titled “Everything I did to make 100,000 yen in revenue three weeks after launching my indie site,” lands in the middle. The author (@jabba) describes the outcome himself as “roughly the size of a site that can buy you an iPhone X in about a month.” It’s not flashy, but as a milestone within reach, it’s a clearly defined one.

What he built

The site is techbookrank.com (“Tech Book Rank”), a ranking of technical books. It pulls articles that mention technical books from the Qiita API and ranks the books by aggregate mentions. The idea: “a book mentioned in more technical blog posts is a better book.”

A “good book” is judged on three criteria: mentioned in many Qiita articles, mentioned in popular Qiita articles, and mentioned in recent articles. The author explicitly states: “I absolutely did not artificially boost any particular book’s ranking.”

One interesting detail is how tags are handled. Tags attached to Qiita articles are carried over directly as tags on the corresponding book. Since the link runs tag → article → book, a book’s content and its tags aren’t strictly matched. As an example, the author cites Is Artificial Intelligence Smarter Than Humans?, which ends up tagged with Python and TensorFlow. The book itself doesn’t discuss those technologies directly, but the tags mean something like “engineers who recommend this book tend to write articles related to Python and TensorFlow.” The author deliberately keeps this loose association, framing it as a mechanism for “encountering a book” that a strict Amazon-bestseller-order ranking wouldn’t produce.

What the article doesn’t say about the 100,000 yen

One thing needs to be flagged up front: the article never states the revenue source. There’s a section titled “Monetizing the site,” but what’s discussed there is the reasoning for treating revenue as an evaluation metric, with a parenthetical clarification that “what I’m calling an evaluation metric here isn’t about the site’s revenue model, whether it’s paid subscriptions or free ad revenue or whatever, that’s not the point.” So this piece doesn’t attempt to identify how the 100,000 yen was earned either. What’s known is only the amount and the timeframe.

What is written instead is the reasoning behind caring about revenue at all. “Money is the strictest measure of whether a site is any good.” A like or a favorite ends the conversation at “oh nice, good work”, but asking “would you pay X yen for this?” raises the bar considerably, in his view.

The decisive factor: fully exhausting his “own passion” on the prior project

The point where the trajectory changed is clear. The site he built before Tech Book Rank was “pushed forward with a lot of my own passion and conviction (and it flopped, in the end.” From there, the author reversed his approach: “set my own passion aside for a moment, and relearn how to plan a project by tracing successful examples.” He writes plainly, “I think this approach was really good”) and that single shift is what separates the earlier project from this one.

The new planning process is described in three steps: identify the target user. Thoroughly research what that user wants and which existing products they like, then copy them. Only at the very last step, add a small dose of your own flavor. The narrower the target, the better, “for engineers” is good, “for IT engineers” is better, and “for IT engineers who like technical books” is better still, according to the article.

Breaking down why it took off

First, he had content ready before anything else. The author writes, “users have zero interest in the system”; “the only thing in front of a visitor when they land on the site is the content.” A classic failure mode for user-submission-based services is building a great system, then waiting for submissions, only to end up with a handful of posts from friends. Tech Book Rank sidestepped this by pulling in roughly 300,000 Qiita articles via API, creating a state where 4,000 books’ worth of listings and mention counts appeared “as if they were already there, even though they technically weren’t” from day one. First-time visitors never saw an empty service.

Second, he promoted where readers already were. Traffic didn’t originate from the site itself. It started from the intro article he’d already published, “I built a technical book ranking by aggregating about 4,000 books from Qiita articles, and it turned out great.” Since the source data and the promotion channel were the same platform (Qiita), the readership of that article and the ranking site’s user base overlapped almost completely. The author writes, “that article got a decent amount of traction, and traffic flowed from there to the site.” Aligning the data source and the acquisition channel is what made this work.

Third, he pushed costs toward zero using free infrastructure. The stated reason matters: “to keep the service alive as long as possible, to maximize the number of chances I get.” He’s preempting the psychology of shutting things down, even a few thousand yen a month, sustained for several months, becomes an excuse to quit. The stack was Rails, GraphQL, React+Redux, MongoDB, GCP, Netlify, Heroku, and CloudFlare, Heroku’s free dyno, free add-ons, GCP’s perpetual free tier, MongoDB’s free tier up to 500MB, and Redis at 25MB. He packed as much data as possible into that 25MB of Redis and served every response from cache, keeping response times under 5ms per the Heroku logs. Data only gets written back to Redis when the underlying database is updated, so under normal operation the database barely runs at all. Information needed for the initial render is placed statically on Netlify. Everything after that is fetched asynchronously via GraphQL and stored in Redux. Free-tier constraints, converted into speed through design.

Failure factors the author names himself

The article lists “3 things you must not do in indie development.” Building something first and saying “I’ll figure out monetization later.” Building something first and saying “I’ll figure out content (getting enough user submissions) later.” Building something first and saying “I won’t know if it’ll take off until I ship it.” He acknowledges some people advocate for each of these, but writes: “for me at least, these three were the biggest causes of failure.” It reads as a self-diagnosis of why the earlier project flopped.

The limits are also stated explicitly. The author argues there’s no correlation between technical skill and planning skill, self-rating his own technical ability, “what proportion of a concept I’ve thought through in my head I can actually implement in code”, at over 90%, while separating that entirely from whether it leads to a good concept. On the milestone itself, he calls it “only 100,000 yen,” and says he’s aiming for 100x next.

What’s reproducible, and what isn’t

The methodology still holds up today: narrow your target one level further than feels natural, break down and mimic prior successful examples, make sure the site is full of content on day one, and align your acquisition channel with your data source. None of this requires additional capital.

What’s harder to reproduce is the surrounding conditions. First, there was an external inventory of roughly 300,000 freely accessible articles. Platforms that are both open via API and have a dense, engaged user base aren’t common. Second, the intro article he posted on that same platform got traction, the author posted regularly on Qiita, and the revenue post itself gathered over 6,000 likes. There’s no guarantee an anonymous account could draw the same traffic through the same funnel. And the infrastructure environment itself has changed. Heroku’s free dyno tier, which the setup assumed, was discontinued in 2022, so the same architecture can’t be assembled the same way today.

Finally, this is a snapshot from 2018. The author has since moved on to other projects, including a self-built weekly newsletter platform analyzing individual subscription-based media. It’s most accurate to read these numbers as a record of that specific moment in time.

Related reading

• Hitode — an individual media property’s revenue trajectory, built on search traffic and content
• Carrd — a solo-run product that kept operating costs to an absolute minimum