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

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.


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
| Before | After | |
|---|---|---|
| Feature delivery | Some features reportedly took four to twelve months | Relevant features in about two months, and a new feature every two-week sprint |
| Communication | Requests exchanged by email | One Slack channel with a request template and clear rules for who to ask and how to raise issues |
| Decision-making | Discussions did not always become an implementation step | Every important discussion has an action, an owner and a next checkpoint |
| Product analytics | Not part of the operating model | Tracking for users, drop-off points, retention and product value |
| Retention | About 6%, with sessions of about 40 seconds | 2 to 3 times higher after the retention-focused features |
| Team | Two engineers and a technical lead | Seven specialists: engineering, DevOps, advisory and partial ownership of transactions |
| Transaction operations | Manual workflows for payments, bonuses and settlements | Modernization 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

AI guardrails in 10 weeks → 94% fewer unsafe automated decisions, zero critical audit findings
Read the story
Prod3: a law firm CRM for processes, documents and tasks
Read the story