Are you working as a freelance developer? Or maybe running an SI business?
If so, have you ever calculated how many hours of unpaid work you did this month?

I sometimes meet friends who take on freelance work as a side job, and every now and then, they say things like this.

“I spent about five hours last weekend and made almost 500,000 won. Freelance work has been pretty nice lately.”

Earning extra income as a freelancer can feel great, especially for full-time employees.
Even if it is only a few hundred or a few thousand dollars, that extra income can make us very happy.
But whether you take on outsourcing work seriously or as a side job, the reality of freelance work is an endless fight against non-billable hours.

The Unpaid Work You May Not Even Realize You’re Doing

Let’s revisit one of the most painful scenarios in freelance work.

You work hard to find clients, and luckily, you land a meeting with a potential client.
You spend two hours in that meeting, passionately listening to the client’s requirements.
You come home and spend another three hours organizing the meeting notes, analyzing the client’s needs, and identifying the core features of the product.
You have a meeting with yourself about how this feature should be implemented, and what risks that feature might have.
Then you spend another hour carefully preparing and sending an estimate.
Will the client accept this price?
Will I, or my team, at least not lose money if we take this project?

That is six hours in total. Even if we calculate your hourly rate at only 50,000 won, that is 300,000 won worth of work.

A few days later, you receive a polite email saying, “We’ll review it and get back to you.”
And then you never hear from that client again.

In the end, those six hours become non-billable hours. In other words, pure loss.
Even if you do end up signing with the client, the income you thought you earned in five hours was actually income that took eleven hours to make.

No matter how well we master the latest tech stack, or how much AI cuts our coding time by 50%, that alone does not do much to reduce non-billable hours in the sales stage.

According to an analysis by Freelance Informer, a media outlet specializing in freelance work, many freelancers spend around 30% of their working hours on non-billable activities such as client acquisition, administration, and proposal writing.
This suggests that freelancers may actually be earning about 30% less than they think.

 Freelancers might actually be earning 30% less than they think. <Source: Freelance Informer>

The Real Reason Deals Fall Through: Client Anxiety

Why do we fail to close deals? Why do so many client meetings fail to turn into contracts?
To answer that, we need to step inside the client’s mind.

Many clients are not IT experts.
Most of them only have an idea for a product and a vague sense of how that product might work.
At the same time, they carry a huge amount of anxiety.

“What if this developer does not build it properly?”
“What if the final result is completely different from what I imagined?”

If that anxiety is not resolved, the deal does not close.

While running SI projects and working with many freelancers, we have observed three types of developers and PMs in client meetings.

When you’re facing a client’s rough ideas and anxious eyes... <Source: Author, generated with ChatGPT>

Type 1: The Coder

• Client: “I want to build an app like Instagram. But it would only be used by people in a specific profession.”

  
  

• Developer: “Yes, that’s possible. We’ll use React Native for the frontend, Node.js and Express for the backend, and MySQL for the database... The estimated cost would be...” (Technical explanation)
  
  

• What the client is thinking:
  “What does that mean? Is this really the most efficient way to build what I want? Will this actually lead to the result I have in mind?”
  
  

  Anxiety rises → the client gives up on the contract.

The Coder type communicates only through technology.
But what the client wants is not technology. It is an outcome.

Type 2: The Salesman

• Client: “I want to build an app like Instagram. But it would only be used by people in a specific profession.”

  
  

• PM: “Of course, that’s possible! We can include Reels by default, add DM features, and even connect an AI chatbot. The project timeline would be around this long.”
  (Overpromising)

  
  

• What the client is thinking:
  “They sound smooth... but is this estimate really right for all of that?”
  
  

  Suspicion rises → the client gives up on the contract.

The Salesman type says yes to everything.
But a yes without a concrete execution plan only makes the client more suspicious.

Type 3: The Partner

• Client: “I want to build an app like Instagram. But it would only be used by people in a specific profession.”

  
  

• Developer/PM: “Understood. Instagram has a lot of features. If you had to choose just one core feature you want to implement first, what would it be? 1) a photo-sharing feed, 2) short-form videos like Reels, or 3) DM?”
  (Planning question)

  
  

• What the client is thinking:
  “Ah, this person is trying to make my idea more concrete.”
  (First layer of trust)
  
  

• Developer/PM: "If the photo sharing feed is key, what screen will users see as soon as they sign up? Will it be other people's photos, or a button to upload photos? If you haven't thought about it, I think it would be good to show other people's photos first and then make the next screen the upload button. That's because~" (In-depth questions and expressing professional opinions)
  
  

• What the client is thinking:
  “Ah, my idea was still vague. I didn’t realize all of this was needed. I can work with this person.”

  Trust rises → the deal closes.

Clients are not buying technology. They are buying a solution to their problem.
And they are buying a trustworthy partner who can build that solution with them.

Planning capability is one of the strongest sales capabilities at this stage, because it reduces the client’s anxiety and creates trust.

What should we do to win client contracts? <Source: Author, generated with ChatGPT>

A Simple Proposal that Turns Free Labor into Paid Contracts

Simple Planning Doc That Turns Unpaid Work into Paid Contracts

The core tool we recommend for becoming a Partner-type developer and improving your close rate is a simple planning document.

The consultation stage is not the development stage.
It is the sales stage.

At this stage, if you want to reduce the client’s anxiety and build trust, you need to present a clear deliverable beyond just an estimate.
For us, that deliverable is usually a simple planning document.

By “simple planning document,” we do not mean an 80-page planning document that defines every screen and explains every detailed policy.

It is a core summary that shows how the developer understood and shaped the client’s idea based on the meeting.
Ideally, this document should be sent within 24 hours after the meeting.
At the latest, within 48 hours.

4 Key Elements of a Simple Planning Doc

As mentioned earlier, a simple planning doc does not need to include everything a full planning document would include.

Before a contract is signed, we usually include only the following core elements.

1. Project Definition (PRD): What Are We Building?

This is the north star of the project.

Instead of saying “an app like Instagram,” make it clear:

“A community app for real estate agents in their 20s to 40s who are familiar with mobile environments, where they can share and communicate about local news through photos.”

By organizing the client’s requirements this clearly, you can earn the client’s trust.

2. Core Feature Spec (MVP): What Needs to Be Included?

This is not about listing every feature that might be included in the final product.

It is enough to include the core features the client mentioned during the meeting, along with a few suggestions.
At this stage, we usually refer to the MoSCoW method.

• Must-Have: Example: social login, photo feed, comments/likes
  The service cannot exist without these.
  
  

• Should-Have: Example: My Page, hashtag search
  Important, but can be left out of the first release.
  
  

• Could-Have: Example: DM, Reels
  Targets for future improvement.

This classification alone gives the client the feeling that their idea is becoming organized.

3. Information Architecture (IA): How Does It Work?

An information architecture that shows the menu structure at a glance. <Source: Author, created with Manyfast>

You do not need to create a fancy wireframe in Figma or Sketch.
If you do, the client may focus only on whether the screen looks pretty and miss the essence of the project.

Instead, use simple text to show the menu structure and the user’s core path.

1. Home (Feed List)

   • 1-1. Feed Detail (Comments)

2. Upload

3. Search (Hashtag)

4. My Page

5. My Posts

6. Settings

This alone helps the client imagine the outcome of the project much more concretely.

And once the client can imagine the result, the contract is one step closer.

4. Feature-Based Rough Estimate: So, How Much Will It Cost?

This is the key.

A lump-sum estimate like “20 million won in total” feels like a black box to the client.

Instead, present the estimate based on the core features defined in section 2.

• Social Login: 1 million won

• Photo Feed (Read/Write): 3 million won

• Comments/Likes: 2 million won

• My Page: 1 million won

• Total: 7 million won

This one-page planning doc should be sent together with the estimate.

This document is strong evidence that says, “I have made your idea this concrete.”
It also proves that you are not just a coder, but a partner.

How quickly and accurately you can create this document is a core capability for freelance developers who want to reduce non-billable hours and improve their close rate.

Three Financial Benefits of Clear Planning

Being able to quickly create a clear planning document does not only improve your close rate.

Even after the project begins, it brings three strong financial benefits that can maximize a developer’s profitability.

Benefit 1: Price Haggling Becomes Feature Negotiation

• Before: No Planning Doc

  “The total cost is 20 million won.”→ “That’s too expensive. Can you do 18 million?”
  → “Ah... then we’ll do it for 18 million this time.”
  (The race to the bottom begins.)

• After: With a Planning Doc

  “The total cost is 20 million won. Please refer to the planning document for the details.”→ “That’s too expensive. Can’t we do 18 million?”
  → “In that case, the comments/likes feature accounts for 2 million won. How about we leave that out for the first release, launch first, and add it later after seeing the response?”
  (A concrete and healthy negotiation begins.)

The planning document becomes the basis for the estimate and builds trust.

The client no longer negotiates around vague costs.
Instead, they can adjust the budget clearly by feature.

This increases the developer’s professionalism and helps prevent unnecessary discounting.

Benefit 2: Rework Becomes an Add-On Contract

The biggest disaster in project management is scope creep — additional requirements that go beyond the agreed scope.

According to PMI’s 2021 Pulse of the Profession report, 34% of projects experienced scope creep.

If you have worked in SI or as a freelancer, you have probably experienced this yourself.

Of course, some level of change is something we have to accept.
But every time it appears, it still creates stress.

34% of projects experience scope creep. <Source: PMI report>

As a simple example, imagine this situation.
The project is already well underway, and the client sends you a Slack message.

“Ah, K. We discussed this internally and decided to use a referral program for product marketing. Could you also make it possible to enter a referral code during sign-up? It seems like a simple change.”

• Before: No Planning Doc

  • “Ah... yes. But if we implement that feature too, the timeline may be pushed back a little...”

    • (Unpaid rework begins. It is not simple. Profitability drops. Stress rises.)

      
      

• After: With a Planning Doc

  • “Yes, that’s a good feature. However, based on the planning document we agreed on during the meeting, the referral code is an additional item outside the original estimate. To include that feature, it would require three days of development work and an additional estimate of 2 million won. Would you like to proceed with an add-on contract?”

    • (Paid add-on contract. Profitability protected.)

      
      

A clear planning document written from the beginning becomes a Scope Shield that protects the project boundary and serves as the project’s standard.

It makes it possible to have a business discussion based on objective materials, rather than an emotional refusal.

Benefit 3: Clients Become Fans

A developer who communicates through clear planning and maintains quality within the agreed scope is no longer seen as just a contractor.

They become a trusted partner.

The client begins to feel:

“I can communicate with this person.”
“This person thinks about my business with me.”

Developers like this naturally receive the next project from the same client, or secure stable recurring revenue through maintenance and additional work contracts.

This is one of the keys to solving the biggest concern freelancers have: unstable income.

It maximizes the lifetime value, or LTV, of each client.

Increasing profitability is the dream and goal of every SI business and freelancer. <Source: Author, generated with ChatGPT>

Conclusion: Your Value Is Decided by Planning Skills, Not Coding Speed

It is now widely understood that AI coding tools like GitHub Copilot and Claude have significantly lowered the barrier to coding itself.

According to McKinsey’s 2024 research, generative AI could improve software engineering productivity more than any previous advancement, increasing developer productivity by 35% to 45%.

This means we are entering an era where coding speed alone is no longer enough to differentiate yourself.

AI is extremely fast and capable.
But it is like a highly competent intern that cannot decide what should be built on its own.

In the future, the value or hourly rate of freelance developers and outsourcing companies will not be determined by how quickly they build.

It will be determined by how accurately they define and plan the problem.

That is because the quality of your planning determines the quality of the prompts you can give to AI.

The power to turn your seven hours of unpaid work into a 7 million won paid contract does not come from flashy coding skills.

It comes from the ability to write a clear planning document.

If you are working as a freelancer, running an SI business, or considering taking on outsourcing work as a side project,
it may be worth asking yourself:

How can I improve my planning skills?

👉Read on Yozm IT, the IT magazine for today’s professionals.