Walica: From 50 Users a Day to 300,000 a Month, on Two Hours Every Weekend for 4.5 Years

Most indie-built services never take off, and stall out. The main reason usually isn’t money or technical skill so much as whether you can keep working through a period when growth simply isn’t happening. A record the developer of the bill-splitting service “Walica” published on Qiita spells out that the flat period lasted over a year, and that operating cost during that stretch was about 1,000 yen a year.

The service is a web app that calculates, after a trip or a night out, “who owes whom how much.” It was built by a company employee in his second year out of college, together with a colleague from the same graduating class, their first indie project together.

Four and a half years, from launch

From launch to 300,000 monthly users: roughly four and a half years. Development has continued at a pace of about two hours each weekend in recent times.

The cost structure of this business

The most easily overlooked number here isn’t revenue. It’s cost.

Early on, this ran on essentially zero cost, “about 1,000 yen a year for the domain.” It’s now running on Heroku, which exceeds the free tier at current scale, but the burden still stays within the range one person can handle on weekends. The revenue source is 100% Google AdSense, and the original article doesn’t state a dollar amount.

The implication is simple: “a full year at fewer than 50 users a day” never turned into a loss. There was no financial pressure forcing a shutdown. The reasons the developer cites for continuing are three: it was genuinely useful to him personally, friends who used it responded well, and even with a small user count, month-over-month growth continued.

Growth began the moment it started showing up in search

The Japanese version’s trajectory changed once it started ranking for search terms like “warikan app” and “warikan calculation.” The developer names this as the turning point. From under 50 users a day, it eventually reached 300,000 monthly users, roughly 10,000 a day on a simple average.

The English version has a separate turning point of its own. Spliito, released at the end of 2021, initially tried to grow via Twitter ads. The result, in the developer’s own words: ads “produce a temporary bump, but don’t actually reach people who have the underlying problem this service solves.”

So at the end of 2022, he rebuilt the entry point for acquisition. The specific steps were these three:

1. Rebuilt the landing page, previously just Walica’s homepage translated into English as-is, with actual service explanation and keyword-rich copy
2. Translated the Japanese copy to English with DeepL, then refined that English with ChatGPT
3. To decide which keywords to target, he asked a native-speaking teacher on DMM Eikaiwa: “when you’re searching for a service like this, what terms would you use?”

After this, users began arriving from many countries, India among them.

Why ads didn’t work and search did

What happened with the Japanese and English versions follows the same underlying structure.

The need to split a bill has a very specific moment of onset: right after getting back from a trip, right after a night out ends. Outside that window, essentially nobody needs this service. Conversely, someone who’s just hit that moment will almost certainly search for it.

Social ads pair poorly with this structure. Ad impressions land whenever the platform’s delivery algorithm decides to show them, so most impressions hit “people who don’t currently have a settling-up problem.” Numbers can move temporarily, but without an active need, the ad goes unused. Search works the opposite way, the moment the need arises coincides with the moment of contact. Even with a smaller pool than ads, the probability that the person who lands actually uses it is different.

There’s also a built-in reason for repeat visits with this kind of service. Trips and get-togethers happen repeatedly, so a user who found it useful once tends to come back the next time the need arises. It’s natural to read the accumulation of one-time search-driven visitors becoming repeat visitors as what carried the service to 300,000 monthly users over four and a half years.

The feature-development philosophy reinforces this reading. The developer is conservative about implementing requested features, carefully weighing what percentage of users would actually be happier and how much cognitive load each addition adds. That’s because a first-time visitor arriving from search being able to complete a settlement without confusion is the entire value proposition of this service.

What isn’t visible, and the limits of this case

Part of this story’s numbers simply aren’t public.

The biggest gap is revenue. The 100%-AdSense-dependent fact is stated, but the monthly dollar amount is not. What level of ad revenue a web service with 300,000 monthly users generates isn’t knowable from this record. The developer’s stated future direction, “wouldn’t it pay better to sell ad slots directly to companies?”, suggests he sees upside beyond current AdSense revenue, but nothing further can be inferred.

There are structural risks too. Reliance on search traffic means direct exposure to changes made by the search engine itself. Free bill-splitting is a low-barrier category, and there’s no guarantee of maintaining top rankings. Running on a single hosting provider, Heroku, as an individual operator also becomes a heavier burden as scale increases.

For comparison, the developer cites the scheduling service “Chouseisan,” reportedly with 4 million monthly users. In the same category of “small annoyance attached to an event,” a scale over 10x larger exists. 300,000 is still partway there, not a finish line.

What’s transferable, and what isn’t

What’s easy to transplant is the cost structure and the approach to keyword targeting.

If you can keep costs down to around 1,000 yen a year, a year without growth becomes simply waiting time rather than a “loss.” Not being forced into a shutdown decision is itself a functioning strategy. The way keywords were targeted here is also reproducible: the technique of “asking a native speaker of that category directly how they’d search” doesn’t require DMM Eikaiwa specifically. The underlying principle, don’t decide keywords by your own gut feel, is the transferable part.

That said, some conditions can’t be copied.

First, this depends on the problem having a clear, well-established search term, “warikan calculation.” Not every indie-built service addresses the kind of problem users articulate and actually search for. In categories without search demand, this strategy simply doesn’t apply.

Second, being a daily user himself. The developer names being “genuinely useful to me personally” as his top reason for continuing. He kept working through the year at 50 users a day not because of external feedback but because of real personal utility. Sustaining someone else’s problem, at zero revenue, for four and a half years, is a different level of difficulty entirely.

Third, sheer development speed. This low-cost structure only works given the premise that a second-year engineer can keep improving the product on two hours of weekend time. Outsourcing it would break the 1,000-yen-a-year operating cost immediately.

Related reading

• Hitode’s blog operation — a long-term domestic content property built on search traffic
• How Carrd reached roughly 200 million yen in annual revenue — a web service that scaled while staying a solo, low-cost operation