Forem: Shalen Mathew

You're not a good Indie Developer if you don't write test cases: I said it.

Shalen Mathew — Mon, 27 Apr 2026 08:24:23 +0000

I don’t claim to be an expert indie dev, but I am an active one. I’ve spent the last year building Quotes App and MovieFlix, and honestly, the process taught me more than any tutorial could. With 200+ GitHub stars between them, I figured it was time to share what I’ve learned about the solo dev grind

Being an indie dev is about wearing a dozen hats, but being a solid developer is the foundation no one talks about. You don’t need to be the next Mark Zuckerberg.

You just need to understand your project’s whole context so you aren’t spending your weekends frustrated, debugging code that’s failing silently.

Mastering your project’s context is the ultimate energy saver. It lets you hand off the coding to agents and actually relax, knowing that if something goes sideways, you’ll see it coming a mile away. Less burnout, more shipping.

As an app developer who markets and builds everything solo, my time and energy are my most important assets. Both are unfortunately limited. You really don’t want to spend your whole life on a single project that is eventually just a gamble. It’s hard to justify spending endless hours of frustration building an app when you don’t even know if it will be worth it yet.

My main principle for building projects is simple: I want the highest ROI for the lowest amount of time. Testing is a huge part of that.

While testing is important early on, it becomes a literal lifesaver once your product succeeds and you start growing a team. When a newbie with zero context starts making changes to your app, that’s usually when all hell breaks loose.

That is exactly why knowing the basics and being a good developer is so vital. It’s the only way to keep the foundation solid while things are moving fast.

Lets Talk about testing

Since I mentioned that time and energy are my most valuable assets, you might think writing tests is just a waste of both. But let me tell you why that’s not true.

Let me describe a real scenario that happened in 2 of my apps

MovieFlix: A ticking time bomb

I had a feature that scheduled movie notifications, then deleted them from the DB after 10 seconds.

When i tested manually on my device. The notification popped up. Everything looked fine.

But when I wrote an automated test, I found a ‘silent killer.’ The background worker was crashing immediately after the notification because it was missing a TypeConverter for the database.

The failure was invisible. To the user, the notification worked, but under the hood, the database cleanup never happened. ‘Dead data’ was piling up, and because the entry was never deleted, the user would be stuck unable to reschedule that movie ever again.

This is the trap: the part I could see (the notification) was fine, but the part that mattered for the app’s long-term health was failing silently. Without that test, I was shipping a time bomb

That’s exactly where testing becomes vital. When you can’t see the result instantly — like with a scheduled task or an async feature — your result is just a promise for the future. You need to be 100% sure the logic is actually going to deliver that result when the time comes.

Quotes App: A Hacktoberfest saga

Last year, my app was part of Hacktoberfest. It was a win-win: I got help building features I wanted, and other people got the chance to contribute to an open-source project.

But this is where testing became a non-negotiable part of the process. I was essentially trusting my code to developers who had zero context about how the app worked. When people are jumping in to fix bugs or add features, you need a safety net. You have to make sure that while they’re building something new, they aren’t accidentally breaking the things that already work perfectly.

To handle this, I added a workflow that runs on every pull request. It automatically checks if the new code breaks any existing features. If the checks pass, I know the code is solid and ready to go.

This setup was a massive time-saver. I didn’t have to manually review every single PR anymore. If a contribution was low ROI, I’d just merge it as long as the checks passed. That allowed me to stop micromanaging the small stuff and focus my energy on the bigger, more essential features.

Ok i showed you why testing is important , but how to do it correctly?

Look, don’t try to test everything. Life is way too short to aim for 100% code coverage. You aren’t a massive corporate entity with unlimited resources; you’re a solo dev.

Focus on the Spine: the core business logic. This is the engine of your app — the data rules, the storage, and the background processes — the core business logic- the reason your users use the app

I test for High ROI. I don’t waste time testing the ‘Skin’ (the UI) because if a button is missing, I’ll see it the moment I run the app. I spend my time testing the silent logic that I can’t see.

If your UI has a bug, it’s a glitch. If your business logic has a bug, it’s a data disaster. Stop testing the paint job and start testing the engine. Secure the core, skip the fluff, and ship code that actually works.

Use AI agents to write your test cases. Don’t start writing them manually from scratch. Today, agents are smart enough to generate the base tests for your project, but you must always cross-check the results.

Never be completely dependent on them. Like I said, being a good developer is a necessity. When you can delegate the repetitive work to save time and energy, do it.

That is all from me for today. Bye!

Why I'm Building in Public (And Why You Should Too)

Shalen Mathew — Fri, 24 Oct 2025 05:32:36 +0000

A few months ago, I did something different. I started building in public.

I've built plenty of apps before. Most of them died in my local repository, never seeing the light of day. But this time with my Quotes app, I decided to share every step of the journey online. The wins, the bugs, the "why is this not working" moments. All of it.

And guess what? The app just hit 50 stars on GitHub. ⭐

That might not sound like much compared to big open source projects, but for me? It was validation. Proof that people actually cared about what I was building.

🚀 How It Started

I've always wanted to build a Quotes app. Simple idea, right? But I'd never gotten around to it. This time though, I made a promise to myself: I'd build it in public instead of coding alone in my room like I usually do.

Android development can get lonely. And frustrating. Really frustrating. So I started posting updates on Twitter and LinkedIn. Shared my struggles with Jetpack Compose. Talked about architecture decisions. Asked for feedback.

Suddenly, development wasn't boring anymore. People were watching. Commenting. Suggesting improvements. Some even started using the app.

That external accountability pushed me to keep going. When you know people are watching, you can't just abandon the project halfway (well, you technically can, but it feels awkward).

💡 The Real Win: Learning in Public

Building Quotes app wasn't just about stars or downloads. It was about leveling up my skills.

I dove deep into Jetpack Compose. Learned Clean Architecture properly, not just surface level. Started writing actual tests instead of skipping them like before. Improved my understanding of MVVM patterns.

And here's the thing: I made the project open source. Because I learned most of what I know from other people's code. Studying open source projects taught me more than any tutorial ever could. So I wanted to give back.

🎃 Then Hacktoberfest Happened

Last year during Hacktoberfest, I wanted to contribute to Android projects. But finding good ones was... hard. Most projects were web-focused or had codebases too complex for beginners. There weren't many Android apps that welcomed newcomers.

I remember thinking, "Someone should fix this."

So this year, I did.

I opened up both Quotes app and MovieFlix (my movie discovery app) for Hacktoberfest contributions. Clean architecture, modern tech stack, beginner-friendly issues. Everything I wished existed last year.

The response? Way better than expected.

Developers started contributing. First-timers made their first PR. Intermediate devs added features. People from different countries, different skill levels, all working on something together.

It felt good. Really good.

📱 Check Out the Projects

Quotes app: A daily motivation app with modern Android architecture
🔗 https://github.com/shalenMathew/Quotes-app

MovieFlix: Movie discovery app with offline support
🔗 https://github.com/shalenMathew/MovieFlix_App

Tech Stack:

✅ Kotlin
✅ Jetpack Compose
✅ MVVM + Clean Architecture
✅ Hilt / Dagger 2
✅ Room Database
✅ Retrofit
✅ Coroutines & Flow

🤝 Why Building in Public Changed Everything

Looking back, sharing my journey publicly was the best decision I made this year.

I connected with developers way better than me. Learned from their feedback. Got motivation when I felt like quitting. Built projects people actually use.

And now during Hacktoberfest, I'm on the other side as a maintainer. Helping others the way open source helped me.

If you're sitting on a side project right now, afraid to share it because "it's not perfect yet" or "what if people judge it," just post it. Tweet about it. Write about your struggles. Share your code.

The worst that happens? Nothing.

The best that happens? You build something real, learn faster, meet amazing people, and maybe even help someone else learn too.

A Guide to Using Singleton Design Pattern in Android

Shalen Mathew — Tue, 08 Apr 2025 15:58:57 +0000

Wrote an article on 𝐒𝐢𝐧𝐠𝐥𝐞𝐭𝐨𝐧 𝐃𝐞𝐬𝐢𝐠𝐧 𝐏𝐚𝐭𝐭𝐞𝐫𝐧 𝐢𝐧 𝐀𝐧𝐝𝐫𝐨𝐢𝐝 on Hashnode . Learn all about design pattern from this article. Hope this will 𝘩𝘦𝘭𝘱 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘪𝘯𝘵𝘦𝘳𝘷𝘪𝘦𝘸 𝘱𝘳𝘦𝘱!!! 👊👊👊

https://shalenmathew.hashnode.dev/a-guide-to-using-singleton-design-pattern-in-android

A Guide to Using Singleton Design Pattern in Android

Shalen Mathew — Thu, 27 Mar 2025 04:41:15 +0000

Design pattern are some the most commonly asked interview topics

Learn all about the singleton pattern from this article : article

Quick guide to Android activity lifecycle

Shalen Mathew — Mon, 27 Jan 2025 10:48:09 +0000

Disclaimer :

(This article is intended for those already familiar with the Android lifecycle who are looking for a quick summary to prepare for an interview or as a refresher.)

The Android lifecycle defines the states an app goes through from launch to termination, handling events like screen rotations and backgrounding.

Android Lifecycle:

When you launch an app or navigate to another activity, the activity goes through this hierarchical lifecycle.

1 . onCreate()

It is called when the activity is created for the first time. It takes care of initializing essential components like views, binding data, or setting up resources.

Example: Inflate the UI layout using setContentView().

2 . onStart()

It is called when the activity becomes visible to the user, but the user can’t interact with the activity yet. It takes care of performing tasks like starting animations or initializing UI updates.

3 . onResume()

It is called when the activity starts interacting with the user

4 . onPause()

It is called when the activity goes partially out of view, like when another activity opens on top. (e.g. when a dialog box appears over an activity)

5 . onStop()

It is called when the activity is no longer visible. (e.g. navigating to another activity). This is when heavy resources are released, app data can be saved, and ongoing tasks can be stopped.

5 . onRestart()

It is called when the activity restarts after being stopped. (e.g., when the user navigates back to the previous activity from the current one)

6 . onDestroy()

It is called when the activity is destroyed either by the user (e.g., back button) or the system (e.g., low memory).

(Quick Tip: Understand the diagram and understand the hierarchy of how the functions are called)

If you want to dig deeper or trying to understand more here is an awesome video about the Android lifecycle: Android Lifecycle

Some interview questions that might be asked about this concept:

name all the Android lifecycle and their functionality
activity lifecycle behavior under different scenarios (e.g., what will be the lifecycle when you navigate to another activity)

That’s all from me 😁. If you I am lacking somewhere or this article needs some correction just comment down. Bye!!!👋