I’m a software engineer in Seoul. I have a day job, and I wanted a side project that could make a little money while I sleep. Not a course, not a newsletter about making money. A small tool that does one useful thing.

What changed for me this year is AI coding agents. For the first time, shipping a small product alone, in the evenings, without a team, felt realistic. I wanted to find out if that was actually true.

Two days later I had a public Apify Actor that returns official Korean apartment sale and rent prices in English. Along the way, my plan changed three times. This post is about those three changes, because they taught me more than the code did.

Where the demand actually is

Apify Store lets developers publish scrapers and data tools (“Actors”) and get paid per result. My first assumption was simple: I can read Korean and most Apify developers can’t, so Korean websites should be an easy niche.

I queried the Store’s public API for Korean sites. The assumption was wrong. There were already more than 200 Actors for Korean sites. Demand was heavily concentrated: shopping data alone had thousands of monthly users, while most other Korean sites had Actors with single-digit monthly users. Some popular Korean services had no Actors at all, but they also had no visible demand.

Lesson one: an empty category is not an opportunity. Usually it’s empty because nobody needs it.

The idea I dropped

The easiest thing to build was a wrapper around a Korean search-trends API. It was clean, official, and had a few paying users on similar Actors.

Then I read the API’s terms. Reselling results from an API key issued to you is the kind of thing these terms are written to prevent. Plenty of people seem to do it anyway. But I have a day job, and a legal dispute would cost me far more than the side project could ever earn. So I set myself a rule: legal risk doesn’t have to be zero, but it has to be something I’d be comfortable explaining to my employer.

That rule killed my best idea and pushed me toward public data.

Choosing public data

Korea publishes a lot of government data through its Public Data Portal (data.go.kr), and Korean law explicitly allows commercial reuse of public data as long as third-party rights aren’t involved. The apartment transaction dataset from the Ministry of Land, Infrastructure and Transport (MOLIT) is one of them: every reported apartment sale and rental contract, updated continuously, with no usage restriction beyond attribution.

The catch for foreign users is access. You need a Korean-language portal account and an application per dataset. That friction looked like a product: run the official API on my side and give people clean English output.

Building it

I built the Actor with Claude Code running in the cloud. I wrote a design doc first (inputs, output fields, pricing), then handed it over with explicit checkpoints.

The biggest unknown wasn’t the code. It was whether a Korean government API would answer requests from servers outside Korea, because Apify runs abroad. I honestly expected it to fail. Some Korean sites block traffic from abroad, and if this API did, the whole plan was dead before any real code existed. So one of the first things I asked Claude Code to do was not to build anything, but to make one real request and save the raw response. Claude Code’s cloud sessions also run outside Korea, so that single call answered the question. It came back with real transactions, and the project suddenly felt real.

Some numbers from the launch test:

• Seoul’s 25 districts, one month, sales and rentals: 18,111 records processed in 56 seconds
• 53 calls to the government API
• Platform cost for that run: about $0.00014
• Peak memory: 180 MB (the default was 4 GB, which I lowered so users pay less)

The API key lives in Apify as a secret, and I had the logs searched for any trace of it before launch. Zero hits.

The plot twist

Right before going public, I searched the Store one more time. There were at least seven other Actors built on the exact same government dataset. At least two of them also didn’t require an API key, and one developer offered theirs completely free. My headline feature, “No API key needed,” was not a feature anymore. It was table stakes.

All of them had roughly one monthly user. So the niche wasn’t crowded with customers. It was crowded with builders.

I think this will become normal. When an AI coding agent can turn a public dataset into a working tool in an afternoon, “I built it” is no longer a moat for anything built on public data.

What I changed

Instead of pretending I was unique, I looked for what the others didn’t do:

• Search any Korean district by English name (Gangnam-gu, Seoul Jung-gu, Bundang), not just numeric codes
• Sales and rentals in one run
• Optional monthly median rows, so you get a market summary instead of 18,000 raw rows
• Romanized place and apartment names, with a small brand dictionary so 래미안 becomes “Raemian” instead of gibberish

I also postponed charging. My planned price would have made it one of the more expensive options in a market where one competitor is free.

It’s live here: Korea Apartment Prices in English. Current revenue: $0. Current users: about one.

Lessons

1. Check demand before picking a niche. Look at monthly users, not the number of tools.
2. Read the terms before you write code. The easiest idea can be the riskiest one.
3. Public data is safe and fast to build on, and that’s exactly why it gets crowded.
4. Distribution is the moat. A Store listing alone won’t find users.

That last point is why this blog exists. Next month I’ll use the Actor to publish a short “Seoul apartment prices this month” report in English, and I’m starting on a second tool.

Have you shipped into a niche that turned out to be crowded with builders instead of customers? I’d genuinely like to know what you did next. You can find me on X at @seoulsmith_dev.