Designers have built the final screen. Leadership has approved them.
The software architect has created the architecture diagram and defined the API contract, which specifies exactly what data the mobile app will request and what the backend will return.
You’ve also seen how multiple teams use different technologies to build our feature.
You’ve also decided the metrics.
So now it’s time to build it and launch it, right?
Not exactly.
Because in enterprise fintech, you’re never building a feature in isolation.
That feature has to pull real relationship manager (RM) data. It has to integrate with backend systems. It has to route calls to the RM. And it has to work seamlessly alongside every other feature inside the mobile app.
That’s why enterprise software isn’t built and released in one shot.
It’s built, tested, and launched in stages.
Let’s walk through what those stages look like.
Stage 1: Lower Environments
An environment is a separate copy of the software where teams can build and test without impacting real customers. These environments are hosted in the cloud. The cloud is remote servers managed by providers like AWS or Azure.
Think of it as a rehearsal room. You wouldn’t test a new play in front of a live audience. You rehearse first.
In lower environments, each team builds its part independently.
Let’s see what each team does and why they work in separate environments.
Mobile app developers build the screen
The layout. The RM photo placement. The name and title fields. The call and email buttons.
Once the developers build the screen, the testers test it on both iOS and Android.
They check: Does the layout look correct? Does the image load properly? Do the buttons respond?
If something doesn’t match the final design, it goes back to the developers to fix.
They use sample data because at this stage, the backend systems aren’t connected to the app yet. For example, a sample RM photo, a name like “Jane Smith,” and an email address.
At the same time, backend engineers build the microservice
Backend engineers build the microservice that will return RM data following the API contract. They ensure it returns the exact fields the mobile app expects: RM name, title, photo URL, email, and phone number.
Backend engineers also use sample data. The microservice returns sample RM information—a test name, a test photo URL, a test email—so they can verify it works before connecting to real customer data.
Data engineers prepare the pipeline that pulls RM information into the data warehouse. Database engineers ensure the required data fields exist.
Why work in separate environments?
To allow work to be done in parallel.
If all teams worked in one environment, one team would block another. The mobile app team would have to wait until the backend microservices and data pipeline are done.
In lower environments, the mobile app works with sample data only.
When you tap “Call,” it doesn’t route through the actual call routing system. When you tap “Email,” it doesn’t notify the actual backup team.
Stage 2: Higher Environments
Once each team finishes building in their lower environment, the work moves to a shared integration environment.
This is where everything connects.
Now the RM screen calls the actual backend microservice, pulls actual RM data, connects to actual call routing logic, and sends actual emails.
This is where things often break.
The mobile app might expect the backend to return “RM_Photo,” but the backend returns “Manager_Photo.” Or the data pipeline takes 30 seconds to update when the app expects it in 5 seconds.
Small mismatches like these break the feature.
A dedicated testing team handles this stage. Much of the testing is automated.
The automated tests check if the RM photo loads, what happens if the RM has no photo, whether calls route correctly when the RM is unavailable, and if the backup team gets copied on emails. They also test if the feature integrates properly with other features in the app.
When tests fail, the issue goes back to the relevant team to fix, rebuild, and retest. This cycle can repeat multiple times.
Once all the integration tests pass, the feature is ready for pilot testing.
Stage 3: Pre-Launch
Once integration testing is complete, the feature moves to pilot testing.
Real users test the app. They’re called pilot users.
You invite a small group: relationship managers and a few high-net-worth clients who volunteer.
What do they test?
They call their RMs. Send emails. See what happens when the RM is unavailable. They test different scenarios to find issues before launch.
This phase usually lasts a day or two, but it happens 10 to 15 days before the actual launch.
Why the gap?
Because if something breaks, you can stop the feature from going live before one million clients see it.
It’s much easier to delay a release than to roll back a live feature that everyone has already seen.
Stage 4: Launch
Even at launch, your feature doesn’t go to 100% of users immediately.
Enterprise fintech releases roll out in phases.
For example, your RM screen might first go live to 10% of high-net-worth clients. Then 25%. Then 50%. Then 100%.
Why?
Because this is the first time the feature is being used by real clients at scale.
If something unexpected happens at 10% (a spike in errors, performance issues, incorrect routing), you can pause the rollout, fix the issue, and restart.
That’s far safer than rolling out the feature to one million clients all at once.
There’s something else important.
Your RM feature isn’t launching alone.
When clients download the latest version of the app, they’re not just getting your feature. They’re also getting performance improvements, security updates, bug fixes, and other features built by different teams.
All of these changes are released together as one app update.
Why fintech features go through such a rigorous release process
You might be wondering: why all these stages? Why not just build it and launch it?
Because fintech apps deal with real money.
Imagine what happens if a bug miscalculates a client’s account balance. A high-net-worth client logs in and sees $500,000 instead of $5,000,000. They panic. They call their relationship manager.
The relationship manager escalates to leadership.
Now you’re explaining to leadership why a client’s reported net worth dropped by millions overnight.
That’s why enterprise fintech companies build, test, and launch in stages.
You’ve seen how this works.
Lower environments where teams build independently. Higher environments where everything connects. Pilot testing where real users validate the feature. And phased rollout where you launch to 10% of high-net-worth clients, then 25%, then 50%, then 100%.
What started as “let’s build and launch” is now a four-stage release process that protects customers’ money, prevents compliance violations, and ensures the feature actually works before one million high-net-worth clients see it.
Next article: How To Estimate Delivery Timelines For Your Fintech Feature