14 years of solo development to reach ¥1M/month — the revenue curve from 290,000 page views for ¥100,000 to 4.22 million page views for ¥1M

Nine stages of the page-view-to-income relationship, disclosed

Solo-developer revenue articles usually end at “here’s how much I made.” What makes the note published in July 2019 by SiRO (a former systems engineer who spent about 10 years at an IT services firm before leaving to develop full-time) a valuable reference is that each stage of monthly income is paired with the page-view figure at that exact time. He ran multiple web services solo, with zero outsourcing. Under this constraint, he writes, it took 14 years.

Page views and revenue at each milestone, plus the implied per-unit rate

The right-hand column is a straightforward division done by our editorial team, but the shape of the curve is unmistakable. Up through ¥300,000/month, 2–3 thousand page views were enough to earn ¥100. At the ¥400,000 stage, that suddenly jumps to 6.7 thousand. Page views grew 3.8x, from 700,000 to 2.67 million, but income only grew 1.3x, from ¥300,000 to ¥400,000.

And the ending is even more interesting. At ¥800,000/month, traffic was 4.44 million page views. At ¥1,000,000/month, it was 4.22 million. Page views went down while income went up 25%. His peak traffic was 4.5 million page views, with daily income in the range of ¥10,000–40,000.

What happened in the back half of these 14 years wasn’t “a competition to grow page views.” The real substance of reaching ¥1M/month was recovering the per-pageview revenue rate that had plateaued at the 2.67-million-page-view mark, over the stretch up to 4.22 million page views. The article doesn’t explicitly state what recovered that per-pageview rate, so it can’t be stated definitively, but it seems reasonable to read it as the cumulative effect of the monetization tactics he lists (AdSense, affiliate, direct-sold ads, and repeat-user acquisition) layering in over that stretch.

The turning point: the decision to abandon user-submission-based services

He states plainly the moment the trajectory changed. The first five years were a string of failures, building things, then tearing them down, over and over. The cause was betting on user-submission-based services, where an unknown individual has no ability to draw in enough submissions.

From there, he made a pivot: “I stopped doing submission-based services and started building things more like convenient tools instead. This way, they can provide value even with no users.” Before-and-after numbers around that specific pivot aren’t given in the article, so a quantitative before/after comparison isn’t possible. But the structural distinction is clear.

A submission-based service draws its value from other people’s actions. With zero users, value is zero, and there’s no way to create a reason for people to show up when starting from zero. A tool-type product, by contrast, has functional value the moment it’s published. A user arriving via search can get something done even in a completely unattended state. If the biggest constraint in solo development is “no ability to draw an audience,” shifting to a format that doesn’t require that ability amounts to redesigning the premise itself, not to avoiding the constraint. His later strategy (launching as a tool first, then adding submission features afterward) is an extension of this same understanding.

Compounding assets, not chasing single hits

Another factor at work is horizontal reuse. For services in similar genres, he can directly reuse registered user lists, data, and source code from earlier projects. He writes that this creates an advantage where “something that would take a new entrant months, I can implement in days.” Behind arriving, over 14 years, at running multiple services simultaneously is the fact that he wasn’t building each one from zero, one at a time.

His approach to sourcing ideas also leans toward observation rather than guessing. He solves inconveniences only someone with direct experience would notice, works backward from technology or data he already has on hand, picks up complaints from social media, and builds ahead of features an influential person might want. He also gets inspiration from competitors. He rates one method in particular, finding an “it’d be handy if there were something like this” post on X (Twitter) and turning it into a service, as “pretty close to a sure-fire method.”

The way he sequences monetization is also instructive. AdSense delivers overwhelmingly strong revenue but comes with strict policies. Affiliate has been a struggle to align with his own services. What turned out more valuable, he says, was special rates and early access to information from ASP (affiliate service provider) reps. For direct-sold ad space, he offered it cheaply as a kind of free sample, letting the advertiser profit first to build trust before moving to a formal paid arrangement. The throughline is “provide value first”, no ads right after launch, sending useful information via newsletter before placing affiliate links, and so on, applied consistently in that order. Some of his services have surpassed 10,000 registered users and still aren’t monetized.

Costs and risks that are easy to overlook

Operating costs are surprisingly small. Combining AWS, GCP, roughly 15 VPS or rented servers, and 10 domains, the total comes to ¥20,000–30,000/month. Outsourcing costs are zero. Against ¥1M/month in revenue, that fixed-cost base means, in terms of profit margin, nearly all of it stays in hand.

The latter half of the article, on the other hand, devotes considerable space to a record of incidents. One episode: he received a legal warning from a data-source company over scraping, responded quickly, apologized, and was let off. Takedown requests over defamation or privacy violations arrive on a regular basis. There’s the risk of a huge BigQuery bill or “cloud bankruptcy” from an EDoS attack. He’s careful about JavaScript usage in the wake of the Coinhive incident. During his side-hustle years, there were services he had to shut down because he couldn’t keep up with maintenance, which pushed him toward design principles like “don’t build services likely to require heavy maintenance” and “prioritize automation even at some cost to quality.” On cloud infrastructure specifically, he offers the practical judgment that it tends to run expensive for a solo operator, and VPS is generally sufficient.

His view of technology also shifted along the way. He initially mistakenly believed technical skill was what determined earnings. What actually mattered, he concludes, was simple design and speed. Solo-development productivity is more than 10x that of large-scale corporate development, he reckons, but that’s because there’s no coordination overhead or documentation burden weighing it down.

What’s replicable, what isn’t

What’s transferable is the choice of format and the sequencing. Don’t bet on a submission-based model when you have no ability to draw an audience. Start with a search-driven tool that’s useful on its own, and add submission features once people have accumulated. Reuse data and code across similar genres. Avoid designs that are heavy to maintain from the start. All of this can be judged independently of any particular skill set.

What’s harder to replicate is the underlying condition. He’s able to solo-manage roughly 15 servers within ¥20,000–30,000/month precisely because of the implementation experience he built up over 10 years at a systems integrator. And, more than anything, the 14 years itself isn’t a length of time you can run as a side project on the side. On top of that, given that his revenue pillars are advertising and SEO, the risk that a search algorithm change reshapes the landscape overnight never fully disappears. He writes that even after reaching ¥1M/month, new anxieties arose, which is exactly why he’s continued diversifying his monetization and building new services. His own self-assessment of where he stands after these 14 years: “still not secure.”

Related reading

• MENTA to Lancers — the exit of a solo-developed service
• ¥10M/month and “80% of my articles dropped in ranking” — the ceiling and fragility of depending on search