All case studiesFinTech · Embedded product team

FinTech rewards platform: seven-person embedded team → a feature every two-week sprint

Consumer FinTech loyalty and rewards platform (name withheld)

Industry
FinTech
Service
Product team · Fractional Chief Technology Officer
Team
3 growing to 7 specialists
Stack
Flutter · Kotlin · Java · Next.js · React · Tailwind CSS
Timeline
Engagement from May 2025 · about 18 months
Abstract view of a rewards app, anonymised
3 → 7specialists in the embedded team
2 weeksbetween new features, down from 4 to 12 months
2–3xuser retention from a base of about 6%
~6 monthsinside the client’s transaction team

About the client

The client is a private company running a consumer FinTech platform in loyalty and rewards. Hundreds of thousands of users shop through hundreds of partners, and the business earns a commission on relevant transactions from users and banks.

Its name is withheld at the client’s request.

The challenge

Business challenge

Retention was around 6%, with an average session of about 40 seconds, and there was little visibility into user behavior, drop-off points or product value. Features were slow to reach users: relevant requests were reported to take between four and twelve months.

Technical challenge

Internal specialists and external engineers worked across several communication and decision patterns. Technical discussions did not always turn into a defined implementation step, and the company wanted to add engineering capacity without relying only on local hiring.

Delivery challenge

Requests arrived by email, ownership of next steps was unclear, and the architecture work was not connected to delivery. The company needed a shared process and a partner who could take on more responsibility as trust grew.

How the work started

Three people joined: two engineers and a technical lead. Instead of opening with a formal audit based on interviews, they joined the daily workflow, worked on real tasks, sat in meetings and watched how requests, decisions and dependencies moved through the company.

Two principles shaped the engagement. Observe first, so the process fits the people and culture already in place. And support first: every change was introduced as a way to make work easier, never as criticism of how things were done.

What CodeLions built

For the delivery challenge: a process the whole team uses

The first improvement, in the first month, was moving development requests from email into a dedicated Slack channel with a simple request template. It created a shared history and spread into the wider team’s daily work.

By the end of month two a baseline delivery process was proposed. Architecture and delivery discussions were tied to an action, an owner and a next checkpoint, so conversations turned into implementation. A new feature shipped within the first months, which tested the process against real delivery.

For the technical challenge: advisory from day one

The technical lead advised on architecture, cloud, process and product decisions from the beginning, not as a final phase. The team grew from three to seven specialists, including a DevOps engineer who joined around month six.

Between months six and twelve the team added advanced tracking for users, drop-off points, retention and product value, fixed application performance issues including a low frame rate, improved release stability and supported a redesign. It also supported the company’s AI initiatives, recommending AI only where it created enough value and using scripts, webhooks or standard code where those were simpler and more reliable.

Illustration of a retention and drop-off analytics dashboardIllustration of a release pipeline and stability view
Product analytics and release stability (illustration)

For the business challenge: retention-focused features

With analytics in place, the team shipped retention-focused features. User retention improved 2 to 3 times from the starting point of about 6%.

Deeper ownership of the transaction domain

After about a year, the technical lead moved into the client’s internal transaction team for roughly six months. The work covered payment processing, bonus calculations, settlements with banks and with commercial partners, and a review of internal transaction processes, with automation to cut manual work and operational errors.

This was internal financial and operational workflow, not the user-facing payment experience. The team also contributed product expertise, took part in shareholder meetings and helped decide what to build, not only how.

Outcomes

BeforeAfter
Feature deliverySome features reportedly took four to twelve monthsRelevant features in about two months, and a new feature every two-week sprint
CommunicationRequests exchanged by emailOne Slack channel with a request template and clear rules for who to ask and how to raise issues
Decision-makingDiscussions did not always become an implementation stepEvery important discussion has an action, an owner and a next checkpoint
Product analyticsNot part of the operating modelTracking for users, drop-off points, retention and product value
RetentionAbout 6%, with sessions of about 40 seconds2 to 3 times higher after the retention-focused features
TeamTwo engineers and a technical leadSeven specialists: engineering, DevOps, advisory and partial ownership of transactions
Transaction operationsManual workflows for payments, bonuses and settlementsModernization and automation started across payments, bonuses, bank and partner settlements

What is next

The next step is a stronger product operating model: annual and quarterly planning, priorities tied to business metrics, effort estimates, more detailed requirements, focused validation of selected features and A/B testing. Work on transaction automation continues, and further AI initiatives will each be weighed against simpler automation.

Other case studies

Is delivery slower than the product needs it to be?

PDF or Word, up to 20 MB