To win the Most Valuable Team (MVT) Award at Money Forward Vietnam, it takes more than just coding skills. It takes a "Product Mindset," a dash of AI innovation, and an obsession with User Focus.
We sat down and invited some members, naming Theta, Coffee, Hugon, San, William, and Min, to share exactly how they delivered a complex Lease Accounting product in record time.
Here is their story, in their own words.
As the captains of this award-winning team, how did you manage such a cross-functional group (from Backend to Accelerator) to stay focused on one goal: release in just 8 months?
Theta (Engineering Manager): We focus on the most important aspect of the Lease Accounting market and help everyone follow it smoothly. With that, every action of our plan will go to the final destination and avoid any distractions.
Coffee (Engineering Lead): Leaders need to break down a big goal into small, achievable steps and milestones, ensuring that all members understand them. Leaders also need to take care of and encourage all members, monitor the process and communication between members to remove the distraction from outside, remove any blockers, resolve conflicts to align with the plan.
You led the team to successfully embed AI into the very core of your SDLC. In your opinion, what is the most critical mindset shift a Lead must encourage to move a team from “simply using AI tools” to “building an AI-driven engineering standard”?
Theta: "We start from an open mind for changes, same as we did with the new lease accounting standard. Then we go to the values that AI adoption could boost or accelerate our speed, productivity, and quality."
Coffee: “It's professional and evolution. AI-driven engineering is now the trend of this era, so at least we need to catch up with what's going on, set a vision, a goal, and pursue it. When we do something, we do it professionally, try to resolve as many issues as possible, generalize the practice, and share knowledge. In that way, we can move forward and help others to move forward as well.”
The team achieved SOC compliance and zero critical defects while beating competitors. From a Backend perspective, how did you balance the “need for speed” with the “need for extreme security”?
We integrated automated security tools into our workflow to find issues early. Additionally, our developers continually enhance their coding skills and security knowledge. We want to write “clean” code that is safe from the start to minimize security bugs. This proactive mindset helped us stay fast without losing safety.
The project significantly reduced infrastructure spend. How does a Backend engineer at MFV think of “cost-efficiency” when designing a high-scale system architecture?
Cost-efficiency is about using resources wisely. When designing, I focus on sizing and analyzing criteria like user count, data size, and specific user needs. This helps us build an “Auto-scaling” system that fits perfectly. It grows when needed and shrinks when not, ensuring we don't waste money on unused resources.
The team won because of “strong market differentiation”. How did the Frontend team use end-to-end UI/UX to turn a complex Lease Accounting tool into a simple and superior one to competitors?
To be honest, making a complex system like Lease Accounting feel “simple” is a massive challenge; the real magic happened because we never treated UI/UX as “someone else’s job”. Every member, from engineers and QC to PMs, acted as a guardian of the user experience.
Here’s how the Frontend team really owned the game:
We weren't just coders during refinement: When a new feature came onto the table, we didn't just look at the technical feasibility. We stepped into the shoes of a stressed accountant dealing with IFRS 16. During refinement, we’d often push back or ask, “If I’m a user, would this flow actually make sense to me?” This “engineer-as-user” mindset allowed us to catch friction points early, before they even reached the development stage.
Polishing as we built: Since the Frontend team is the first to actually “touch” and interact with the product, we took that responsibility seriously. If a transition felt clunky or a data table looked too overwhelming for the Japanese market’s standards, we didn't just follow the Figma file blindly. We proactively suggested tweaks to make the interface more “breathable” and intuitive.
The “Continuous Feedback” culture: We didn't wait until the end to see if it worked. We maintained a tight loop with stakeholders and PDM, iterating constantly. We also invested time in leveling up our own UI/UX knowledge, which meant we could spot inconsistencies much faster.
At the end of the day, our differentiation didn't come from a single “eureka” moment, but from the fact that we were obsessed with the user's journey. We transformed a dense, compliance-heavy tool into something that actually feels helpful and straightforward to use.
How did you use AI or standardization to accelerate the Frontend development process to hit that 8-month production deadline?
For a system as complex as IFRS 16, Lease Accounting would have been nearly impossible without a radical shift in how we approach the SDLC. From day one, we didn't just “use” AI; we integrated it into our DNA, moving our workflow at 2x or 3x speed:
From Coding to Orchestrating: By leveraging advanced tools like Cursor, GitHub Copilot, and Claude Code, we automated the tedious parts, generating Pull Requests, writing documentation, and initial requirement analysis. As AI evolved toward AI Agents and SubAgents, our roles shifted from “coders” to Architects and Orchestrators. An engineer could now handle multiple tasks in parallel by coordinating AI Agents to generate the bulk of the code, while we focused on high-level logic and edge cases.
The “Quality Gate” Philosophy: We realized early on that “fast” is dangerous if it’s “messy”. To prevent AI-generated technical debt, we built a rigorous automated quality gate. This included strict linting, formatting, and SonarQube integration. But the real game-changer was our testing strategy. We maintained over 90% code coverage through unit and integration tests. We also used Storybook extensively for visual testing, ensuring the UI stayed consistent and “true to life” for the end-user, no matter how fast we were moving.
The Human-in-the-Loop Principle: Despite the power of AI, we held one rule sacred: 100% human review. We used AI to help us review code faster, but the final sign-off always came from a person who understood the specific business context of the Japanese market.
By combining the raw speed of AI Agents with a rock-solid standardization of our testing and review culture, we didn't just hit the deadline—we delivered a product that is both incredibly stable and built to scale."
Zero critical defects at release. What was the testing strategy that ensured such high quality at such a high speed?
First, we have many technical discussions regarding architecture decisions and implementation solutions to make sure every task will be implemented in the best way.
Second, we have a research phase for domain knowledge, and by collaborating with experts in the business, we can identify and mitigate high-risk scenarios to cover in the early phase.
And finally, we are following the TDD (Test-driven development). Everything is testable, and has been tested in the development phase. That helped engineers to find and fix the bugs from the very beginning and save time for the later phases.
Did you feel the company provided enough “breathing room” and resources (mentorship or AI tools) for you to upskill while you were sprinting toward the deadline?
Yes, thanks to the provided AI tools such as Claude, Cursor, Gemini... we have reduced much development time in all phases.
We are working in the new project in a new business area. There is a lot of new knowledge for us. AI helps us to gather information, analyze, and make helpful decisions, making our work easier."
In an 8-month “battle”, bottlenecks can kill a project. As an Accelerator, how did you ensure Product requirements transform to Engineering reality without speed reduction?
In our 8-month “battle”, ensuring that over 130 User Stories were delivered on time to the engineering team was a massive challenge, especially since we started from scratch with a complex domain and a fixed release schedule. To maintain momentum without sacrifice, I focused on three core strategies:
1/ AI-Powered Discovery: We are proud to be one of the first projects to integrate AI into the Discovery process. Instead of spending hours on manual drafting, we trained AI to automatically generate Epics and User Stories based on a set of continuously refined rules. This allowed the team to dedicate the majority of time to core business logic discussions, simply reviewing the AI-generated outputs. This shift saved us countless manual hours every week.
2/ Strategic Prioritization (Must-have vs. Nice-to-have): For a brand-new product, feature ambition is always high. I worked closely with the Discovery team to ruthlessly categorize requirements into “Must-have” and “Nice-to-have”. When time pressure intensified, we stayed firm in focusing our resources on the core value proposition, ensuring the product was in its best possible state for Go-live.
3/ Early Technical Sync: We didn't wait for 100% of the requirements to be finalized before hand-off. As soon as a high-level solution took shape, I shared it immediately with the Dev team to assess technical feasibility. Identifying concerns at such an early stage allowed us to pivot quickly and avoid the nightmare of 'tearing down and rebuilding' during the final sprint."
Can you describe a moment where the “One Team” spirit between MFV and MFJ Japan was most visible? How did this “borderless” culture help you hit the deadline?
The “One Team” spirit truly shone brightest during the preparation for our Version 1.0 release. We established a shared communication channel with the CS team in Japan, integrated with an AI translation bot to dissolve any language barriers.
The most impressive moment was when the CS team reported user bugs on the support site. Instead of waiting for a middleman to coordinate, our QA team in Vietnam proactively responded and collaborated directly with the Japanese team to resolve the issues. This proactivity proved that geographical distance and language differences disappear when everyone is driven by a single goal: customer satisfaction.
San: In the past, I perceived my role as someone who waited for a finalized requirement to start coding. However, from the very first kickoff of this project, that mindset was challenged. I was encouraged-even expected-to speak up, challenge ideas, and provide feedback directly to the Product and Design teams.
This project taught me that to be a true Product Engineer, you cannot be passive. You have to be obsessed with the ”Why” before the “How”:
Becoming a Domain Expert: I realized that to build a great tool for Japanese accountants, I couldn't just understand React or TypeScript. I had to understand IFRS 16, the nuances of Japanese leasing laws, and the specific pain points our users face daily. I spent time studying the market and our competitors to ensure every component I built actually solved a real-world problem.
Bridging the Gap: My definition of an engineer has shifted from someone who 'writes code' to someone who “solves problems through technology”. It’s about identifying a user's struggle and finding the most efficient technical path to eliminate it.
Ownership from Day Zero: At MFV, being a Product Engineer means having a seat at the table. We don't just implement features; we help shape them. This sense of ownership is what drove us to push for the MVT award.
Ultimately, this project proved to me that our value isn't measured by the number of tickets we close, but by the impact we create for the customer. I now see myself as a co-creator of the product, not just a builder of its interface."
William: This project has shifted my definition of a Product Engineer from being a “builder" to being a "strategic partner”. Previously, I thought my job was just to deliver clean, bug-free products. But seeing how our 'future-proof' architectural decisions actually played out when the business expanded, I realized that a true Product Engineer must have business empathy. It’s not just about solving the technical problems of today; it’s about anticipating the user's needs of tomorrow and using tools like AI to bridge that gap faster.
Q: Is there a specific MFV value (like “User Focus” or “Fairness”) that you saw your teammates living out every day during the tough times?
And those are the stories told by members of the Lease Accounting team - the Winner of 2H2025 Half-year All-Hands. May their stories inspire you on your journey to grow yourself and move forward, with us.
