Unrushed Apps Blog

Hello World from UnrushedApps

Sat, 28 Jun 2025 00:00:00 GMT

Hi 👋 I am Samiul – a solo developer from the UK. Welcome to my blog 🎉

I have always wanted to make mobile apps, and recently I decided to just go for it. I quickly created an MVP of an app idea I had in mind and published on Google Play Store. But turns out Play Store shows the developers name and full address on the app details page, which seemed quite odd from a privacy perspective. The only way to avoid it was to publish as a company. And thus, Unrushed Apps Ltd was born 😀

While created as a mean to privacy, I am totally enjoying the feeling of entrepreneurship. It has been a while since I felt such strong sense of creativity. Not only I am building an app, I am now also building my own solo-startup. It comes with lots of responsibilities, but somehow it doesn’t feel like a chore. It feels fun!

For the last 2 months, I have been spending my 5-9 to build my app and grow my presence as UnrushedApps. It has been a fun journey. My 9-5 feeds my stomach, but the 5-9 feeds my heart ❤️.

I hope to document all my learning and adventures on this blog, cause it would be shame to forget the exciting times.

App Pause – 3 Months Progress Report

Fri, 15 Aug 2025 00:00:00 GMT

I hit 500 total downloads yesterday, just a week shy of App Pause‘s 3 months Birthday. I know it’s not a huge number and compared to other apps that go viral, the growth has been very modest, but it still feels like a big deal to me. I have come far considering I started from scratch as an App Developer.

When I started 3 months ago, all I had an idea.

No MVP.
No app.
No website.
No company.
No social media presence.

Today, I have:

An app with 500 downloads, 180 MAU and 40 DAU.
I am now director of a Private Ltd Company called “Unrushed Apps Ltd”
I have my own website, landing page and a blog with 0 subscribers.
A threads account with ~300 followers.
More experience. I have made quite a few mistakes, so I feel wiser now.

But how did I reach here? What went well and what went bad? This is the reflection on my journey.

Things that went well

Luck is always a factor and I would be lying if I denied the random fortunate events. Few places where I got lucky:

Quick MVP creation and its release: My first git commit was on April 23 and I published my app on May 20. So around a month to complete my MVP AND publish it live on Google PlayStore. That was quick. The journey wasn’t smooth and there were multiple challenges, but it could have taken much longer easily and had it done so, my motivation would have drained quickly.

Bypassed PlayStore Internal Testing Policy: I created a private ltd company to mostly hide my personal information on Google PlayStore page (didn’t feel comfortable showing my name and full address to millions of people). Turns out, if you have a corporate account with Google PlayStore, you are not required to do fullfill Google Play’s policy of getting your app tested by 12 internal testers for 14 days. That saved a lot of time!

Got Early Genuine Feedback: Right after publishing my app, I posted on Reddit to promote it. It didn’t get much traction – just a single comment from one user. But this single person gave my app a try and sent very detailed feedback by email. Next day, another user emailed me with detailed feedback. So right off the bat, I got two kind users who gave me detailed feedback for improving the app. That helped shape my road map as continued adding more features and polishing the app.

Early Positive Feedback: I got 8 five-star reviews for my app very quickly (within a month). That was motivating. I haven’t been getting a lot of reviews since then though.

Building in Public: Right before publishing, I opened a threads account to promote my app. After few posts, the algorithm started showing me accounts that were “building in public”. I got inspired by them. These folks were friendly, so I asked them questions on comments and they answered. Learned a ton. I started doing the same with my app and quickly built up a following base (as of today, 293 followers).

Things that didn’t go well

Let’s take a look at all the mistakes I made.

AdSense Account Suspension for Silly Reason: Got my AdSense account blocked. I wasn’t even trying to show ads 🤦‍♂️. I just needed to use Admob’s UMP SDK for consent management to handle GDPR and they suspended my account (for life) due to “suspicious activity”. Bruh. You can appeal it once and I already wasted my chance.

I have since then switched to a different CMP SDK and my advice to new app devs would be to stay away from Admob UNTIL you have significant userbase.

User Data Corruption During Update: Botched up a database migration during v0.11.0 release and impacted 26 users. You can read more about it here.

Didn’t Market with Trackable Link: At one point, I suddenly got a surge of new users, but I didn’t have a clue about the source. Learned the hard way about using UTM sources for creating trackable links.

Things where I need to improve

Improve the landing page: Even though I don’t get a lot of traffic to my website at all. Is there any point? I guess it’s better to stay prepared in case I start getting more visitors.

Track Referrals Better: I still have no clue where I am getting all my users from, other than organic PlayStore traffic. I have been using UTM sources with my link, but the traffic has been so little that PlayStore reports them as “Others” on the dashboard. Perhaps I can improve the accuracy somehow? Maybe integrating with Play Referral API would do the trick?

Add more features: Spend more time in development instead of worrying about marketing. Marketing really hurts the pace.

More Marketing: Launch it on more sites. I have been feeling shy about it.

Monetisation: Add a tip jar such that Google gets a cut. I hear they tend to promote apps that earn them money.

Keep on Writing on my Blog: Write about my lessons on the blog. Try to build up a newsletter on the side (why not?). I currently have 0 subscribers. If you are reading this, maybe consider signing up? 🙏

Keep on building in public

Publish on Play Store as UK Company

Mon, 07 Jul 2025 00:00:00 GMT

When it was time to publish my MVP for App Pause on Google Play Store, I had to make a decision: publish as an individual or a company. Publishing as an individual meant my full name and address would be plastered across PlayStore for everyone to see. This made me feel a bit uneasy, so I explored the alternative – formation of a company.

Turns out, creating a company in UK is relatively simple. The bare minimum requires simply filing up a form online and paying just 1 GBP! Now, I am not going to go into too much details on exactly what is needed in this post. There are plenty such guides online. I am just going to provide a brief summary of my journey in creating a Company.

If you create a company, then PlayStore will show the company name instead of your actual name. However, there is still a challenge that remain unsolved – PlayStore will also show your business address. If you use your home address as your business address when creating the company, then that will be shown here.

In order to hide your home address, you will thus need to use some alternative address when forming the company. Unfortunately, it’s not legal to use PO boxes for this address. The registered office address must have physical location where documents can be delivered and acknowledged. It’s going to be expensive to rent an actual office, but thankfully, there are cheaper options.

3rd Party Service for Buying Address

There are 3rd party services where you can buy registered office address. These locations are fully stuffed with people to accept any letters that arrive there and then they email the scan copies to you.

I used 1stformations to buy their Privacy Service. This package comes with a registered office address and a service address – the address connected to the director of the company. Without a service address, I, the director, would have needed to provide my home address for a place to contact with me 🤦‍♂️. So I had to buy both a registered office address and a service address.

All in all, I had to spend around 70 GBP to buy the addresses. It’s going to be an annual cost. Sigh.

Note, these address will only forward legal letters to you, so letters from Company House and HMRC. Any other kind of letters would NOT be forwarded to you, unless you buy another of their service. It’s all on their website. Have a look.

Creating is easy – Maintaining is a bit harder

Well, now that I have a company, what are my responsibilities? I was worried about this, but turns out this is also simple.

Create account on Company House and enable all online safety mechanisms.
Create a Corporation Tax account (you must do this within 3 months of company creation)
If you collect any kind of user information, you will also have to pay money to https://ico.org.uk/ annually.
Keep track of key events for the company decisions. I am just tracking them on Google doc.
Keep track of all money in and out. I don’t have a bank account yet cause I am not dealing with any transactions just yet (only spending money occasionally). Once I do, I should also start using some kind of accounting software. Everything is manual for now.
File paperwork annually: Confirmation Statement. I haven’t done them yet, but I don’t think they will be complicated either.

AI to make things easier

Throughout my journey, I have been asking Gemini questions to unblock me. Got an HMRC form to fill and unsure about some question? Juts take a screenshot of the form and ask Gemini what to answer. Most of the time, it can explain the question and what’s needed accurately. Everything about this process is public so AI has plenty of information to help out with your questions.

Publishing on Google Play Store

To publish on Google Play Store, I just had to wait one day after creation of my Company. All UK company automatically get a DUNS number, which is what you need to create a company account on PlayStore. Then I just had to pay 25 USD and my account was good to go.

Now I have complete privacy. On top of that, as a completely pleasant surprise, turns out you do not need 20 testers for 14 days if you have a company account on Play Console! This made releasing app much easier!

What’s Next

I haven’t faced any problems with my company yet. Then again, it only has been 2 months. I will wait a year before writing another update to this post.

Interested in following my journey? Please Subscribe to my monthly newsletter or give me a follow on Threads where I build in public. Have a question? Drop a comment 🙂

App Pause – 6 Months Progress Report

Sun, 23 Nov 2025 00:00:00 GMT

3 months ago, I posted my 3 months progress report here. I am back with a 6-month update. The second quarter was much better than the first, though I am still facing high Day-0 churn (~60% uninstall rate).

The Numbers (Month 3 vs Month 6)

Metric	Month 3	Month 6	Diff
Downloads	500	2,210	+ 342%
MAU	180	487	+ 170%
DAU	40	140	+ 250%
Revenue	$0	$111	> 999%

Here is the breakdown of what happened:

What Went Well

Focused More on Dev: In Month 3, I realized organic ASO was vastly outperforming my manual social media efforts. So instead of spending time on social media promotion, I decided to try and reduce my high Day-0 uninstallation rate. This worked out just fine since my daily download has now tripled from 10/day to 30/day (unfortunately, I didn’t manage to drive down the uninstall rate).

Discord Server: I noticed some of the apps nowadays provide support on Discord. This felt much superior than email to me. Chatting is faster + if the community is large enough, sometimes users can just help each other. Obviously everyone doesn’t have discord, so I still provide email support. The Discord server is just an alternative feedback platform. It has grown to 12 users now and frankly, I am very happy with the engagement of the community. I am getting bug reports and user feedback more frequently now.

PlayConsole Review Time: I don’t know what happened, but Play Console now takes around 30 minutes to approve my releases. It used to take 24 hours before. Thanks to the fast review, I can now easily push hot-fix for critical bugs.

Helpful Users: I am happy to say that I have some power users of the app who don’t hesitate to contact me whenever they see any bugs. Really grateful to them since they manage to catch critical bugs. For example, after just 14 hours of a release, a user reported that my “Stop Service” no longer worked. I fixed it quickly. That day, I had the highest amount of uninstall (36) and if the user didn’t report the issue, it would have taken me multiple days to notice the problem.

Revenue Validation: I know that my app is useful, but is it useful enough for people to pay? Ultimately, that’s the end goal for me: to make enough money so that I can say goodbye to my 9-5 job. My app is far from complete, so I decided to start with a tip jar first.

I integrated with RevenueCat and created a “Support Me” screen. Users could buy me coffee/lunch/dinner with various prices. I had 4 users who bought me coffee/lunch. This was a huge milestone. My app finally made some revenue.
After a month, I finally added a premium feature: Multiple Profile support. I rebranded “Support Me” screen to “Pause+” and started a subscription model. I know that some people hate subscription so I also kept a “Lifetime Purchase” option.
- Anyone who bought me cofffee/lunch/dinner, were upgraded to the “Lifetime” plan.
Happy to say that I now have: 2 monthly, 1 annual and 6 lifetime subscribers.
I made a total of $111 so far.

High Feature Velocity: I managed to add quite a few features to my app:

Major Features: Import/Export, Scheduling, Accessibility Service, Multiple Profile
More features: Delay Pause Screen, Multiple Substitute Apps, Quick Switch, Ask Every Time, Breathing Exercise, Auto Close Pause Screen, App Usage Limits

What didn’t go well

Device Fragmentation: I underestimated how differently OEMs handle background services.

I wasted weeks trying to debug user reports blindly because I didn’t have the hardware. I eventually had to buy a second-hand Samsung device just to reproduce and fix a specific UsageStats lag bug.
I don’t log to logcat in production, so it was hard to debug user issues. I solved this by implementing a local file-logging mechanism. Now, when users send feedback, they can tick a checkbox to “Attach Debug Log”. This context was the only way I managed to solve complex background service crashes.
I implemented few more ideas to make the UsageStats based monitoring service work, but in the end, it didn’t work consistently on certain devices. I added “Accessibility Service” support as an optional alternative. This reduced uninstall rate a bit.

Subscription Shock: My uninstall rate was steady at 50% but spiked to 60% when I introduced the subscription screen. Users see a paywall and immediately get their guard up, even though most features are free. I need to fix this onboarding UX.

Complex UI – Poor UX: I added “Multi-Profile” support, but it confused users (including existing DAU) so much that uninstalls spiked again. I had to build a specific “spotlight” tutorial just to explain the UI.

Next Steps

Focus on Development: Add more features. I am a developer, that’s my first instinct.
- Website Blocking, In-App Component Blocking (Youtube Shorts, Instagram Reel, Weekly/Hourly usage cap, Strict Mode: Hide stop button, restrict changing pause settings, prevent app uninstallation – More UX improvements
Focus on ASO: Improve PlayStore Listing by adding a video, better screen shots and machine translations for few other popular languages.

The whole journey has been humbling. I have come far but I can still see a long road ahead of me. If I can continue to develop my app at this pace for another 18 months, I think it can turn into a great one.

Initial Setup of Unrushed Blog

Thu, 03 Jul 2025 00:00:00 GMT

Right after creating a blog and writing Hello World post for it, I like to write a post on the efforts behind setting up of the blog. It serves both as a guide for others and a documentation for myself that I can refer to months later, just to compare the before and after state.

Here are the details:

Domain: Porkbun. I have been using them for a while and simply love them. Simple, reliable and cheap! They also have free email forwarding, which is what brought contact@unrushedapps.com to you folks.
Hosting: Cloudways. A bit on the expensive side to have a dedicated server for wordpress blog. A shared hosting would have done the job. But I have another blog running on it already, so I am now just sharing the same hosting among my two blogs.
Theme: Stratus. I could have used a default free theme. I should have. But their demo page showcasing app looked beautiful so I ended up buying it. To be honest, I would probably go for something else next time. Something that’s lighter and faster. I am stuck with this for now since I don’t want to spend more money on the theme. Let’s focus on the content for a bit shall we?
Plugins:
- Elementor: Came with the theme.
- Sitekit: Plugin by Google for Google Analytics. Pretty good.
- Rank Math: for SEO.
- Complianz: Cookie policy and Cookie popup for GDPR.
- Smush: for optimising images.
- Wordfence: for security.
- wpDiscuz: for a better commenting system.
- UpdraftPlus: for backing up blog regularly on Google drive.
Legal Pages:
- Cookie Policy: Complianz plugin created on for me.
- Privacy Policy: Created for free at CookieYes.
- Terms & Condition: Complianz has another plugin for this. Used that.

That’s it. Took me roughly three weeks to get everything set up. I am not really happy with the speed and performance of the blog, but I don’t think I can do much to improve it with this theme. If I write consistently for a year on this blog, I will switch to a lighter theme next year.

Measure Conversion Rate of On-Boarding Flow in Android

Mon, 04 Aug 2025 00:00:00 GMT

App Pause didn’t have an on-boarding flow until recently. It took me a while to implement since I wanted to measure conversion rate for it. The purpose of on-boarding is to make things easier for users, and if I don’t measure it, how would I know if on-boarding is actually helping or not?

Well, at least that was the intent. To summarise, I implemented it in the following 4 steps:

Create an on-boarding flow
Fire custom events for each step
Export data from Google Analytics to BigQuery
Visualise data on Looker Studio.

Here is what the data looks on Looker Studio at the moment:

I will now explain each of the step above in more detail.

1. Creating an On-boarding Flow

I wanted to use library to make things easier for me, and while I did find few, they didn’t match my exact vision, so I ended up implementing my own flow. Frankly, it wasn’t that difficult.

On a high level:

I created a screen on compos and put a HorizontalPager in it.
Based on the page number, I loaded different composables, where each step is one composable.
Created next and previous button that updated the page number.
Added some animation between page switch.

And done. Rest of the logic is embedded in the composable like how you would create normal screens. I used a single ViewModel across all 5 steps.

2. Firing Custom Events from each step

If you are building an Android app, you are most likely using Firebase Google Analytics already. If not, maybe consider it? Firebase, by default, collects some generic events from your app, e.g. screen views.

We just need to use that same framework to fire some custom events. Google analytics has limits to how many custom events you can fire, but the limits are pretty generous (500 per app user).

I decided to create generic custom event called “onboarding” with specialised parameters to differentiate them:

Param Name	Values
action	start, step_viewed, completed, skip
step_name	welcome, how_it_works, select_app, permission, ready

This way, I can cover multiple events (on-boarding start, complete and view of every step in between) with just one custom event. Here is the code snippet for the method I used.

fun fireOnboardingEvent(action: String, stepName: String?) {
    Firebase.analytics.logEvent("onboarding", Bundle().apply {
        putString("action", action)
        stepName?.let { putString("step_name", it) }
    })
}

3. Exporting data from Google Analytics to BigQuery

GA4 showed me count of every “onboarding” event, but what I needed to see was count of the params. To see breakdown of params for a event, you have to first “register” the param on the GA4 dashboard. It felt a lot of work tbh.

Instead, I simply exported all the data to BigQuery where it’s much easier to query such a thing. Exporting was as simple as linking bigquery integration from the admin panel. If you are using Firebase, there should already be a Google Cloud project ready for you to use, so it’s quite simple.

The advantage of BigQuery:

It’s free to store 10 GB of data each month. For small apps like mine, it’s very unlikely that I will hit such amount of data storage.
On the stored data, you can run queries. 1 TB of data process is free each month. Again, unlikely that I will hit such a limit.
- For my app with around 100 weekly active users, one of the custom query was taking around 200 KB.
- BigQuery actually provides you estimate of how much data a query might use, so that’s also useful. Always check that before running a query.
You can configure it such that when limit is hit, the query just fails, rather than incur cost.
You can delete old data to make space for new ones.

Once you export the data, it takes around 24 hours to see the first table. Each day’s data is stored in a table named event_YYMMDD.

4. Visualization on Looker Studio

Once the table was created after 24 hours, I was able to then connect BigQuery with Looker Studio, which is free to use. Here is what I created for the on-boarding event flow.

To create this, just do the following:

Insert a table
Filter events based on name “onboarding”
Add dimension: “Event Param Name Value” so that a column gets created for each value of the event
What should be the value for each row? That’s decided by metric and we can simply select record count.
Finally, go to “Styles” of the table and convert it into a bar chart instead of table.

To make things easier to digest, I also created three score card to highlight the three values:

Total users starting the onboarding
Total users who completed onboarding
Completion Rate

The instructions are a bit hand wavy, cause I don’t really want to write up a tutorial on “how to use Looker Studio”. There are plenty available for that. This article is for showing what’s possible and getting you interested in learning Looker Studio. It’s all drag and drop tbh and once you get used to it, pretty simple to visualise the data in your own way.

How I used the data

Originally, I didn’t allow skips in my onboarding flow. I noticed how users were dropping out from the first step and without skip, the only way to drop is to uninstall the app. Maybe users didn’t want to go through onboarding at all or maybe didn’t trust me enough to grant me permissions? Maybe the on-boarding flow was hurting the user rather than help them?

Instead of pissing off users and getting my app uninstalled, I decided to add a skip button. A skipped onboarding is much better than uninstall.

What I should be ideally doing is A/B testing here instead of just adding a skip button. I have never done A/B testing before, so for now, I just added the skip button to stop the leak. In future, I will start using A/B testing to fine tune the process.

At least now I have some numbers that I can try to improve. I finally have a baseline.

[Post-Mortem] Room Database Migration Gone Wrong during Android App Update

Sat, 09 Aug 2025 00:00:00 GMT

When I started using Room database for App Pause, I knew it was just a matter of time before I messed up the migration one day. I hit the milestone this week after releasing v0.11.0.

I am writing this post-mortem of the incident so that I can review this next year, along with all the other mess ups that I am sure will happen. We need to share our failures just as much as we share our wins.

Problem and its Discovery

My wife calls me to tell: “Hey! Your app isn’t working anymore.” I run to her to check what’s happening. She shows me the screen with a button: “Use for 0 minutes”.

Yup, that was a bug 🐞 I went into the app and found that all values are either 0, false or null for per-app settings, even though she doesn’t use that feature. I immediately knew that my update had gone wrong. I must have made some error in the migration logic that corrupted her data.

Got really heart broken. Just that morning I was celebrating hitting 100 WAU on Threads, and now this! I already have a high uninstall rate and this was just gonna make things worse.

Reducing the blast radius

After mopping for 5 minutes, I started to think if there was any way to stop the roll-out for the new version. Even though I released the new version 12 hours ago, not everyone received it yet.

I remember reading about halting roll-out in one of Google Play’s recent updates, so I searched for it. I found the button on console and pressed it.

Halting reduced the blast radius, but didn’t change the fact that there were damage. 26 devices had received the update already. While it was bad, at least rest of the 140+ devices were now safe.

Root Cause

I started digging into the code to figure out where I went wrong. So here is what I was doing:

@Entity(
    tableName = "per_app_settings",
    ...
)
data class PerAppSettings(
    @PrimaryKey(autoGenerate = true)
    val id: Long = 0,
    ...
    @Embedded
    val appConfig: AppConfiguration? = null
)

data class AppConfiguration(
    val waitingPeriodInSeconds: Int,
    val gracePeriodInMinutes: Int,
    val appUsage: AppUsageSection, <--- New
)

In the recent update, I added a field to the embedded object appConfig called appUsage. I first altered the table to add a column for this new field, and then populated it with a default value (“BARCHART”) since it’s meant to be non-null.

The latter part was the bug and purely my fault for not understanding how embedded fields worked in Room database. I thought since appUsage is non-null, I must put non-null value in it. Wrong!

The database has no concept of AppConfiguration object or AppUsageSection. In it’s eye, appUsage is just a string column which can be null. The Room database uses converters to convert the raw fields into the kotlin objects as required.

Since I used AppConfiguration as nullable embedded field, Room behaves as following:

Flatten all the fields from embedded class into the table.
If EVERY field of embedded class is null, then treat AppConfiguration as null and don’t convert it.
If ANY of the field is non-null, treat it as non-null and convert it to AppConfiguration object.

By updating every appUsage value to BARCHART, I inadvertently ended up marking the embedded field non-null, and when Room tried to convert it to an object, it converted the null into their corresponding default values (0 for integer, false for boolean and null for string).

Fix and Recovery

Once I understood the root cause, the fix was simple.

Don’t update appUsage field for ALL rows.
Just update it for rows that already have non-null AppConfiguration. That’s detectable by querying for non-null grace-period.

But this just fixes the migration for those who hasn’t migrated yet. What about the 26 people whose data got corrupted during migration? I needed a way to fix their broken state.

For them, I ended up bumping my database version again to v6 and wrote a version-5-to-6 migration logic. As part of this, I queried all rows that have grace-period column set to null, but appUsage field set to non-null. These should never happen ideally and indicate a corrupted row. For these I set all fields to null again.

Then I tested the flow few more times and shipped the update (after a 24 hours review period).

After thought

This brings me to the question: what can I do to avoid such a scenario in future?

Few things I can improve:

This bug impacted per-app configuration, even if user didn’t use the feature. Very few user uses this feature, yet everyone ended up suffering from the bug. This shouldn’t be the case. I have decided to make per-app configuration a toggle switch and for those who have it turned off, in future, they won’t be impacted by any bug in per-app configuration.
Even as the author, it took me a while to realize that the pause screen was showing config from per-app configuration. The detection should be simpler. On pause screen, I should show some icon to differentiate configuration from per-app vs dashboard.
It takes 3 clicks to reach per-app configuration. I should make that easier.
I had no way to communicate to the impacted users that I am aware about the bug, fix is coming and there is a workaround. I am gonna explore if there is any way to push message to my app’s home screen from Firebase (to apps on a particular version).
I learnt a lot from this mistake. That’s the only consolation I can give to myself at the moment. I wouldn’t be surprised if I lose some users due to this issue and that sucks. Took me a long time to hit 100 WAU.

Oh well. Mistakes are part of the journey. Let’s just hope I don’t repeat the same mistake again.