As Important as the Code: What You Say and How You Say It

When I started doing freelance work for companies in 2024, writing the code was the easy part. The hard part was this: most of the time the client does not know exactly what they want, and if you just say "sure," two weeks later you have built the wrong thing.

What follows is what I learned during that period and while building my own products — none of it technical, all of it at least as useful as technical knowledge.

1. Write down your understanding and get it approved

Before I start any work, I write out my understanding in my own words and send it over:

"As I understand it: a 5-page corporate site, the contact form lands in your inbox, no blog section for now. Delivery in 3 weeks. Is that right?"

Those three sentences have saved me from countless rebuilds. More often than not the client replies "yes, and could we also have this" — and that "this" gets discussed before any work begins.

2. Instead of "that can't be done," say "here is how it can be done"

When a request comes in that is technically impossible or very expensive, refusing it outright puts the other person on the defensive. Laying out the cost and an alternative side by side moves the conversation forward instead:

• Bad: "That can't be done."
• Good: "Done that way it takes about two weeks. We can get the same result in three days by doing it this other way, and the only difference is this. Which would you prefer?"

Leaving the decision to the client both helps them make the right call and shares responsibility for the outcome.

3. Deliver bad news early

Say it the day you realize you are going to miss the deadline, not on the delivery date. A delay announced early is a problem; a delay announced late is a loss of trust.

4. Do not avoid the price conversation

Talking about price too late puts both sides in an awkward position. The healthiest thing is to give a number right after the scope is clear. Saying up front that the price changes if the scope changes removes the argument you would otherwise have later.

Being able to say "this extra request is out of scope; it needs this much additional time and this much additional cost" is one of the most necessary skills in freelance work.

5. Store copy is sales language too

The same rule applies on the product side. The description in the app store is not a technical spec sheet, it is a piece of persuasive writing. The user is not looking for an answer to "what does it do" but to "which problem of mine does it solve".

6. Every word in the interface is a sentence

Button labels, error messages, empty state text — all of it is communication with the user. Saying "an error occurred" leaves the user on their own. Saying "couldn't connect, please try again" tells them what to do next.

7. The same rule holds in a job interview

If you cannot explain the work you did, having done it is not enough on its own. When describing a project, this trio works well: what the problem was, what I did, what the result was.

"I built an app" is a sentence. "Users kept forgetting expiration dates; I redesigned the notification system and we passed app store review on the first try" is a story. The second one sticks.

I have been writing code for eight years. Looking back, the things that changed my career the most were not the languages I learned; it was learning what to say and how to say it.

• Communication
• Freelance
• Client management
• Scope
• Sales language