Hiring Developers on Kmong: Five Things to Know First, from a 5.0-Rated Seller

This is neither a promotion of Kmong (a major Korean freelance marketplace) nor a takedown of it. We — Freesi — are a 5.0-rated seller of development services there, and at the same time a development company that takes projects through its own site.

So this is written from a position that sees both sides: how to commission work well on the marketplace, and which projects are better handled by contracting a development company directly. The short version is that both are correct answers, in different situations.

The real value of a marketplace like Kmong is two things: escrow (the platform holds your payment, so the money cannot simply disappear) and reviews (you can see a seller's actual transaction history). Those protections matter most on:

Clearly bounded one-off work in the 500,000–5,000,000 KRW range (approx. USD 360–3,600) — scraping scripts, automation tools, landing pages, simple programs

A first time outsourcing, with no instinct yet for reading vendors — reviews act as a filter

When you want to start quickly — inquiry to kickoff takes days

Within that range, commissioning through the marketplace is a reasonable call. We run plenty of projects at that scale there ourselves.

From the inside, the signals that separate good sellers from risky ones are fairly clear.

Read the body of the reviews, not the star rating. A 5.0 average is common. The information is in the review text — look for sellers with many reviews containing specific sentences ("thorough right down to the such-and-such feature," "fast on revision requests"). A seller with nothing but one-line praise gives you nothing to judge on.

A seller who asks a lot of questions before quoting is a good seller. Questions about exception cases — "how should we handle it when this happens?" — come from people who have actually built the thing. If a price arrives immediately after your requirements with no questions attached, the odds of hearing "that was not in scope" later go up.

Ask directly about experience with your project type. Great reviews do not help if the seller has never done a payment integration and you need one. One question does it: "Have you built something similar before?"

Keep payment inside the platform. Decline sellers who propose dealing outside to save on fees — the moment escrow protection is gone, so is the reason for using the marketplace at all.

From the seller side too, some projects are hard to run through a marketplace chat window.

Projects above 10,000,000 KRW (approx. USD 7,200) running several months. At that scale you need a requirements document, acceptance criteria per milestone, and a formal contract stating scope, warranty, and source code ownership. Handling that through message-based marketplace transactions carries real dispute risk.

Systems where long-term maintenance matters. Marketplace transactions are structured to close per job, so a system that will need ongoing operation, incident response, and new features is safer with a party that will sign a maintenance contract including an SLA (an agreed response time).

B2B purchasing that runs on formal contracts and tax invoices. If your company requires a signed contract and a tax invoice (the VAT invoice Korean companies need for their books), a direct business-to-business contract is cleaner from the start.

For projects like these, contract a development company directly — us or anyone else. The criteria for choosing are laid out in where to outsource development.

Worth knowing: the same seller can price differently depending on the channel. Marketplaces charge sellers a transaction fee, and sellers generally reflect that in their prices. In other words, the platform's protections — escrow and dispute mediation — have a real cost inside the price.

That is not a criticism. As the price of protection when transacting with someone for the first time, it is reasonable. The nuance is simply that on a second or third project with a development company you already trust, a direct contract can be more efficient for both sides.

Marketplace or direct contract, these three apply identically.

1. Scope in writing — keep the screen list and the in-scope/out-of-scope split in a document (an attachment), not in a chat thread.

2. Acceptance criteria first — agree on what "complete" means (tested with real data, and within what window) before work begins.

3. Confirm source code ownership — whether the deliverable includes the complete source code, and whether accounts and keys are in your name.

With those three, the failure rate drops sharply on any channel. Without them, disputes happen on any channel.