How to Explain Technical Decisions to Non-Technical Clients

To explain technical decisions to clients who aren’t technical, talk about what changes for them, not how it works: what it costs, how long it takes, what happens if you don’t do it, and what changes for their team. Show the problem on screen instead of describing it, offer two or three options with their trade-offs, and recommend one. A short screen recording is a good format for this, because the client sees the slow page or the broken button with their own eyes.

This guide is written for freelance developers and agency teams who need a client’s decision on something the client can’t evaluate alone.

Talk about outcomes and trade-offs

Your client doesn’t care about the framework, the database or the plugin. They care about four things:

1. Cost: how much now, and how much every month after.
2. Time: how long, and whether it moves the launch.
3. Risk: what happens if we don’t do it.
4. Change: what’s different for them and their team afterwards.

Translate each technical point into those terms before you explain it:

What you’d say to a colleague	What the client needs to hear
“The booking plugin is unmaintained.”	“The booking system won’t get security fixes anymore. It works today, but each month it stays, the risk goes up.”
“We should add caching.”	“Pages will load faster. After you edit a page, the change may take a few minutes to appear.”
“Let’s move to a headless CMS.”	“More freedom in design, but two systems to maintain instead of one, and a higher monthly cost.”
“There’s a lot of technical debt.”	“Shortcuts from earlier make every new feature slower and more expensive to build.”

If a sentence still needs a technical word to make sense, explain the word once, in passing, and move on.

Show, don’t tell

“The page is slow on mobile” is an opinion. A recording of the page taking ages to show the product photos on a phone-sized window is a fact the client can see. Video is the easiest way to show a technical problem to someone who isn’t in front of your screen:

• The problem as the customer sees it: the checkout button that does nothing on Safari, the form that loses what you typed.
• The before and after: the old page and the faster one, side by side.
• The screen they’ll use: the admin panel after the change, so “a new editor” stops being abstract.

Circle the part that matters while you talk. Drawing on the screen during the recording does that well; see how to draw on your screen while recording on Mac.

Use analogies carefully

A good analogy from the client’s own world makes a decision click. A few that tend to work:

• Maintenance and updates are like servicing a car: skip them and it still drives, until it doesn’t.
• Technical debt is like a restaurant kitchen that isn’t cleaned between services: every service is slower than the last.
• Backups are like insurance, except you should check they work before you need them.

Use one per decision, not one per sentence. And say where it breaks: “unlike a car, a security hole can be used by someone else before anything looks wrong”. An analogy that hides a cost or a risk is worse than none.

Give options with their costs

Most technical decisions have more than one answer. Present two or three, including “do nothing” when it’s a real option, and put them side by side:

Option	Time	Ongoing cost	Risk
Keep it as it is	None now	None	Grows every month without fixes
Replace it with a maintained plugin	About two days	A yearly license	Low; bookings move over
Build a custom booking form	About two weeks	Our maintenance time	Low, but more to look after

A hypothetical example: times and costs depend on the project.

Then recommend one and say why, in one sentence: “We’d replace it with the maintained plugin: two days of work, and the risk goes away.” Clients decide faster when you’ve done the thinking and they only need to agree. For the money side, walking a client through a quote by video uses the same approach.

A structure for the explanation

Whether you record a video or write an email, this order works:

Send it with the ask in writing too, so Giulia can answer from her phone without replaying the video:

Hi Giulia, three minutes on the booking system. Nothing is broken, but the plugin won’t get security fixes anymore. I recommend replacing it (about two days of work). Can you let me know by Friday which option you prefer?

https://justrec.app/v/k3f9Qa

Booking system: three optionsJustRec · 3:05

What not to show

A screen recording for a client is not a code review. Leave out:

• Code. Unless the client asked for it, code signals “this is complicated” and nothing else.
• Credentials. Passwords, API keys, environment files, terminal history with tokens. Send access through a password manager, never in a video.
• Logs with customer data. Error logs often contain names, emails and order details.
• Other clients’ projects. The sidebar of your editor and your browser tabs can show them.
• Internal chat about the client or the problem.

When to explain it live

Some technical decisions are too big for a video alone: a rebuild, a platform change, anything that changes the budget a lot. Send the video as a pre-read, then decide on a short call. We cover the line between the two in when not to send a video to a client.

And keep the explanations for later. When the project ends, the same approach makes a good handover: website handover videos show the client how things work without a single line of code. The complete guide to async video for client communication puts all of it together, and our page for freelancers shows how JustRec fits a one-person practice.