There's been a fresh wave of debate in the US about online age verification and what it means for free speech. The argument is roughly this: once a service has to verify your age, it's a short hop to verifying everything else you say or do. Some folks are calling it the precursor to automated attribution of speech.

I read those threads and I keep thinking the same thing. Korea has been living in that world since the early 2000s.

본인인증 is built into almost everything here. To sign up for a serious service in Korea you usually verify your phone against your national ID. KakaoTalk has 53 million MAUs in a country of 51 million people. When you log in with Kakao, the platform already knows who you are.

This is the landscape Western platforms are only now arguing about. And it's a real opportunity for anyone building software in Korea right now, especially small businesses without engineers.

What 'verified by default' unlocks for SMBs

A few things first-time builders ship in their first week on DontCode:

A neighborhood marketplace where every seller is a real, identified person. No throwaway accounts. No scammers.
A dues-collecting community app for a 동호회 or church group. Members log in with Kakao, pay monthly through KakaoPay, the organizer sees who's current and who's not.
A hagwon practice-test app where each student session is tied to a verified phone number. The account is the kid, not a shared link, so cheating drops.
A booking app where customers leave a small KakaoPay deposit to confirm. No-shows become a math problem with a known answer.

None of these need an engineer. They need three things: a login, a payment, and a database. In Korea, the first two are infrastructure now, the same way DNS is.

The product gap

Most Western no-code builders treat Korean payments and Kakao login as a 'we'll get to it later' thing. You can wire them up if you know what you're doing, but you usually don't, and it usually takes a week of fighting webhooks. That's the gap.

We built DontCode with Kakao OAuth, KakaoPay, NaverPay, and Toss in the box. You toggle them on. The platform handles merchant onboarding, signing keys, webhook secrets, and reconciliation. There's no integration code to write because there's no integration to write.

What you actually spend time on is the part that's specific to your business: the listings, the lesson plans, the menu, the schedule. The other use cases on our blog follow the same pattern.

Why this matters now

The West is about to spend a few years arguing about whether requiring ID online is a good idea. Meanwhile, Korean SMBs can ship a verified-user app this weekend and start charging next week.

If you've been holding off because the tech part felt out of reach, that part is solved. The hard questions are the business ones: who's your first customer, what do they actually pay for, how does anyone find you. Those don't go away.

But 'I don't know how to do auth and payments' doesn't really hold anymore. Spin something up at dontcode.co and see how far you get before you hit a wall. Most people are surprised how far that is.