Lessons from Building a Side-Project App

Note 1: This article was written in 2018 and originally published on Xiao Zhuanlan. It was edited and moved to this blog in 2025. Note 2: The app discussed here, Shijing, has been removed from all app stores, so there is no need to look for it. Note 3: This article was written some time ago, so parts of it are no longer applicable. For example, apps did not need to be registered with the authorities at the time.

This article summarizes what I learned from building a small side project this year and shares some of its analytics. Perhaps it will be useful for your next side project.

First, a quick introduction: Shijing was an Android app—a simple, charming app for learning classical Chinese poetry. It let users search for poems, browse poems and poets, get poetry recommendations, and add a poetry widget to their home screen.

Below is its main interface. The design was fairly simple and easy to use.

Now, let me share some development lessons and app data in more detail.

1. Product Positioning and Monetization

Once you have an idea for a side project, you need to position it. What pain point does it solve? Who are its target users? How willing and able are they to pay? Which features will you charge for, and what will the pricing model be?

An app for learning poetry is clearly a niche product. It addresses the need to look up and read poetry on a phone. You might say, “I can do that in a mobile browser!” True—but reading poetry in a browser is a worse experience. After all, people who want this are literary types; we can be a little particular. My target users were mainly students, including high-school and university students. Clearly, they did not have much purchasing power or willingness to pay, so I never expected significant revenue.

Shijing's main paid feature was saving poems, which may seem unusual. I reviewed many competitors, and none charged for it. My reasoning was that many competitors were free because their data was stored only on the device: uninstall the app, and it was gone. I did not think that was a good experience. Since I was building the app, I wanted to store users' data on a server, so I made saved poems a key paid feature.

I chose a subscription model—monthly, six-month, and annual plans—with no lifetime purchase. On the one hand, users who liked the app could keep subscribing, giving me recurring revenue. On the other, I worried about the services I depended on, including backend data storage and payment integration. With a one-time purchase, I would be in a difficult position if any of those services stopped operating. Do not assume that is rare; it happens easily. In fact, learning that LeanCloud's mobile analytics service was being discontinued was what prompted me to write this article and share these figures. Another common model is advertising: integrate an ad SDK, insert ads on certain screens, and wait for revenue. But Shijing served a niche audience with limited traffic, so ads were not realistic—and I personally dislike ads, so I did not use them. I later built a simple Shijing mini program that monetized free users through ads. The result was dismal: about the price of two bottles of drinks per month.

The chart below shows revenue since March 1 this year. So far, total revenue has exceeded RMB 10,000. There were more paying users when paid features were first introduced; once new-user growth stabilized, so did revenue. This side project did not earn much, so after finishing it I mostly stopped adding features, fixing bugs and releasing occasional updates instead.

2. App Stores and Software Copyright Registration

I recommend applying for software copyright registration while you are still building your product demo. It takes more than a month to obtain, unless you pay extra for expedited processing. You can use an agency for around RMB 200. It will provide templates, explain how to complete the forms correctly, and handle everything else once you submit the required materials.

Why apply? Many Chinese app stores require developers to provide a software copyright certificate before listing an app, including Tencent MyApp and Huawei AppGallery. Do not forge one. Stores with looser review processes, such as 360 Mobile Assistant, may let you publish, but if some stores discover a forged certificate, you may never be able to list the app again. It is not worth the risk.

Some Chinese app stores, such as Coolapk, do not require software copyright registration, so you can use them to test the waters before receiving your certificate. Others, such as Alibaba's app distribution platform, only require an individual developer disclaimer. One amusing case was Smartisan's app store: before I even submitted Shijing, it crawled the app. Smartisan then asked me to prove I was the developer in order to claim the listing, and did not require a copyright certificate. The strangest were OPPO and vivo's app stores, which did not support individual developers at all. I have never forgiven the blue and green phone makers for that. Did I miss the Flyme app store? I would rather not mention it. Meizu may genuinely have had no staff left: every review took forever, ended with an inexplicable rejection reason, and eventually I gave up on the channel.

App stores usually require developer verification before you can publish, so register and verify as a developer early—ideally before you begin development. Approval takes a few days. One odd experience I had was failing Sogou's developer verification, so I abandoned Sogou Mobile Assistant as a channel.

Whether to publish on Google Play also depends on product positioning. Shijing promoted traditional Chinese culture, so Google Play did not add much value. In practice, it had very few users there, and publishing on Google Play required adopting Google's billing mechanisms, which meant substantial code changes.

Shijing was previously available on Google Play. During development, I created a dedicated googleplay product flavor, removed the integrated payment feature to make it free, and switched analytics to Firebase. I later removed it because Google Play detected the app's built-in update mechanism.

3. Content, Data, and Asset Copyright

When building a side project, never take content licensing lightly. Know where the data in your app comes from and whether it presents copyright issues. And this applies to assets as well as data.

The poetry data in Shijing came from the Ancient Poetry website, which has a rich collection of poems and poet information. After scraping and organizing the data, I open-sourced it on GitHub as poetry. If you are interested, you can use my open-source data to build your own poetry app—with no data copyright concerns.

Early on, Shijing also had an asset copyright dispute. Its logo and the little whale animation on the home page were materials shared by a designer on Lottie. I had checked that the site's license allowed free use, modification, and commercial use before using them. Later, a Shijing user told me the designer had accused me of copying on Weibo. Embarrassingly, the logo conflicted with one for another product the designer was about to release. I hurried over to explain the situation. The designer eventually clarified on Weibo that they had overlooked the site's license and agreed that I could continue using the assets. So do not overlook content licensing.

4. Testing in a Small Community, WeChat Feedback, and Yun Tucao

I recently came across a saying that roughly means, “If you are happy with how your product performs on its first launch, you launched too late.” In other words, do not wait until everything is ready; launch early to test the waters. I think this is especially important for side projects. Before launch, it is all in your head. Only after launch may you discover that it does not truly solve a user problem, and the project may die before it begins. Shijing first tested the waters in the small Coolapk community for several reasons: 1. publishing there did not require software copyright registration; 2. its users closely matched Shijing's target audience, mainly students; and 3. Coolapk users were accustomed to giving feedback and suggesting improvements. I also created a WeChat group for interested users, and many offered thoughtful suggestions.

As the app improved, I no longer needed the WeChat group for issue reports. The app included an entry point for Yun Tucao, which was easy to integrate and made handling user feedback easier. With a few custom parameters, I could see the phone model and app version used by each person submitting feedback, which helped me respond.

5. Accounts and Payment Integration

No one wants to register an account just to use an app like this. But the app had in-app purchases—what else could I do? Without an account system, how could I know whether someone had already paid? This makes accounts one of the biggest challenges for independent developers. Without a business license, an app could not use WeChat sign-in. I surveyed Shijing's WeChat feedback group: very few people wanted to sign in with a phone number, followed by email. So I ultimately used traditional username-and-password registration and sign-in.

An idea: Here is a theoretically viable approach to account systems. If I had not already built one, I would have used it. Without a business license, you cannot use WeChat sign-in, but a normal app can still open a WeChat mini program. In the mini program, you can ask users to authorize access to their information, obtain their openId, then pass it back when returning to the app. That effectively creates “WeChat mini-program” sign-in and indirectly solves the difficulty of building your own account system.

The second major pain point for independent developers is payment integration. Without a business license, you cannot obtain WeChat Pay or Alipay access, so you must find another route. Some intermediary payment platforms exist: users pay the third party, which periodically transfers the collected funds to you while charging a fee. (These platforms are fairly discreet, and publicizing them could lead to penalties or shutdowns, so I will not name them here. The image below shows one platform's pricing.)

6. Crash Reporting and App Updates

Shijing included Bugly for crash reporting and app updates. Crash reporting is absolutely essential; otherwise, you will not know what went wrong after release. In China, I recommend Bugly for crash reports. Keep the mapping file for every published version and upload it to Bugly after release, so crash stack traces are immediately understandable. Bugly also has a useful tagging feature. I assigned each screen in the app a tag, so when a crash occurred, I could tell which screen it came from.

As for app updates, I did not pay attention at the time and published to Google Play without changing the code. Google Play detected that the app included its own update mechanism, penalized it, and removed it. If you are publishing to Chinese channels, I still recommend including in-app updates: it is easy to accidentally ship a mistake, and Bugly's emergency patch delivery can help.

Below are the full-version updates pushed by Shijing. The data shows that only about one tenth of users typically chose to upgrade, so whether to add an update mechanism depends on your situation.

7. Promotion and Campaigns

Once the app is built, it naturally needs promotion. But what can a cash-strapped developer do without an advertising budget? I especially want to thank the Coolapk community and Zui Mei Apps. In the period after Shijing launched on Coolapk, it received several recommendation opportunities, giving it excellent exposure and steadily increasing downloads. Through a friend's introduction, I also met a Zui Mei Apps staff member, who promoted Shijing for free and ran a Weibo repost giveaway. Many thanks.

Beyond those approaches, developers may only be able to promote their work in relevant communities. I cooperated with other app developers on cross-promotion, answered questions on Zhihu, published promotional articles on SSPAI, and posted in Baidu Tieba and Douban poetry groups. But those posts were soon removed as ads. Promotion is genuinely not simple.

One reminder: when promoting your product, track the effectiveness of each channel. In simple terms, they may all point to Shijing's download page, but you should know which channel brought a user there and how much traffic each route drove. That is the best way to learn which promotional path works for your app.

The chart below compares acquisition channels using LeanCloud's marketing analytics for Shijing. Promotion through Zui Mei Apps was the most effective, followed by users who downloaded the app after finding my Zhihu answers, then users who were directed from the Shijing WeChat official account.

8. Mobile Analytics

Finally, let us talk about mobile analytics. I recommend integrating analytics into your very first release. Why? Because the necessary data can show you how people use your app and guide you toward decisions that better serve your target users.

Shijing used LeanCloud's mobile analytics service. To compare data, I also integrated Jiguang analytics. The numbers from the two systems never matched exactly, but the overall picture was similar. For the Google Play version, I used Google Firebase, but it had too few users for meaningful analysis. So let us focus on LeanCloud's data below.

This chart shows user growth. It grew quickly at first, then after stabilizing, added fewer than 100 users per day and held around 1,500 daily active users. I know—that is painfully small~~~

This chart shows active users from different channels. Coolapk users were the most active, followed by Smartisan's and Xiaomi's app stores. Both stores had a spike, which I suspect came from a free app recommendation that sharply increased impressions and downloads.

This chart shows the events I reported. I defined many of them, down to every user tap, pull-to-refresh action, and load-more action.

To make it easier to see the success rate of key events, I created some event funnels. I also reported data on the duration of every request, which helped identify where the user experience might suffer.

This chart shows the geographic distribution of users. People in Guangdong, Jiangsu, Shandong, Henan, and other regions really did seem to love learning more, haha. Why is this useful? BaaS or CDN services may require you to choose a server region, such as East China, North China, Hong Kong, or overseas. Knowing your users' geographic distribution helps you decide and deliver a faster, better experience.

This chart shows the distribution of users' phone models. Xiaomi and OnePlus phones appeared to be more popular with student users. This is useful too: once you know the main phone models and OS versions used by your target users, make sure to prioritize those mainstream devices whenever a feature requires device-specific adaptation.

This chart shows user navigation paths. Most people entered through the home page, at a little over 55%. Just over 31% went directly to a poem's detail screen by tapping the home-screen widget. A little over 3% went directly to search through app shortcuts, which were supported only on newer operating systems, so the smaller share makes sense. Of users who entered through the home page, 13% viewed the daily recommended poem, while 10% went directly to search. This analysis is highly useful for improving the app experience: for example, it shows which screens people spend more time on, and therefore which screens might suit certain types of ads. It can also show the day's peak usage periods, so if you need to send a notification, you can prioritize those times.

All right, I have rambled on enough. It is late, so I will stop here. If you read this carefully, you have probably felt how difficult it is for individual developers to get an app out into the world. I truly admire independent developers and founders. I hope this article is useful for your own side-project journey.