How Webskyne Helped Meridian Finance Cut Onboarding Friction by 62% with a Flutter-Next.js Rearchitecture

Overview

Client: Meridian Finance, a digital wealth-management startup targeting first-time investors in Southeast Asia.
Role: Webskyne led full-stack rearchitecture and UX redesign.
Timeline: 12 weeks (design, build, QA, and launch).
Stack: Flutter (iOS/Android), Next.js 14 (customer & operations dashboards), NestJS microservices (orchestration, KYC, notifications).
Outcome: Onboarding completion rose from 58% to 94%; time-to-first-deposit dropped from 11 minutes to under 4 minutes; customer satisfaction up 21 points.

Meridian Finance entered 2025 with a clear growth mandate: acquire 150,000 funded accounts in twelve months. Instead, after six months they had 42,000 funded accounts and a churn problem. Exit interviews and app-store reviews told the same story: the onboarding process felt like a bank in 1998—long, paper-heavy, and impersonal. The engineering team knew the codebase was holding the product back, but with investor pressure mounting, a slow incremental rebuild was not an option. They brought in Webskyne to rebuild the onboarding and customer-facing layers without disrupting live banking integrations.

The Challenge

The problems were both visible and structural. On the surface, first-time users were asked to complete 17 screens spanning identity verification, address proof, tax residency, employment details, and investment profile. There was no progress indication, no save-state, and no way to pause and resume without starting over. Users who abandoned on screen 9 of 17 left behind incomplete data; retargeting campaigns that referenced partial submissions felt invasive rather than helpful.

Beneath the UX problems, the technical architecture was worse. The legacy app was a hybrid WebView wrapped in Cordova, sharing a session with an authorization server that issued JWTs valid for 24 hours with no refresh token rotation. The backend was a monolith in which KYC verification, account provisioning, notification dispatch, and analytics ingestion all shared a single Postgres database. Any one of those workflows could hold a row lock long enough to cascade into timeouts and failed onboarding attempts.

The operations dashboard that customer success agents used was a single-page React app built on an outdated data layer that queried the production database directly. Agents could not filter by onboarding stage, see why users dropped off, or trigger a verification retry without engineering. Product managers had no real-time view of funnel metrics; all decisions were based on weekly CSV exports from a data warehouse with a 48-hour lag.

Finally, compliance added hard constraints. The Monetary Authority of Singapore required immutable audit trails for every identity check, and the financial services regulations in Indonesia and the Philippines mandated that certain PII fields never leave the region. The existing architecture stored all user data in a single US-East database cluster, making regional compliance both technically and legally fragile.

Goals

We agreed on six concrete objectives at kickoff:

• Reduce onboarding friction: Cut the number of mandatory steps by more than half without lowering compliance coverage.
• Raise completion rate: Move from 58% to 90%+ completion within 30 days of launch.
• Shrink time-to-first-deposit: Bring median time under 5 minutes.
• Separate compliance from commerce: Ensure KYC data can be audited and isolated from transactional data.
• Empower operations: Give customer success agents real-time funnel visibility and self-service intervention capabilities.
• Future-proof the stack: Migrate from WebView to a native-grade mobile experience and replace the monolith with independently deployable services.

These goals were not guesses. Early analysis of user session recordings, heatmaps, and support tickets made the drop-off points concrete: screens 3, 7, and 12 were responsible for 71% of abandonment. Each of those screens asked users to enter sensitive information while providing no reassurance about security or progress. That insight shaped the product discipline that drove everything that followed: every new screen had to justify its existence with both a compliance requirement and a measurable UX outcome.

Our Approach

Webskyne embedded a cross-functional squad inside Meridian’s existing teams: two Flutter engineers, one Next.js specialist, one NestJS backend engineer, a product designer, and a dedicated QA engineer. We ran two-week sprints with a hard rule—every sprint had to deliver something shippable that could be demoed to a compliance stakeholder. That discipline kept legal and risk teams in the loop and prevented late-stage surprises.

We began with a funnel audit: replaying 200 completed and 200 abandoned sessions, tagging failure points, and mapping the dependency graph between backend microservices. The audit revealed that the KYC provider had a 12-second median latency and a 4% failure rate; the monolith lacked circuit breakers; and the analytics pipeline inserted events synchronously into the same database that handled onboarding mutations. We categorized findings by risk and impact, then ranked fixes by the ratio of friction reduction to implementation effort.

Next came information architecture and progressive disclosure. Rather than asking for all data up front, we introduced a tiered onboarding flow: identity and country selection in step one, document capture and selfie biometrics in step two, tax and employment details in step three, and investment preference in step four. Step five drove the user directly into a guided first-deposit flow. We designed each step with a single primary action, clear copy explaining why the data was needed, and a visible progress bar. The investment questionnaire, previously 14 Likert-scale questions, became an adaptive quiz that skipped irrelevant branches and shortened the path for conservative investors.

On the technical architecture side, we made three structural decisions early:

1. Flutter for unified mobile code. Replacing the Cordova WebView with Flutter gave us a single compiled codebase for iOS and Android, native-platform biometric APIs for Face ID and fingerprint verification, and a rendering pipeline that made animations smooth even on mid-range devices common in Indonesia and the Philippines.
2. Next.js 14 App Router for customer and operations surfaces. We chose server components to reduce client-side JavaScript and improve first-paint performance, while enabling streaming UI for dashboard widgets that needed real-time data. For the operations portal, we used React Server Components with role-based access control enforced at the route level.
3. NestJS microservices with CQRS. We split the monolith into three bounded contexts: Identity (KYC, document storage, audit), Accounts (provisioning, balances, deposits), and Engagement (notifications, nudges, preferences). Each service owned its database schema, communicated via async events, and exposed a versioned REST API consumed by the Flutter app and Next.js dashboards.

A fourth decision was equally important: we moved data residency in front of the feature. From day one, the new architecture partitioned PII by region. Indonesian and Philippines users’ KYC documents and biometric hashes were stored in a dedicated Singapore cluster, with metadata-only records kept in the US for settlement logic. This did not add measurable latency—the Flutter app prefetches configuration from a CDN and caches non-PII assets locally—but it removed compliance objections and allowed us to launch in Indonesia six weeks ahead of schedule.

Implementation

The development phase unfolded in four sprints. Sprint one delivered the identity and KYC flow. We integrated Onfido for document verification and custom biometric liveness detection using Flutter’s platform channels to call native iOS and Android APIs. The biometric check ran entirely on-device; only the liveness score and a reference image hash left the phone, encrypted with a one-time key.

Sprint two built the Next.js operations dashboard. Customer success agents could filter users by onboarding stage, view a timeline of every verification event, and resend document-upload prompts from a single click. We added role-based access control with CASL, so supervisors could export reports while junior agents could only view assigned users.

Sprint three introduced the adaptive investment questionnaire and connected it to an account-personalization engine written in NestJS. The engine uses a lightweight decision tree that branches based on user responses to three seed questions: investment horizon, risk tolerance, and available capital. Based on those answers, it pre-selects a portfolio template and prefills the first-deposit amount. This reduced time-to-first-deposit by more than a minute on average, because users no longer had to construct a portfolio from scratch before funding.

Sprint four was optimization and launch preparation. We added full-session crash reporting with Sentry, set up Datadog APM for the NestJS services, and configured p95 latency alerts. On the data side, we stood up a ClickHouse analytics cluster with a real-time ingestion pipeline; the operations dashboard could show funnel metrics with less than two minutes of latency. Before launch, we ran a 48-hour load test simulating 20,000 concurrent users. The bottleneck was a third-party rate limiter on the KYC provider; we added a token-bucket queue and a user-facing estimated-wait display, eliminating 503s during simulated peaks.

Design and QA were continuous, not handoff phases. The product designer paired with QA on every sprint review, catching copy errors and accessibility issues before they reached the staging environment. We tested on a device lab covering 12 Android models and 6 iOS devices spanning API levels 26 through 35. The Flutter app maintained a 60fps scroll performance on even the lowest-spec test device.

Results

The redesigned onboarding went live on a Tuesday morning. We rolled it out to 10% of traffic for 72 hours, watching funnel metrics and support ticket volume in real time. When completion rates held above 92% and no P0 incidents appeared, we increased to 100% of traffic by Friday.

Within the first 30 days:

• Onboarding completion rose from 58% to 94%, exceeding our original 90% target by four points and matching the best-in-class benchmark for wealth-management apps in Southeast Asia.
• Median time-to-first-deposit fell from 11 minutes to 3 minutes 42 seconds. Users who previously abandoned during document upload now completed the flow and deposited in a single session.
• Abandonment on step 3 (the previous highest-drop-off point) dropped from 41% to 6%, driven by clear copy, a seamless camera UI, and a progress indicator that showed exactly how many steps remained.
• Customer satisfaction, measured by post-onboarding NPS, increased 21 points, from 38 to 59. Qualitative feedback specifically called out the speed and clarity of the new experience.
• Operations efficiency improved dramatically: average agent handle time for onboarding issues fell from 14 minutes to 4 minutes, because agents could diagnose problems and trigger verification retries without engineering support.

The business impact followed quickly. Funded account growth in Month 13 jumped to 188,000—more than doubling the annual target and pushing Meridian’s Series C valuation up 35%.

Key Metrics

Metric	Before	After	Change
Onboarding completion rate	58%	94%	+36 pts
Time-to-first-deposit (median)	11 min	3 min 42 sec	-66%
Step-3 abandonment	41%	6%	-35 pts
Post-onboarding NPS	38	59	+21 pts
Agent handle time	14 min	4 min	-71%
Funded accounts (Year 13)	~82k	188k	+129%

Lessons Learned

The Meridian engagement taught us four lessons that now shape every Webskyne project.

1. Friction is a metric, not an opinion. Early in the project we measured every screen with a single question: does this screen serve compliance, and does it hurt completion? If the answer to the second part was yes and the answer to the first was no, the screen had to be redesigned or removed. That razor cut 12 screens without touching the underlying checklist. Instruments like heatmaps and session replay were not optional polish; they were the inspection mechanism that kept us honest about whether our design choices actually worked.

2. Architecture is UX. We have often seen teams treat backend latency and frontend design as separate concerns. At Meridian, the 12-second KYC latency was experienced by users as an unexplained spinner, which increased abandonment precisely at the most compliance-critical step. By adding a token-bucket queue, a visible wait estimate, and optimistic UI updates, we turned a backend problem into a UX feature. The lesson: every millisecond the server delays is a design problem, not just a performance one.

3. Compliance and speed are not opposites. The team assumed that shrinking onboarding would require weakening KYC. Wrong. A progressive disclosure model actually improved compliance: agents could see exactly which documents failed and why, and users who received a targeted resend completed verification in 82% of cases, compared with 34% when the retry was vague. Clear, tiered flows make compliance more enforceable, not less.

4. Ship in slices, not layers. Had we built the perfect mobile app first and worried about the dashboard and infrastructure later, we would have shipped a beautiful product that compliance could not use. Instead, every sprint produced a vertical slice spanning mobile, backend, and operations. Shippable slices forced us to make real trade-offs under real time pressure, which led to higher quality decisions than an ivory-tower architecture document ever would.

Conclusion

Most clients come to Webskyne because they want a new app or a faster website. The Meridian engagement reminded us that what they really need is a shorter distance between user intent and user success. That distance is rarely a single line of code; it is the sum of design clarity, technical reliability, and operational empathy.

Over twelve weeks, Webskyne helped Meridian Finance rebuild that distance. The result was not only a 36% jump in onboarding completion but also a faster, safer, and more humane way for first-time investors to start their financial journey in Southeast Asia. The new Flutter-Next.js-NestJS stack is now Meridian’s standard platform, used by 1.2 million users across four countries, and we continue to iterate with them on features that make wealth management accessible to people who had never considered it before.