Building a mobile app that works beautifully for 100 users is very different from building one that stays performant, maintainable, and secure at 50,000 users — and different again at 500,000. Most of the mistakes teams make are invisible at small scale and catastrophic at large scale.
Last year, we delivered a cross-platform FinTech application for NovaPay Solutions — a P2P payment platform now serving over 50,000 active users on iOS and Android. It has a 4.9-star App Store rating and handles millions in transaction volume daily. It also nearly failed twice during development.
Here's what we learned.
Lesson 1: Architecture Decisions Made in Week One Are the Hardest to Change in Week Ten
The NovaPay project started with a seemingly reasonable decision: use a shared Redux store for all application state. It worked fine for the first few screens. By the time we had 40 screens and 12 developers touching the codebase, it was a maintenance nightmare — every state change could trigger unexpected re-renders anywhere in the app.
We rebuilt the state management layer in week eight. It cost us two full weeks of developer time. The lesson: spend more time on architecture in the first two weeks than feels comfortable. The cost of changing a foundational decision later is always higher than it looks.
What we use now: a combination of React Query for server state, Zustand for global UI state, and component-local state for everything else. Each layer has a clear responsibility and clear boundaries.
Lesson 2: Security in FinTech Isn't a Feature — It's the Foundation
A P2P payment application handles real money and real personal data. Security architecture needs to be thought through before the first line of code is written, not retrofitted after the MVP.
For NovaPay, this meant:
- Certificate pinning to prevent man-in-the-middle attacks
- Biometric authentication (Face ID, Touch ID, Android Biometrics) as a primary login mechanism
- End-to-end encryption for all transaction data
- Jailbreak and root detection — flagging compromised devices without breaking legitimate use cases
- Session token rotation after every sensitive operation
- Rate limiting at both API and client level to prevent brute-force attacks
We commissioned an external penetration test before launch. It found three medium-severity issues and zero critical ones. The prep work paid off.
Lesson 3: Performance Budgets Need to Be Set Early
We set explicit performance budgets in week one and treated violations as bugs, not "things to fix later." Every screen had a target: first meaningful paint under 1.5 seconds on a mid-range Android device on a 4G connection.
Enforcing this discipline forced us to be intentional about list virtualisation (every long list uses FlashList), image optimisation (WebP with progressive loading), and API response design (never returning more data than the screen needs).
The result: the app scored consistently above 90 on Google's Android vitals benchmarks — unusual for a complex financial application.
Lesson 4: Testing Across Devices Is Non-Negotiable
React Native abstracts away many platform differences, but not all of them. Keyboard behaviour, date picker UI, biometric APIs, and push notification handling all behave differently enough between iOS and Android to require explicit testing on both.
We ran automated tests on a matrix of 24 device/OS combinations using AWS Device Farm. This caught 11 bugs that only manifested on specific Android versions. Without this coverage, at least some of those would have reached users.
Lesson 5: App Store Review Takes Longer Than You Think
Apple's App Store review process is thorough and occasionally unpredictable. Our first submission was rejected for insufficient explanation of data usage. Our second was flagged for a payment flow Apple's reviewers couldn't complete with test credentials. Third submission: approved within 48 hours.
The lesson: build two extra weeks into your timeline for App Store review cycles, and test your submission thoroughly with staging credentials before submitting.
What We'd Do Differently
If we rebuilt NovaPay from scratch today, we'd invest more time upfront in a proper design system — a shared component library with documented props, accessibility attributes, and visual specifications. We spent too much time later reconciling slightly inconsistent implementations of "the same" button across 40 screens.
Scalable mobile apps aren't magic. They're the result of disciplined architectural decisions, proper testing infrastructure, and a relentless focus on performance from day one. The good news: every one of these lessons is learnable before you start, not after.
If you're planning a mobile project, talk to our mobile team — we'd be glad to share more of what we've learned.
