Day 9: The MyViberNet App
We're building a mobile app for ViberNet customers. Here's what the decisions look like before a single user touches it.
Most people share apps after they ship.
I'm sharing this one while it's still being built, because the interesting decisions happen before launch, not after.
The app is called MyViberNet. It's the customer-facing mobile app for our fiber ISP. Here's what it needs to do:
- → OTP-based login — no passwords, no reset flows, no support tickets
- → View current plan and expiry
- → Check usage
- → See transaction history
- → Recharge directly from the app
Simple on paper. The decisions underneath are not.
Why Flutter:
We could have built a web app and called it done. We chose Flutter because the widget system lets you build something that feels native and looks good, without a dedicated designer. For a lean team, that matters.
Also: one codebase, Android and iOS. That's Flutter's main strength.
The decision I'm most confident about:
- OTP login. No passwords.
- Our customers are not all technical. A password reset flow creates confusion, support calls, and churn. An OTP to their phone number just works.
- Design for the actual user, not the ideal user.
The thing I'm watching most carefully:
- The backend. Laravel Sanctum handles auth, but expired token handling on the API side is where mobile apps quietly break. We are building that error handling before the happy path is even complete.
Most bugs in mobile apps aren't in the app. They're in the API.
Day 9 of my 30-day build-in-public series; sharing what I'm actually building at ViberNet and OpenLoop every day.
The journey is more interesting than the destination. People who follow the build feel ownership over the outcome, they become your first users, your first advocates, and your most loyal audience.
Build out loud. From day one.