A little over a year ago, we started building a financial comparison product in Vietnam around what looked like a simple problem:
People could find plenty of loan offers online, but comparing them was surprisingly difficult.
There were bank websites, finance company websites, apps, aggregators, ads, promotional landing pages and social media posts. The information was everywhere.
The problem was that it was rarely presented in the same way.
One lender might advertise a monthly interest rate. Another used an annual reducing-balance rate. Another focused on the monthly payment. Fees might appear somewhere else entirely. Eligibility requirements were often described differently from one provider to another.
We thought the solution was straightforward:
Collect the information, standardize it and build a clean comparison interface.
That idea eventually becameVaynhanh.ai.
After our first year, more than 9,500 users had used the platform, and our comparison coverage had expanded across more than 40 licensed financial institutions.
9,500 users is not a huge number by consumer internet standards.
But it was enough to expose many of the assumptions we got wrong.
Here are seven things we learned.
1. More listings do not automatically make a better comparison product
Our first instinct was predictable.
If we wanted to build a useful loan comparison platform, we needed more products.
So the obvious metric seemed to be:
"How many lenders can we add?"
It did not take long to realize that this was the wrong optimization target.
Imagine a comparison page with 100 loan products where every lender describes interest, fees, eligibility and repayment terms differently.
You technically have a lot of data.
But you do not necessarily have a comparison.
The user still has to interpret every product manually.
We gradually changed the question from:
"How many products can we list?"
to:
"How many products can we make genuinely comparable?"
That changed how we thought about the entire product.
Coverage still matters.
But structured coverage matters more.
Ten products with clearly normalized information can sometimes be more useful than 100 products copied directly from lender marketing pages.
For anyone building an aggregator, directory or marketplace, this may sound obvious.
It was not obvious to us at the beginning.
2. The hardest technical problem was not the interface. It was normalization.
The user-facing product looks relatively simple.
A borrower selects what they need.
The platform shows relevant options.
They compare amounts, terms, rates and requirements.
Behind that interface is a much more annoying problem:
Financial institutions do not always describe equivalent things in equivalent ways.
Take interest rates.
You may encounter:
Monthly rates
Annual rates
Flat rates
Reducing-balance rates
Promotional rates
Rates that depend on customer profiles
Fees that affect the economic cost but are not part of the headline rate
Now try putting all of those into one comparison table without misleading the user.
That became one of our biggest product challenges.
If you oversimplify the data, the interface becomes clean but potentially misleading.
If you preserve every technical detail exactly as published, the interface becomes accurate but difficult for ordinary consumers to understand.
We had to find a middle ground.
Over time, we started thinking less like a search engine and more like a data normalization company.
This work eventually influenced the methodology behind ourVaynhanh Fast Loan Market Report 2026, where we proposed a standardized framework for comparing credit products using consistent fields rather than treating every lender's presentation as directly comparable.
The broader lesson was useful beyond fintech:
If your product aggregates information from many providers, the real moat may not be collecting the data.
It may be deciding what the data actually means.
3. Users think in problems, not financial product categories
We initially thought users would behave like people working inside the financial industry.
They do not.
A lender might think in terms of:
"unsecured personal loan"
"revolving credit"
"installment financing"
"credit card"
"overdraft"
A user is more likely to think:
"I need VND 20 million."
"I need to pay a medical bill."
"I run a small shop and my cash flow is short this month."
"My credit history is not perfect."
"I need money before payday."
Those are completely different ways of describing the same market.
This affected how we designed search and comparison.
We originally placed more emphasis on product categories.
Over time, we started placing more emphasis on user intent.
The better flow became something closer to:
Need -> constraints -> suitable category -> shortlist -> detailed comparison.
Not:
Financial category -> giant list of products.
This seems like a small UX decision.
It changes a lot.
Once you organize a product around the user's problem rather than your industry's taxonomy, navigation, filtering, content and even SEO start looking different.
4. Trust turned out to be a product feature
We assumed users would primarily care about three things:
Rate.
Loan amount.
Approval speed.
They do care about those things.
But we underestimated another question:
"Is this lender legitimate?"
Vietnam has a large and rapidly digitizing consumer credit market, but it also has unlicensed lending apps and online offers that can look surprisingly similar to legitimate financial products.
That means verification cannot simply be buried in a disclaimer.
We began treating lender identity and licensing information as part of the comparison experience itself.
This changed our internal standard.
Before asking whether a product should rank highly, we first ask whether the institution belongs in the comparison set at all.
Our current approach is to focus comparison coverage on licensed financial institutions rather than attempting to maximize the number of offers available.
There is a tradeoff.
Excluding questionable providers means fewer listings.
But that is one tradeoff we are comfortable making.
The interesting product lesson was that trust is not something you add after the product is finished.
In financial services, trust is part of the product architecture.
I suspect the same applies to marketplaces involving healthcare, insurance, legal services or anything else where users cannot easily verify providers themselves.
5. We use AI, but we learned to give it boundaries
Building something called Vaynhanh.ai creates an obvious question:
How much of the platform is actually powered by AI?
The answer has evolved.
AI can be extremely useful for tasks such as:
Drafting
Categorization
Extracting structured information
Identifying inconsistencies
Summarizing long documents
Supporting research workflows
Helping the editorial team process large amounts of material
But financial information creates a different standard of risk.
If an AI-generated sentence in a general blog post is slightly awkward, that is an editorial problem.
If an AI independently changes an interest rate from 18% to 8%, that is a financial information problem.
So we introduced a fairly simple internal rule:
AI can assist with the work.
AI does not independently publish financial rates.
Material financial data still needs a verifiable source and human review before publication.
This probably makes our workflow slower than a fully automated pipeline.
We are fine with that.
One of the things I have become more skeptical about while building with AI is the idea that automation percentage is automatically a measure of product quality.
Sometimes the better question is:
"Where should automation stop?"
For us, financial pricing data is one of those boundaries.
6. Monetizing a comparison platform creates an uncomfortable incentive problem
This was probably the most important business-model question we had to deal with.
Comparison businesses need revenue.
A common model is referral revenue from financial institutions when a user continues to an application or completes another qualifying action.
That sounds straightforward until you realize what it means.
The companies paying the platform are also the companies being compared on the platform.
That creates an obvious conflict:
What happens when the lender paying more money wants better visibility?
If commercial relationships can directly determine ranking position, the comparison gradually stops being a comparison.
It becomes advertising presented as comparison.
We decided early that commercial compensation should not be allowed to purchase ranking positions.
That decision creates operational friction.
The easiest way to maximize short-term revenue would probably be to give more exposure to whichever commercial relationship pays best.
The better long-term product decision is to separate commercial relationships from comparison methodology.
Whether that ultimately proves to be the optimal business decision will take longer to know.
But I increasingly think marketplaces have to decide what they will not sell.
For us, ranking position is one of those things.
This is an area where I would especially like to hear how other Indie Hackers handle the problem.
If suppliers fund your marketplace, how do you prevent supplier economics from gradually controlling discovery?
7. Our first 9,500 users made the roadmap narrower, not broader
Before launch, our roadmap was large.
Very large.
Loans.
Credit cards.
Calculators.
AI recommendations.
Financial education.
Personalization.
Automated matching.
More categories.
More integrations.
More everything.
After watching real users, the roadmap became simpler.
The main job is not:
"Help people access as many financial products as possible."
It is:
"Help people understand the differences between financial products before making a decision."
That distinction now influences most of our priorities.
It means better structured data matters.
Verification matters.
Source dates matter.
Clear explanations matter.
Repayment calculations matter.
Identifying the actual lender matters.
Showing 20 extra products often matters less.
I think this has been our biggest lesson from the first year.
Early-stage founders are constantly encouraged to expand.
More features.
More markets.
More channels.
More monetization.
Sometimes usage teaches you the opposite.
Your product may become better when you understand the small number of things users actually need from you and become unusually good at those things.
What We Would Do Differently If We Started Again
If we were starting Vaynhanh.ai again tomorrow, I would change the order of operations.
Instead of:
Get lenders -> collect products -> build interface -> add comparison logic
I would probably start with:
Define comparison standard -> define verification rules -> build data model -> collect products -> build interface
It sounds less exciting.
There is no impressive AI demo in that sequence.
But the boring infrastructure turned out to determine whether the visible product was actually useful.
I would also spend more time talking to users before deciding how financial products should be categorized.
Industry terminology is useful internally.
User intent is usually more useful externally.
And I would define our AI boundaries earlier instead of figuring them out as the product grew.
Where We Are Now
We are still early.
9,500 users is enough to learn from, but nowhere near enough to claim we have figured out consumer finance.
Vietnam's lending market is also changing quickly, so some of the assumptions that work today will probably need to be revisited.
But one idea has become much clearer to us:
A loan comparison platform is not primarily a search product.
It is a trust and data-standardization product with a search interface on top.
That is not the company description we would have written when we started.
It is probably a much more accurate description of what we are actually building today.
For other founders building marketplaces, aggregators or comparison products, I am curious about two things:
What turned out to be the hidden hard problem in your product after real users arrived?
If the companies funding your marketplace are also the companies being ranked or recommended, how do you manage that conflict?
Would love to compare notes.
