Why Do Dev Agencies Only Ever Build Other People's Apps?

I've always wondered about this. Why don't the people who teach you how to trade stocks make their money trading stocks? Why do the people who teach online-store selling teach it instead of just running a store? In the same way: dev agencies are arguably in the perfect position to run an IT business of their own — so why do they only ever build other people's? After getting into this business myself, I learned the industry's open secret: agencies can be great at doing what they're told, but they're remarkably weak at finding and doing work nobody asked them to.

Dev Outsourcing Is a "Homework" Business

The economics of dev outsourcing reward you for putting in the least possible engineering resource while charging as much as you can. So you end up treating every task like homework assigned by a teacher. Going and finding extra homework to do earns you nothing.

As a result, all of your thinking centers on "do the homework the client gave us, well." The question "what does this client actually need next?" rarely gets asked. Here's an example, from the client behind the dental-clinic website a marketing agency built for ₩5.5M (~$4K) (and what it really should have cost).

How a Typical Agency Responds vs. How We Respond

Take the contact-collection page on a dental clinic's site. A visitor enters their phone number and a message; the clinic's front desk reviews the inquiry and calls the patient back. Dead simple. When an agency gets a request like this, 99% of the time the response is:

Typical agency response

Build a form for the customer's phone number, name, and message, and an admin page that displays exactly that — phone number, name, message.

You might ask: what's wrong with that? Nothing — the agency just finished the homework as assigned. And since building anything more earns them nothing, stopping there is fine. They built exactly what the requirements doc said.

How we responded

Sure, the client asked for a feature to enter and view contact info and inquiries, so we could have stopped there too. But picture the clinic's front desk for a second. Odds are it's chaos. Several people might be handling inquiries at once, or it might be one person juggling everything. In the rush, it's easy to lose track of which inquiries have already been handled across multiple staff. What if you built the feature imagining that situation?

• A way to see which admin checked a given inquiry, for when multiple people are handling them
• A way to see whether a given inquiry has been fully resolved

We could have built it to just show "John Doe / 010-1234-1234" and nothing else. The client never once asked for these features — probably because it's hard to anticipate needing them. They weren't in the requirements doc, and we didn't charge more for them. We just did it. Because we don't want to be a typical agency.

It's the Structure of the Industry

A dev outsourcing shop may be great at doing what it's told (and honestly, even just doing that well puts you in the top 10%), but thinking about what the client needs next is something the structure makes nearly impossible.

The second reason — a shop that's run platforms first-hand and been through the wringer vs. one that's only ever coded — is what I'll cover in the next post.

---

A good development partner doesn't just do the homework. It thinks ahead to the things nobody asked for. Potential is a development partner that helps Korean and Asian founders expand westward — and we look past the spec to the context behind it. Reach out anytime.