I've been developing mobile apps since 2018, and there's something I've noticed over the years: no matter how simple an app starts out, certain capabilities tend to become necessary sooner or later.
The MVP Misconception
When starting a new mobile app, one of the first questions is usually: What's the minimum we need to build before launching?
That's a fair question. The whole point of an MVP is to validate an idea without spending time building things nobody might ever use.
But I think there's an important distinction we sometimes overlook: keeping an app simple doesn't mean leaving out the things it needs to run reliably in production.
I can probably guess what you're thinking: Why build something you don't need yet?
I agree. I'm not suggesting we add features just because they might be useful someday. But after working on different mobile projects, I've noticed that certain needs keep coming up. Crash reporting, analytics, notifications, and update management are good examples.
These aren't necessarily difficult to add later. My point is simpler: if we already know we'll probably need them, why not consider them from the beginning?
Once an app reaches the App Store or Google Play, a new phase begins. Real users start interacting with it on devices we haven't tested, under conditions we can't always reproduce. Bugs appear, requirements change, and new versions need to be released.
That's why I believe a production-ready app needs more than its core business features. We also need ways to understand what's happening, respond when something goes wrong, and keep the product evolving.
You Can't Fix What You Can't See
Imagine launching an app that works perfectly on every device you've tested.
A few days later, users start reporting that it occasionally crashes.
Where do you start?
Without production monitoring, you're relying on user descriptions and your ability to reproduce the problem. And anyone who has tried to reproduce a bug that only happens on someone else's device knows how frustrating that can be. Trust me, I've been there more times than I'd like to admit. 😅
Crash Reporting
For me, crash reporting is one of those capabilities that should be there from the first release.
When something goes wrong, we need to know about it. Ideally, we should be able to identify the affected app version, operating system, device, and stack trace without asking the user to explain everything.
Crash reporting also helps us understand the scale of a problem. Is this happening to one person or hundreds? Did it start after the latest release?
Tools like Firebase Crashlytics or Sentry make this possible.
Which one you choose is less important than having that visibility in the first place.
Of course, not every problem causes a crash.
An API request might fail. A payment operation might return an unexpected response. A background task might stop working while the app continues running normally.
These problems can be just as important, but without proper error monitoring, they may go unnoticed.
Product Analytics
Crash reporting helps us understand when something breaks. Analytics helps us understand what people actually do with our app.
Are users completing the registration process? Which features are they using? Where are they dropping off?
Without that information, it's easy to make product decisions based on assumptions.
I'm not suggesting we track every interaction. I think it's better to start with a few meaningful events that tell us whether the app is doing what it's supposed to do.
For example, if registration is an important part of the product, knowing how many users start and complete that process can already tell us something useful.
Firebase Analytics is one option for collecting this information, provided we handle user data responsibly and respect applicable privacy requirements.
The goal isn't to collect as much data as possible. It's to have enough information to make informed decisions.
Every App Needs a Way to Evolve
One thing we can be certain of is that our app will change.
We'll fix bugs, introduce features, update dependencies, and adapt to new operating system versions or backend requirements.
So it's worth thinking about how we're going to handle those changes before the first release.
Application Updates
Publishing a new version to Google Play or the App Store is only part of the process.
Not everyone updates immediately. Some users disable automatic updates, while others keep using older versions for weeks or even months.
That means we may have several versions of our app running in production at the same time.
And we need to be prepared for that.
Version Management
Let's say our backend introduces a change that an older app version doesn't support.
What happens to users who haven't updated?
Do we ask them to install the latest version? Do we prevent them from continuing? Can the backend remain compatible with both versions?
These are decisions I'd rather make during development than in the middle of a production issue.
A basic version management strategy can help us distinguish between recommended and mandatory updates, define minimum supported versions, and communicate clearly with users.
Of course, forcing an update shouldn't be our default solution. Maintaining backward compatibility whenever possible is just as important.
Over-the-Air Updates
Depending on the technology we're using, we may also have the option to deliver certain updates without publishing a new version through the stores.
In React Native projects using Expo, for example, EAS Update allows compatible JavaScript and asset changes to be delivered over the air.
That can be especially useful when we need to fix something quickly.
But OTA updates have limitations. Changes involving native code or dependencies may still require a new binary, and we must respect the distribution platforms' policies.
I'm not saying every project needs OTA updates. I just think it's worth understanding whether they're an option before we need them.
Communication Is Part of the Product
Another capability I've seen become important as applications evolve is communication with users.
Maybe we need to notify someone about a transaction, remind them about an upcoming event, or announce something relevant.
Depending on the product, notifications can become an important part of the experience.
Push Notifications
Push notifications may not appear in the initial requirements, but they're worth considering when the product is likely to need communication outside the app.
And there's more to them than simply displaying a message.
We need to think about notification permissions, user preferences, device registration, and what should happen when someone taps a notification.
Services like Firebase Cloud Messaging or OneSignal provide solutions for delivering push notifications.
Does every app need them from day one? Of course not.
An offline calculator probably doesn't need push notifications. But if we're building an application where reminders, alerts, or transactional updates are likely to matter, I think it makes sense to consider that early.
Update Notifications
There's another type of communication that's easy to overlook: letting users know when they should update the app.
Sometimes an update introduces improvements. Other times, it fixes a critical issue or addresses a compatibility problem.
We should have a clear way to inform users when an update is available and, when necessary, explain why it's required.
It's a small detail that can make the experience much less confusing.
Essential, Recommended, or Optional?
Now, you might be wondering whether all of this defeats the purpose of building an MVP.
I don't think so.
I'm not suggesting that every application needs every capability I've mentioned. A banking app, a social network, and a simple offline utility have very different requirements.
What I'm suggesting is that we should make these decisions consciously instead of ignoring them because they aren't part of the initial business features.
Here's how I'd approach the capabilities we've discussed:
| Capability | My recommendation |
|---|---|
| Crash reporting | Have it from the first public release |
| Error monitoring | Start with basic visibility |
| Product analytics | Track a few meaningful events when appropriate |
| Store release process | Have a reliable process before launch |
| Version compatibility | Think about it early |
| OTA updates | Evaluate based on the technology stack |
| Push notifications | Consider early if communication is relevant to the product |
| Update notifications | Have a way to communicate important updates |
These aren't strict rules. They're simply starting points that have worked well for me.
And there's a question I like to ask when thinking about these decisions:
If we need this capability three months after launch, will we wish we had considered it earlier?
If the answer is yes, maybe it's worth addressing now, even if we decide to postpone the implementation.
Build for What Happens After Launch
An MVP is about building only what's necessary to validate an idea. I completely agree with that approach.
But launching an app isn't the end of development. It's the beginning of a different stage, one where we have real users, unexpected problems, changing requirements, and a product we need to maintain.
Over the years, I've noticed how often the same operational needs come up across different mobile projects.
That's why I believe it's worth thinking about them from the start.
We don't need to implement everything immediately, and we certainly don't need to overengineer a simple application.
We just need to recognize the difference between features we might never need and capabilities that help us operate and maintain the product we're building.
Keep the MVP simple. Just make sure it's ready for what comes after launch.
Bye!!
Top comments (0)