Anniversary app "365-Day Anniversary" hit 10,000 yen a month, two months after launching a subscription

Indie developer Inoue (X: @tty215_dev), who runs the anniversary-management app 365-Day Anniversary, reached 10,000 yen in monthly revenue two months after launching a subscription feature. He announced the milestone on X on May 17, 2025, and on May 25 published a note.com post detailing the design decisions that led there.

The amount itself isn’t large. Still, this case is worth covering because what’s disclosed isn’t “what sold for how much” but “which parts were rearranged, and how, to move the numbers.” It’s a story about deliberately reconnecting two revenue sources, banner ads and subscriptions, that usually work against each other.

The scope of what’s disclosed

Let’s state the limits up front. In the free portion of the note post, only two figures are given: “10,000 yen a month” and “2 months.” Download count, monthly active users, conversion rate, plan pricing, and the split between ad and subscription revenue are all absent. The paid section starts from “how I got users to choose the annual plan” onward, and this article doesn’t go into that. So what follows is a breakdown of decision-making, not of revenue figures.

What the app actually sells

365-Day Anniversary manages anniversaries. Based on what’s described in the note post, users can tag anniversaries and organize them, add custom tags, receive notifications, and create groups to invite other users. Rather than a simple date list, it’s closer to a “relationship management tool” with sharing and notifications built in.

The premium plan has 6 perks: ad removal, notification customization, unlocking the limit on custom tags, reordering/hiding tags, unlimited group participation, and unlimited group invitations. Notice that 5 of the 6 are the “remove-a-limit-on-a-free-feature” type. There’s essentially no new feature available only to paying users.

This isn’t accidental. Inoue explicitly states his policy is “to keep all features usable for free,” explaining that “as an indie developer, funds are limited and I can’t afford paid advertising, so I want to prevent users leaving due to friction and instead have them feel the value through the features.” With no ad budget, the cost of re-acquiring a user who churns is effectively infinite. So the design principle is: don’t push people away with feature limits.

Two decisions that changed the tide

This case has two turning points.

Step one: repositioning where banner ads appear. Previously, “concern about hurting the user experience took priority, so ads only showed on specific screens.” He changed this to a constant display on the main screen. In his own account, revenue increased after this change, and no negative feedback from users materialized. The magnitude of the increase isn’t disclosed, but the direction is clear: “not reducing ads but increasing them turned out to be the right call.”

Implementation details are also described. This app uses a horizontal-swipe UI for switching pages, and the banner is placed in a spot unaffected by the page switch, so it doesn’t reload with each swipe. Not reloading on every view is a design that optimizes for time-on-screen rather than raw impression count.

Step two: launching the subscription feature. This is the direct trigger for reaching 10,000 yen a month, hit two months after launch.

Why it worked — turning ads into the thing you pay to remove

What stands out is that these two decisions aren’t independent.

Normally, in-app ads and subscriptions cannibalize each other. Increase ads and the experience degrades, driving churn instead of subscriptions. Decrease ads and ad revenue falls. Many indie apps get stuck at this tradeoff.

Inoue’s design steps outside it. He cites two reasons for making the banner constant. One is “to increase time-on-screen and raise revenue.” The other is the decisive one: “to make the ad-removal perk feel valuable.”

The ad serves double duty. It generates ad revenue and simultaneously manufactures the very reason someone buys the premium plan. Increase ad exposure and ad revenue rises, and at the same time the desire to “make it go away” rises, raising subscription revenue too. Two axes that would normally trade off against each other are reconnected to point in the same direction. This is likely a large part of why the timeline was as short as two months.

This structure only works, though, on the premise that the free version remains genuinely usable. Restrict features and pile on ads at the same time, and users simply leave. “All features free” and “ads always visible” are a pairing that only functions together, copying just one half of it backfires.

The effort poured into the paywall screen

Another point disclosed in detail is the design of the purchase screen. Inoue writes: “instead of implementing on impulse as usual, I locked down the design in Figma first.” Four specific efforts are described.

Perks are shown in an accordion, so the full picture is visible at a glance when collapsed, and expanding each one reveals an eye-catching image explaining the benefit. On the pricing display, the yen symbol and the number use different text sizes, with only the number enlarged (he explicitly credits an article from the App Marketing Lab for this technique). A Q&A and cautionary notes address concerns upfront, particularly explaining that cancellation during the free trial is possible and walking through the cancellation steps by platform. The screen itself is implemented as a bottom sheet, so it can pop up over the existing screen from any entry point in the app.

What all these have in common is that every change reduces hesitation to buy, nothing else. No discounts, no limited-time offers. Carefully explaining how to cancel might look counterproductive if you only look at short-term conversion, but it’s front-loading a cost that would otherwise show up later as refund requests or a poor store rating.

What didn’t work, and what remains unknown

As Inoue himself reflects, the period when he “only showed ads on specific screens” out of concern for user experience wasn’t functioning on the revenue side. The concern itself wasn’t misplaced. It was aimed in the wrong direction. What needed restricting wasn’t ad exposure but feature access.

At the same time, a lot remains unverifiable from this article. The split between ads and subscriptions within the 10,000-yen total is unknown, and at the extreme, an interpretation like “subscriptions barely sold at all, and the always-on-ads effect just showed up two months later” can’t be ruled out from public information alone. Without conversion rate or price, a per-unit-times-count check isn’t possible either. 10,000 yen a month is a level a meaningful number of indie apps reach, and there isn’t enough material here to conclusively attribute it to this specific design.

What can you take away from this?

What’s easy to reproduce is the idea of redesigning the relationship between ads and subscriptions from “cannibalization” to “reinforcement.” Putting ad removal at the top of a premium plan’s perk list isn’t unusual in itself, but going as far as the counterintuitive move, keeping ads constantly visible to actually make that perk function, is the transferable insight. The implementation choices (locking the paywall design in Figma first, documenting cancellation steps per platform, using a bottom sheet to multiply entry points) aren’t especially difficult either.

What’s harder to reproduce is the underlying assumption. This design depends heavily on being “an app opened daily or on a regular cadence.” Anniversary management is a category driven by notification-triggered repeat opens, which is exactly why banner time-on-screen accumulates and ads become annoying enough to be worth removing. The same setup on an app opened a few times a year wouldn’t accumulate either ad revenue or the desire to remove ads. Likewise, perks like group participation and invitations only carry value because the app is designed for multi-person use. They don’t transplant to a single-user-only app.

And the hardest thing to copy is turning a lack of funding into a design principle rather than a constraint. The chain of reasoning, “can’t afford paid ads → so churn is fatal → so don’t squeeze users with feature limits”, isn’t the kind of logic a well-funded team arrives at.

Related reading

• Photo AI — a case of a solo developer accumulating revenue from a single app
• Carrd — a subscription design built around free usability