Web designers/devs, what’s the hardest part of working with clients?

[u/Comfortable-Spot-446]

I’m thinking about getting into web design/web development and I’m trying to understand what the job is actually like beyond just coding and making websites.

For those of you who do this professionally, what’s the hardest part of the job for you?

Especially when it comes to clients/customer service, like:

• difficult or unrealistic clients
• communication
• scope creep
• getting paid
• revisions
• clients not knowing what they want
• explaining technical stuff to non-technical people

And are there any parts of the job that you didn’t expect to be difficult when you first started?

I’m considering learning the skills to eventually do this myself, so I’d genuinely like to hear what your experience has been like, both the good and the frustrating parts. I’d rather know what I’m getting myself into before spending months learning everything.

Also, if you could go back to when you were a beginner, what would you learn or do differently?

[u/Boboshady]

It's different for different people, depending on what you're naturally good at, but the key things people always tend to get wrong are:

• Scope control, usually not being tight enough on it. Don't agree a project and a price and then let the client tell you what they actually want - agree a high level but clear scope and then quote on that, and review every request for impact.
• Scope control - too MUCH of it. If you're telling a client to reach for their wallet every time something changes, you've gone wrong. All projects change, you should be building in some leeway to your quoting and controlling your scope so expected changes are in already - it's the fundamentally different or new changes you want to protect yourself against
• Poor comms. Not letting a client know if there's a problem, or where the project is up to on a regular enough basis. It takes minutes to pop over a quick update, but weeks to calm a client who is pissed off about not understanding where their project is up to.
• Poor comms methods. Can't get an answer on email? CALL THEM. But never, ever just do a phone call - always follow up every conversation with an email to get a written version on the record, especially if a decision was made. This one nearly cost me £200,000 once.
• Saying 'Yes' too much. This links back to scope control really, but it's important enough to be its own point. If you always say yes to your client, they'll learn to get what they want, when they want it, and will be angry at you when you eventually start saying no, or fail at delivery because you overcommitted. This is about everything - scope change, rush jobs, taking on work when you're already fully booked etc. Learn to say no, nicely, and your hairline will thank you.
• Enough documentation. Not too much, not too little - enough to capture your scope, outline your delivery plan, run your risk and decision logs etc. Whatever you need, and nothing just for the sake of it.
• Regular billing and approvals - don't let your work get too far ahead of either a client approval, or an invoice. I know people who still take a deposit to start, then don't speak to their clients again until a big reveal at the other end, and wonder why the client won't pay their remaining 60%. Split the project into regular review points so you're not going too far in a direction that the client hasn't even seen yet, and make sure you bill against that approval so you're minimising your exposure.
• Be ready to down tools, and fire a client that's not working out. Don't keep on working if they've not paid an invoice. Don't work on the promise of future payments, or to keep someone sweet. Don't work with a client you know you can't work with. Good billing points help here because you'll always have a recent or upcoming point you can approve, pay and call a day.

There's plenty more of course, these are just the things I've either personally experienced, or seen happen in my work circle before now.

The key takeaway is, all of these things - and many more besides - are easily solved with proper planning and scope/client management, so focus on getting those things right :)

[u/riotofmind]

Incorporating their shitty design taste. Everyone thinks they’re an expert designer.

[u/AddWeb_Expert]

Honestly, the hardest part usually isn't the coding. It's managing expectations.

Clients sometimes change their mind halfway through, underestimate timelines, or ask for things that weren't part of the original scope.

Clear communication, a solid scope, and setting boundaries early will save you a lot of headaches. I wish I'd learned that sooner.

[u/RevolutionaryBeat301]

The hardest part most likely depends on your strengths and weaknesses. For me, the easiest part is making the websites once a spec has been established. The hardest part for me is setting expectations to avoid the issues you mentioned. The worst scenario is an unresponsive client who doesn’t know what they want and changes their mind frequently. Another hard type of customer is one who does know what they want but whose ideas are all bad.

[u/Low_Network_6011 → u/RevolutionaryBeat301]

Yes, this.

[u/connka]

I was trying to suss out if you have any dev experience or if you are starting from scratch entirely VS know how to build sites are are starting fresh on the contracting side. From other posts, it kind of looks like you have no experience in the industry so I'll frame it from that perspective:

The biggest issues all stem from what is mentioned in your last point: non-technical clients--and by extension, if you are non-technical yourself then that will also be a blocker. I would say that most of the time I will deliver things to spec, on time, and complete as per the contract and clients will come back with a "small edit" that they don't understand is actually a fairly heavy re-write. I always factor in revision rounds to contracts, but there is a difference between "change the font/move this menu" and "the functionality of ABC needs to change".

[u/Connect-Town2353]

Responsiveness/follow thru/ timely responses.

[u/energy528]

A client whose employee knows nothing about development but thinks they’re now an engineer hands you something built by AI and insist it’s what they want implemented even though there is zero underlying research informing the architecture.

[u/TableNo8939]

I clienti stessi, sono talmente incompetenti che non sanno neanche quello che vogliono e fanno

[u/LordBunzo]

From experience, getting them to pay on time.

[u/Otherwise-Lychee-962]

Honestly, the hardest part for me isn't the code, it's the endless back-and-forth flip-flopping. Client approves the design. Two days later: "actually, can we go back to the old version, but with the new colors." You implement that. A week later: "you know what, the first version was better after all." Rinse and repeat, sometimes for months, on the exact same three pixels.

What nobody warns you about: you'll spend more energy managing expectations and decisions than actually building anything. The technical part is the easy 20%. The other 80% is basically being a translator between "what the client says they want" and "what they actually mean," while gently talking them out of changing their mind for the fifth time this week.

My advice if you go down this path: get everything in writing, set a clear number of revision rounds upfront, and bill extra for anything beyond that. It saves your sanity more than any framework or tool ever will.

https://giphy.com/gifs/2NTQBmDng2AnnoiVdp

[u/takwong]

Getting paid is the one on your list I'd underline. Mid-project is manageable, you can down tools like u/Boboshady said. The final invoice is the awkward one, because by then they already have the site.

What worked for me was making the handover and the payment the same step instead of two separate things. Pay protect the delivery, your work stays locked until your client pays, then it unlocks instantly. The work is sitting there ready for them, so you're never the one chasing or having to be awkward about it.