Background

"Built Today: Digital Detox Aid" began after the initial development of the "simnabuleo" website, my sixth project, had been completed. At the time, "simnabuleo" was going through an ad monetization review, and while waiting for the result, I was thinking about the next project idea.

In previous projects, I had tried app launches, website development, in-app purchases, and ad monetization, but none of them led to a clear revenue validation. So this time, instead of launching a free app, I wanted to launch a paid app myself and see whether actual purchases would occur when I ran ads.

I chose digital detox as the project theme. Digital detox refers to the intentional practice of reducing the use of digital devices such as smartphones, computers, and social media [Wikipedia - Digital detox]. "Built Today: Digital Detox Aid" was planned not as an app that forcibly blocks usage, but as an assistive tool that helps users keep their focus time and sleep time in the form of a challenge.

This direction also came from a personal need. My fifth project, "Illuminate the Dark Dungeon", took more time than expected and disrupted my daily routine, so I felt that I needed a tool to return to a healthier lifestyle. At first, I considered an app that would help users reduce phone usage time and increase their step count. However, I concluded that measuring whole-device screen time and step count would require permissions, background execution, and platform policy review, making it difficult to implement reliably in a short period. So I adjusted the scope and centered the app around the focus timer and sleep feature.

The reasons I chose this project are as follows.

Setting the Development Goals

The development goal of "Built Today: Digital Detox Aid" was not simply to implement digital detox features. In this project, the core goal was to verify whether purchase conversions would occur after actually launching a paid app and running ads.

To do this, the app's features focused on "actions that help users use their phones less." At first, I considered whole-device screen time measurement and step count measurement as key features, but I decided that they would be difficult to implement reliably in a short period because of permission and background execution issues. So I adjusted the direction toward the focus timer and sleep feature, which users could start directly inside the app and whose completion status could be checked.

I also aimed to make use of assets from previous projects. I showed AI content from the "simnabuleo" website inside the app and connected encouragement phrase data to the phrase copying feature, extending previous projects into features for the new app.

For the development method, I experimented with Flutter app development using Claude Code. In particular, I wanted to check whether Claude Code subagents could split implementation by feature area and improve mobile app development speed and workflow.

System Architecture

"Built Today: Digital Detox Aid" is a mobile app built around digital detox features. Users start actions inside the app, and the app determines whether the actions are completed. Completion results are reflected in mileage, character collection, quests, and statistics.

The app's core flow is feature use and rewards. When a user checks AI world news, copies an encouragement phrase, uses the focus timer, or uses the sleep feature, the app stores the completion status of each feature. Based on the completion result, it then grants mileage and connects usage records to quests and statistics.

Core Implementation Flow

Permission Constraints and Feature Pivot

In the initial plan, I considered phone usage time measurement and step count measurement as core features. The structure was to reward users the less they used their phones and the more they walked.

However, during the implementation review, I confirmed that both features had major platform constraints. On Android, there is the 'UsageStatsManager' API for querying app usage statistics, but because it handles device usage records, permissions and user consent flows need to be considered together [Android Developers - UsageStatsManager]. On iOS, there is also the 'Device Activity' framework for monitoring usage activity, but Screen Time-related features require separate frameworks and policy review [Android Developers - Android health & fitness].

Step count measurement was also not simple. Health Connect can handle health data such as step counts and sleep, and it provides related data types and permission flows [Android Developers - Background Execution Limits]. However, this method is closer to reading health data recorded on the platform. It did not fully match my initial plan of immediately connecting step counts to rewards inside the app in terms of real-time responsiveness.

I also reviewed a sensor-based approach for directly measuring step count. However, that approach would require the app to keep running and would also require consideration of background execution. Since Android places restrictions on background services and execution, I judged that it would be difficult to build a stable continuous measurement structure. [Apple Developer - Device Activity]

So I reduced features centered on automatic measurement. Instead, I changed the direction toward features that users could start directly inside the app and whose completion status could be checked. Phone usage time measurement was replaced by the focus timer and phone-use detection during sleep. Step count measurement was converted into sleep habit improvement and digital detox features.

Although this decision changed the app's features, it allowed me to adjust the scope to a level that could be completed within a short period. It was not simply giving up on features, but a process of redefining an implementable scope within platform constraints.

Feature Restructuring and Reuse of Existing Project Assets

Although Built Today was designed around a single theme — digital detox — some of its features were built by reusing assets from my previous projects. Instead of creating all content and data from scratch, I reconnected existing content to fit the purpose of this app.

First, the AI World Chat feature reused data from my sixth project, "simnabuleo" Inside the app, users can see a brief preview of selected content from "simnabuleo" If they want to read more, they can tap "Read More" to open the "simnabuleo" website. Through this structure, Built Today functions not only as an independent digital detox app, but also as an entry point that directs users to an existing web project.

The Copy Encouraging Phrases feature reused encouraging phrase data from my first project, "CheerUp Mini" Users can view a short encouraging phrase inside the app and copy it by typing it out. Rather than forcibly blocking phone usage, this feature was designed as a lightweight supporting activity that gives users a small emotional reset while keeping the interaction simple.

Focus Timer and Mileage Reward Structure

I adjusted the feature scope from tracking total device usage time to managing focus sessions started manually by the user. Users can set a focus duration inside the app, and if they complete the session until the timer ends, they receive mileage as a reward.

This was an alternative design that preserved the app’s core digital detox goal while avoiding platform permission issues. The app does not automatically track the user’s total phone usage, but it encourages reduced phone use by letting users voluntarily commit to and complete a focused session.

Mileage was used as an immediate reward for completing a focus session. Instead of providing only a basic timer, I connected session completion to mileage accumulation and character collection, giving users a small reason to return to the app repeatedly.

Designing Challenge Rules for the Sleep Feature

The sleep feature was designed not as a simple sleep tracker or alarm, but as a sleep challenge that helps users avoid using their phone during the sleep duration they set. After starting a sleep challenge, the user succeeds if no phone usage is detected during the challenge period.

Phone usage was detected based on screen touches or sudden significant changes in accelerometer values while the sleep feature was running. However, right after starting the sleep challenge, users may need to place their phone on a bed, desk, or bedside table. To account for this, the first five minutes were treated as a phone placement buffer, and usage detection was ignored during that period.

I also allowed retries during the early stage of sleep. If phone usage was detected within the first 30 minutes after starting the challenge, the user could retry. After that point, the result was judged based on how far the user had progressed through the sleep challenge: failure, partial success, or oversleep failure.

This rule structure was designed to avoid treating the sleep feature as simply “success if the user sleeps longer.” The goal of Built Today’s sleep feature is not just to encourage more sleep, but to help users keep the sleep duration they set for themselves. Therefore, phone usage during the middle of the sleep period is treated as failure or partial success, while no detected activity after the scheduled end time is treated as an oversleep failure.

The sleep feature also included sleep music. When users start a sleep challenge, sleep music plays for a set amount of time and then stops automatically. This was designed as a supporting feature to help users fall asleep during the early stage of the challenge.

Local Statistics Storage and User Activity Records

Built Today stores key user activity data locally and uses it to display statistics. The stored records include major in-app activities such as AI World Chat usage, Copy Encouraging Phrases usage, focus timer sessions, sleep challenges, and mileage acquisition.

For data storage, I used SQLite. Since this project did not include complex server-side features such as login, cloud synchronization, or in-app purchases, storing activity records directly on the device was a better fit for the project’s scope and development goals.

The statistics feature was designed to help users review their own digital detox activity. Users can check records such as focus timer usage, sleep challenge attempts, and mileage earned. These records also serve as a basis for encouraging repeated app usage.

Character Acquisition and Minimal Reward Design

Built Today includes a feature that allows users to acquire characters by collecting mileage. Users earn mileage by completing focus timer sessions, sleep challenges, and other activities. Once they collect enough mileage, they can use it to draw a character.

The characters do not have any special functionality. I intentionally excluded elements that would directly affect app usage, such as stat boosts, feature unlocks, or additional benefits. Characters were provided only for collection and for filling out a character catalog, because the core value of the digital detox app was not the character system itself, but the focus and sleep challenges.

Character collection was designed as a minimal reward mechanism for digital detox challenges. When users complete focus time or sleep challenges, they accumulate mileage and can gradually collect characters. The goal was to add a small sense of achievement to self-management activities that might otherwise feel burdensome.

However, character collection is closer to a supporting element that encourages repeated in-app usage. It is difficult to view it as a core value strong enough to persuade users to purchase a paid app. In the actual project outcome, mileage and character rewards alone were not enough to drive paid conversions. This can be seen as one reason why Built Today was completed and launched from a technical standpoint, but failed as a business experiment.

Paid App Launch and Advertising Experiment

After implementing the features, "Built Today: Digital Detox Aid" was released as a paid app priced at $1. The goal was not simply to list it on app stores, but to check whether users acquired through ads would actually proceed to purchase.

I used Google Ads and Apple Ads as the advertising channels. Google Ads app campaigns can expose apps across multiple placements such as Google Search, Google Play, YouTube, and the Display Network, and they can optimize for conversion goals such as installs or in-app purchases [Google Ads Help - About App campaigns]. Apple Ads can expose apps in App Store search results and product pages, and search results ads are matched based on the direct intent signal of the user's search query [Apple Ads - Ads on the App Store].

However, the results were different from what I expected. In previous free app advertising, I had been able to generate downloads relatively quickly, but the same approach did not work for a paid app. I spent about 700,000 KRW on Google Ads, but the expected level of purchase conversion did not occur.

This showed me that free downloads and paid purchases are fundamentally different conversion goals. A freemium model typically offers basic features for free while charging for premium features or additional functionality. In that model, one of the key challenges is converting free users into paying users. In practice, acquiring free users and generating actual purchases are not the same problem. [Investopedia - Freemium Business Model: Definition, Examples, Pros & Cons]

A related article cites data suggesting that freemium conversion rates commonly remain around 2–5%. It also explains the psychological barrier known as the "Penny Gap", a concept introduced by Josh Kopelman. The idea is that the gap between free and even a very low paid price can be significant. Asking a user to pay one penny for something they previously received for free can be harder than asking an existing paying customer to pay more. [GoSquared Blog - Freemium conversion issues? Why you need to address the penny gap]

As a result, "Built Today: Digital Detox Aid" was technically completed through release, but the advertising-based paid sales validation failed. Through this experiment, I found that ads can create impressions and clicks, but they cannot create the reason to purchase on behalf of the product.