.webp)
The harsh reality we see in the market: mobile banking apps usually do not fail when they launch. They fail years later, when the codebase grows, more teams join, and delivery speeds up.
When the project outlives the people who built it
Banking apps are large applications and long-term projects. It's natural that people leave and new people join during development. Multiple teams cooperate, each responsible for part of the system. The challenge is making sure the project does not lose know-how when someone moves on.
"Set up the project to keep the know-how itself, not the people on it."
Most of that comes down to documentation, but more than just Confluence. It is code-level documentation that explains why something was chosen and why not. To-do and fix-me comments with a date, a reason, and a ticket. UX descriptions written for the next developer who will read them in two years. A design system that someone can actually use without asking the original author.
None of this is glamorous. In a project that runs for years across multiple teams, it is what separates structured delivery from constant rework.
Architecture that earns its complexity
Every architectural decision made in year one will either protect you or constrain you in year four. Most teams only discover which one it was when delivery starts slowing down and nobody can explain why.
"There is no single good architecture. Every company and every developer has their own. What we love is clean architecture."
Clean architecture, layered from system-dependent to system-independent code. The practical payoff is simple. When you need to change the network library, you change the network layer. Nothing else breaks.
Advanced modularisation takes this further. We typically work with more than 100 modules, which lets us control precisely what is exposed across the system and what stays internal.
By default we use Kotlin Multiplatform to share business logic across Android and iOS. Behaviour stays consistent. Bug fixes are usually applied once, in one pull request. Development time drops by around 40%. We keep the UI platform-specific, because that is where you need full control over animations and the native feel users expect.
One principle runs through all of it: always validate, including your own steps.
"I was the architect who designed the patterns and the rules. And then, on a later change, I broke them myself."
Code review by developers is not enough either, things slip through. So we build projects with automated checks: architecture and packaging rules, quality gates measuring coverage and duplication, code that flags itself when someone uses a forbidden or duplicated library.
AI-assisted development without losing the codebase
The same principle now extends to a new participant in the codebase. AI agents generate code at a pace human teams cannot match. Used well, they save time, reduce repetitive work, and free experienced developers to focus on the decisions that matter. Used without rules, they drift away from the level of quality a banking project depends on, and they do it fast.
The distinction we draw internally is between AI-assisted development and what is often called vibe coding. AI-assisted development means experienced developers using AI to generate substantial portions of code, then reviewing and refining it against established standards. Vibe coding is closer to prompting your way to a working prototype. The first belongs in production banking apps. The second does not.
To keep AI output aligned with how we want code written, we built the Flow Guidelines for AI project. It brings our development standards directly into AI tools, so the generated code follows the same rules a senior engineer would apply by hand.
The principle from architecture holds here too. Always validate, including your own steps, and the AI most of all. We covered the approach in more detail in a separate article.
Security stands on the same foundation
Architecture and quality controls determine how well a product scales. They also determine how much attack surface there is for someone to work with.
The two conversations are inseparable, which is why we deliver banking applications together with Wultra, who handle the security side: authentication, in-app protection, secure onboarding, and the patterns that protect users across login, payments, and 3D Secure.
In our joint webinar, Boris Filcak from Wultra walked through a real investment scam currently active in Europe. One phone call, sixty minutes, three loans taken out in the victim's name and €25,000 gone.
No sophisticated attack, no brute force. A well-prepared adversary and a chain of decisions that looked reasonable at every step. Every one of them was preventable earlier. The full breakdown, including where each intervention point sits and what PSD3 will change about liability, is in the webinar recording.
What this comes down to
Most of the decisions that determine whether a banking app holds up are made early, by people who will not be there when the consequences arrive. Architects move on. Engineers change companies. New teams join, AI agents start contributing code, security threats evolve. The project keeps running.
What survives is the discipline built into the foundation. Documentation that explains the why. Architecture that enforces its own rules. Guidelines that hold AI to the same standard as a senior developer. Security patterns that work even when users do not.
None of this is visible from the outside. It does not show up in app store ratings or feature roadmaps. It shows up in what does not happen. The delivery that does not slow down in year three. The rework that does not pile up. The security incident that does not turn into a headline.
We see this from two sides. Clients who took development back in-house years ago still come back when they need an outside view: an architecture review, a second opinion on a major decision, validation of a direction they are considering.
The conversation usually starts with code we wrote, still running, still being shipped. That is the strongest signal we get that the foundations held.
That is what we build for. Apps that are still being shipped, improved, and trusted five years after launch, by teams who can still explain why the code looks the way it does.
.webp)
.webp)
.webp)
.webp)
.jpg)
.jpg)
.png)
.avif)
.avif)
