TransferIQ

I’ve been thinking more about what IQ Labs actually is.

I didn’t start with a grand plan to build a startup studio.

I started with problems I personally understood.

TransferIQ came from cross-border payments — comparing remittance providers, FX, exchanges and stablecoin routes without really knowing what the recipient would finally receive.

Then came Jobtelligence, built from a completely different problem: job searching, resume matching and preparing better applications with AI.

Two different markets, but the way I build them is becoming consistent:

Find a problem I understand.

Break it down operationally.

Build the smallest useful product.

Ship it.

Watch where it fails.

Improve it.

That is slowly becoming the identity of IQ Labs.

Not a company built around one idea, but a small product studio focused on turning real operational problems into working software.

TransferIQ is currently moving deeper into research, community and cross-border payment intelligence.

Jobtelligence is focused on making the job application process more intelligent and less repetitive.

Both are still early.

The next challenge for IQ Labs isn’t building more products.

It’s proving that the products already built can attract users, create real value, and eventually sustain themselves.

That’s the part I’m focused on now.

I’ve just shipped a new update to TransferIQ.

The product originally focused on comparing traditional remittance providers, crypto exchanges and stablecoin-based transfer routes.

The problem was that international transfers are low-frequency. A useful comparison tool alone does not give users a strong reason to return regularly.

So I added two new layers:

Research

Long-form analysis on FX, remittance infrastructure, stablecoins, payment systems and crypto exchanges.

Community

A place for users to share real transfer experiences, hidden fees, route problems and practical questions.

The long-term direction is now clearer:

Research brings people in.

Community captures real user knowledge.

Compare helps them evaluate actual routes and recipient amounts.

I’ve also started publishing deeper company reports on Binance and Bybit, focusing on ownership, legal entities, regulation, custody and user risk—not just trading volume or product features.

The next goal is not adding more random features.

It is building a repeatable content-to-product loop:

Research → discussion → real route data → better comparisons.

TransferIQ is still early, but this update brings it closer to becoming a broader cross-border payment intelligence platform rather than just another fee calculator.

https://transferiq.org

I haven’t posted an update here for a while, but I haven’t stopped working on TransferIQ.

The opposite happened: I started doing too many things at the same time.

Recently, I have been:

• improving TransferIQ’s remittance and exchange comparison flow

• publishing FX and remittance content in multiple languages

• testing channels such as Medium, Blogger, LinkedIn, Telegram, SoloXin, and W2Solo

• tracking which content generates real traffic

• building and launching another product, Jobtelligence

Jobtelligence compares a resume with a specific job description and analyzes role fit, experience, skills, achievements, and missing keywords. It also includes AI-generated professional headshots for applications, LinkedIn, and portfolios.

The biggest lesson so far is that shipping the product is only the beginning.

I now spend more time asking:

• Who actually needs this?

• Can users understand the value quickly?

• Why do visitors not sign up?

• Why do signups not become paying users?

• Which channels generate useful traffic instead of empty views?

I used to think product development and marketing could be handled separately.

Now I believe they need to happen together.

Build, publish, observe, and adjust.

That is what I have been doing recently, even if I was not documenting it here.

TransferIQ

https://transferiq.org

Jobtelligence

https://jobtelligence.com

Recently, I spent some time studying Monito, probably the closest major benchmark for TransferIQ.

I knew it was a much larger platform, but I had never looked closely at just how large its operation had become.

Monito has content covering more than 300 financial providers, offers reviews and guides in 11 languages, and covers money transfers to more than 200 countries and regions. Its current app listing says users can compare more than 100 trusted money transfer providers and banks.

Then there is the content operation.

Monito does not stop at money transfer comparisons. It publishes provider reviews, country-specific transfer guides, eSIM comparisons, online banking content, and practical information for people living or traveling abroad.

Its audience is also much broader than someone simply searching for the cheapest transfer today. The site attracts migrants, expats, international students, remote workers, freelancers, and travelers through hundreds of different search intentions.

The scale was honestly overwhelming.

TransferIQ currently covers 19 providers. Monito has spent years building a much larger database, far broader country coverage, and an enormous SEO footprint.

Looking at that difference as a solo builder can be discouraging. It is easy to think:

“How am I supposed to compete with this?”

But after the initial shock, I started looking at it differently.

Having a strong company in the same market gives me a real benchmark. I do not have to guess what this category could eventually become. I can study what already works:

• How they structure country and transfer-corridor pages

• How they turn provider data into searchable content

• How they expand from one financial problem into adjacent expat needs

• How they build trust around comparison results

• How they serve users at different stages of living and working abroad

It also helped me see where TransferIQ should not simply copy Monito.

Monito goes extremely deep into traditional remittance comparison. TransferIQ is trying to compare a wider set of possible routes: traditional remittance companies, banks, and crypto-based routes, including stablecoins, exchanges, P2P, and conversion services.

That broader route comparison is still much smaller and less mature. But it gives the product a different direction.

The lesson for me was simple:

A much larger competitor does not only show you how far behind you are. It also shows you how large the opportunity may be—and gives you clues about what to build next.

I cannot reproduce a decade-sized content operation overnight. What I can do is identify one missing comparison, one useful corridor, and one underserved user problem at a time.

Instead of asking, “How can I become as large as Monito?”, I am now asking:

“What can TransferIQ explain or compare that even a platform this large does not show clearly?”

That feels like a much better question for a solo builder.

Have you ever studied a competitor and felt completely overwhelmed by their scale? Did it discourage you, or did it help you find a clearer direction?

I’m building TransferIQ, a tool that compares cross-border remittance fees, exchange rates, and estimated recipient amounts.

When I started, the product seemed straightforward:

1. Collect quotes from multiple providers.

2. Normalize them by country and transfer amount.

3. Rank the cheapest options.

4. Show the results in a clean interface.

I assumed the main challenges would be APIs, data processing, and UI.

I was wrong.

The hardest part is deciding when the data is reliable enough to influence someone’s financial decision.

A remittance price is rarely a single number. The advertised fee may be zero, while the provider earns money through the exchange-rate spread. The result can also change depending on the amount, payment method, payout method, destination, and time of the quote.

A provider that is cheapest for $200 today may not be cheapest for $1,000 tomorrow.

That creates an uncomfortable tradeoff for a solo founder.

I can add more providers and make the product look more complete. But every new provider adds another set of rates, conditions, and edge cases that must be monitored.

A comparison covering 100 providers sounds impressive. But if some of the information is outdated or calculated under different assumptions, the ranking may be misleading.

A product covering 20 providers with consistently verified data may be more useful—but users could leave because their preferred provider is missing.

Lately, I’ve been asking myself these questions before adding new features:

• Can users see when the data was last updated?

• Can they understand why the ranking changed?

• Is the difference between an estimate and a confirmed quote clear?

• Does the product explain that a low fee may hide a poor exchange rate?

• Should uncertain data be displayed with a warning or hidden entirely?

In most software, a small data error is an inconvenience. In a financial comparison product, it can cause someone to move real money based on the wrong result.

That changes how I think about shipping quickly. Speed still matters, but trust debt may be more expensive than technical debt.

At the moment, I’m leaning toward narrower coverage with better verification, then expanding gradually. But I’m not sure that is the best early-stage strategy because limited coverage can make the product feel unfinished.

If you were building a data-driven product, which would you choose?

Broad coverage with results that are useful as estimates, or limited coverage with data you can verify more consistently?

I’d especially like to hear from anyone who has built a comparison engine, marketplace, financial product, or data aggregation tool.

A few days ago, I received an unexpected email from someone on the LINE NEXT Payment Biz team.

They had reviewed TransferIQ and invited me to apply for early access to Unifi Pay Direct.

For context, TransferIQ is a product I built independently to compare cross-border remittance, FX, and cryptocurrency routes. It shows users the estimated amount they may receive after considering exchange rates, fees, and spreads.

But TransferIQ does not currently process payments.

Its payment volume is zero, the user base is still small, and I am building it without a traditional programming background. So receiving this invitation was surprising.

To be completely clear, this is not a partnership announcement. I was invited to submit an early-access application, and there is no guarantee that TransferIQ will be accepted or integrated.

Still, it felt meaningful for one reason: I didn’t pitch them first.

Someone working on payment infrastructure saw the product and thought it might have a relevant future use case. For a small independent product, that is a more useful signal than another like or generic promotional email.

In the application, I explained that TransferIQ is evaluating Unifi Pay Direct for possible future premium features, cross-border payments, and settlement functions.

Before considering any integration, I need to understand:

• Which countries and currencies are supported

• Whether an API or SDK will be available

• Who is responsible for KYC and AML

• How settlement works

• Whether users in Brazil, Korea, Japan, and other international markets can be supported

• Whether the infrastructure fits TransferIQ’s actual product direction

Being technically able to add payments does not automatically make payments useful. Country coverage, compliance responsibilities, settlement options, and user demand matter much more than simply connecting an API.

I have now submitted the early-access application and sent a formal reply thanking the team for the invitation.

For now, I will continue improving TransferIQ’s core comparison features. I don’t want to redesign the entire product around one early conversation.

The project is still early, and this may lead nowhere. But after weeks of dealing with Android crashes, failed API calls, low traffic, and $0.06 in ad revenue, it was encouraging to see that the problem I am working on could be relevant to someone outside the project.

Early validation does not always arrive as revenue or rapid user growth.

Sometimes it is simply the first serious person from the industry saying, “This might be worth exploring.”

Has anyone here received an infrastructure or partnership inquiry while their product was still this early? How did you decide whether to integrate it or stay focused on the original roadmap?

Spot / Conversion / P2P / Card

The biggest update was the Spot market system. TransferIQ now checks which exchanges actually support each trading pair and separates pair availability from live pricing.

This means:

• Exchanges remain visible even when a price API temporarily fails

• Official exchange APIs are used where available

• Verified pair, fee, and spread data fill the gaps where APIs are limited

• Korean, Japanese, Brazilian, and global exchanges are compared

• Each result connects to the relevant trading market

• Referral links are preserved separately

• The product remains synchronized across six languages

I also completed Google Play internal testing over the weekend and uploaded the updated Android build.

The product is gradually evolving from a basic transfer calculator into a route-discovery platform that helps users answer three practical questions:

Where can I make this conversion?
How much will it cost?
How much will I actually receive?

My remittance comparison app is built with React Native and Expo. I built it alone, with no professional coding background, and recently released it on Google Play.

I opened the production version expecting to celebrate.

Instead:

Tap icon → splash screen → app closes.

Every single time.

Naturally, I assumed the worst part of my codebase was responsible. My App.js is around 9,000 lines. Yes, I know. I am a non-developer who kept adding features until one file became the entire company.

So I started investigating.

First, I suspected the AdMob banner initialization. I moved the initialization into a useEffect, wrapped it in .catch(), and tried to make the JavaScript side as defensive as possible.

The app still crashed.

Then I found CRYPTO_CODES being referenced around 546 lines before its declaration. For a moment, I thought I had found a classic JavaScript temporal dead zone error:

ReferenceError: Cannot access 'CRYPTO_CODES' before initialization

But the reference was inside a function. The function only ran after the constant had already been initialized.

False alarm.

At that point, I went far beyond what I expected to do as a non-coder.

I created a Node test harness to simulate my module loading in production mode with:

__DEV__ = false

I stubbed React Native, Expo, Supabase, native modules, and even every image loaded with require().

I wanted to answer one question:

Does the top level of my App.js actually crash when the production bundle loads?

It did not.

The module loaded successfully.

The first render also completed successfully.

My ugly 9,000-line JavaScript file was, at least mechanically, innocent.

The real clue came from the Android crash log:

Invalid application ID MobileAdsInitProvider.attachInfo

The failure was happening inside the Google Mobile Ads native initialization process.

That meant the app was crashing before my JavaScript had a chance to run.

The problem was not my React component, my proxy code, my exchange APIs, or the giant collection of arrays and functions inside App.js.

It was the native AdMob configuration generated from app.json.

The production build did not have a valid AdMob application ID correctly reflected in the Android manifest.

That also explained why this JavaScript code could not save the app:

MobileAds() .initialize() .catch((error) => { console.log('MobileAds initialization failed:', error); });

A JavaScript .catch() can only handle an error after the JavaScript runtime is running.

This crash happened earlier, while Android was initializing the native Ads SDK.

You cannot catch a native startup crash from the JavaScript layer.

I corrected the AdMob plugin configuration in app.json, verified that the Android application ID used the proper AdMob App ID format, and also added the Android advertising ID permission explicitly while cleaning up the configuration:

{ "plugins": [ [ "react-native-google-mobile-ads", { "androidAppId": "ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy" } ] ], "android": { "permissions": [ "com.google.android.gms.permission.AD_ID" ] } }

The important distinction is:

• The AdMob App ID uses ~

• The banner Ad Unit ID uses /

For example:

App ID: ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy Banner ID: ca-app-pub-xxxxxxxxxxxxxxxx/zzzzzzzzzz

Mixing those up, or failing to generate the App ID correctly in the Android manifest, can cause the Ads SDK to fail before the app reaches JavaScript.

The main lessons I learned:

1. An instant crash on launch may be native, not JavaScript.
   When the app dies before the first screen appears, do not immediately spend hours reading React components.

2. adb logcat is your best friend.
   One native stack trace can be more useful than reading thousands of lines of JavaScript.

3. A successful build does not mean the native configuration is valid.
   An AAB can build successfully, upload successfully, and still crash immediately in production.

4. JavaScript error handling cannot catch every failure.
   If Android crashes while loading a native provider, your try/catch and Promise .catch() blocks never get a chance.

5. The smallest configuration mistake can hide behind the largest file.
   I was convinced my messy codebase was responsible. The real issue was a native configuration entry outside App.js.

I am rebuilding and releasing the corrected version now.

Hopefully, the next screenshot is the app actually opening instead of another crash log.

The app, for anyone curious about a non-coder building an FX, remittance, and crypto fee comparison product:

https://play.google.com/store/apps/details?id=com.jkim1285.TransferIQMobile

Has anyone else spent hours debugging the completely wrong file?

Solo founder. No coding background. Built a fintech comparison app (remittance + crypto routes) entirely with AI tools (Claude + GPT Codex) in about 6 weeks. Shipped to Google Play. Built a companion website. Set up analytics, SEO pages, referral links — the whole thing.

Then I looked at my numbers:

• 166 users in 28 days

• 0% retention past week 1

• 1 organic search click. One.

And what was I doing with my weekends? Fixing a badge that was 2px off in dark mode. Adjusting spread calculations to show ranges instead of single values. Rewriting a cost display from percentages to currency format.

Nobody asked for any of it.

The Loop

Here's the trap I fell into — and I think a lot of solo builders fall into it too:

1. I notice a UI bug

2. I fix it

3. The fix breaks something else (thanks, Codex)

4. I fix that too

5. I check a competitor's app

6. "Oh, they display it like THIS. I should do that too."

7. Another full day of coding

8. Push update on Sunday

9. Monday: still 166 users

Repeat.

The worst part? I was productive. I was shipping code, squashing bugs, improving the product. It felt like progress. But my user count didn't move. Not even a little.

The Realization

I was solving problems that nobody complained about — because nobody was there to complain.

I was adjusting lighting on a stage with no audience.

The app works. It's not perfect. There's a provider showing a 56% fee that's obviously a calculation bug. The spread data shows single values instead of ranges. Some corridor badges are missing. Yes, these are real problems.

But here's the thing: these problems only matter if someone is using the product.

With 166 users (mostly from me sharing links on KakaoTalk), zero organic traffic, and zero retention — the bottleneck isn't code quality. It's distribution.

What Actually Needs to Happen

I mapped out where my users come from:

• 131 direct (me manually sharing links)

• 17 referral

• 8 organic

• Seoul accounts for 50 of the 166 users

So my real audience is Korean expats sending money abroad. My real moat is deep corridor knowledge (I've lived in Korea and Brazil, speak both languages, worked in crypto ops for 8 years).

But I was spending 100% of my energy on code and 0% on content.

The fix isn't another sprint of bug fixes. It's:

1. Write SEO content targeting my actual corridor (KRW→BRL, KRW→JPY)

2. Distribute on channels where Korean expats hang out

3. Stop touching code until a real user complains

4. Only do code updates on weekends, only based on actual feedback

The Rule I'm Setting

No code Monday through Friday. Only content creation and distribution. Code changes on weekends only, driven by user feedback — not my own perfectionism.

If nobody complains about the 56% fee bug, it means nobody's looking at Wise quotes on my app. Which means the bug isn't my problem. Getting people to the app is my problem.

For Other Solo Builders

If you're reading this and you recognize the loop — ask yourself:

• When was the last time a user (not you) reported a bug?

• Are you building features because users asked, or because a competitor has them?

• How much of your week goes to code vs. distribution?

If the answer to that last question is >50% code and you have <1,000 users, you might be in the same loop I was.

Ship it. It's good enough. Go find your audience.

Building TransferIQ — a remittance + crypto route comparison app. Currently at the "finding my audience" stage. Would love to hear if others have broken out of this loop and how.

Today I spent most of the day cleaning up TransferIQ’s remittance and crypto comparison cards.

The biggest lesson was simple: removing information is not the same as improving the UI.

I had to separate three things clearly:

• Data source labels, such as Live Exchange Market, Provider Benchmark, and P2P Pricing

• Product-specific costs, such as Fee Range, Spot Trading Fee, Card Fee Range, and Spread Range

• The final comparison metrics: estimated receive amount, estimated total cost, and arrival time

AI made the work much faster, but it also changed logic that I only wanted visually reorganized. That caused unnecessary bugs and repeated fixes.

The real job was not coding. It was defining what each number meant, deciding what should stay visible, and preventing the AI from changing calculations, API sources, rankings, and provider logic.

The final result is much cleaner and easier to compare across remittance providers, P2P, cards, and crypto off-ramps.

My main takeaway:

AI can dramatically increase development speed, but the founder still has to control product meaning, terminology, and data trust.