DEV Community: Aldo Barbosa

trying to figure out who decides how risky a client request actually is

Aldo Barbosa — Mon, 07 Sep 2026 14:51:25 +0000

got a lot of good pushback on my last post about the "milestone locked = billable" thing. someone in the comments reframed the whole problem as blast radius instead of size or hours, and it stuck with me. so i sat down to sketch out how i'd build that into the tool and immediately got stuck, before writing any code.

sorting requests into buckets isn't the hard part. cosmetic stuff like copy or colors, just log it and move on. anything touching data, auth, or something already approved, that needs an actual review.

what i can't figure out is who does the sorting.

if it's me tagging every request that comes in, i'm back to manually triaging everything, which is the whole thing i was trying to get away from. if the client tags it themselves, every request turns into "just a small tweak" because nobody rates their own request as the risky one.

only idea i've got so far is giving them a short list to pick from when they submit something, like visual tweak, content change, new behavior, something's broken, and letting that map to a risk level on my end instead of asking them to judge the risk directly. but even that breaks down fast, like a "visual tweak" that happens to touch a component used in three other places.

haven't even gotten to the change budget idea some of you brought up last time either, wanted to sort this part out first.

anyone dealt with this before, where the person doing the classifying has a reason to underplay how risky it is?

How do you decide which client requests need a formal change process vs which don't?

Aldo Barbosa — Thu, 03 Sep 2026 15:08:52 +0000

for a while my approach to scope creep was pretty binary: milestone approved = locked, anything after = billable. that killed most of the "i never said it was final" arguments.

but it created a new problem. treating every tiny request the same way as a big one started annoying clients. a client asking to change a button color got the same "that's a change request" response as someone asking to rework the auth flow, and that felt disproportionate, even to me.

talked this through with someone in the comments on my last post, and they framed it in a way that stuck with me: the threshold isn't size or hours, it's blast radius.

a two minute database change can carry more risk than a two hour UI tweak. cosmetic stuff (copy, colors, spacing) can just get logged and batched. anything touching data models, auth, integrations, or something already inside an approved milestone needs an actual impact pass, regardless of how small it looks on the surface.

they also mentioned keeping a small "change budget" for minor stuff, once that's used up, the next request automatically becomes a formal change order instead of a favor.

i haven't fully implemented this yet, still mostly running on the old binary version, but it's making me rethink where i draw the line.

how do you all decide what's worth the formal process and what isn't? going by hours, going by what the change touches, or something else entirely?

The biggest mistake i made with client contracts (and how i fixed scope creep)

Aldo Barbosa — Mon, 31 Aug 2026 14:45:48 +0000

on my first few freelance projects, my contract had one big flaw: it treated delivery as a single event at the very end.

what always happened:

client would say "looks good" on staging in week 2
in week 5, right before launch, they'd ask to redo the entire homepage layout
when i mentioned extra cost, they'd argue: "but the project isn't launched yet, so this is just part of it"

i lost so many weekends doing free reworks because of that loop.

now i do two simple things differently:

every milestone is an isolated delivery. once stage 1 (e.g. design/auth) is approved, that code is locked. any changes after that are billed as an add-on.
no verbal or slack sign-offs. i send a private link via Velloxis where they click to approve before i start writing code for the next stage.

it completely killed the "i never said it was final" argument.

how do you guys handle clients who try to redesign early features right before launch?

Update: Why non-technical clients hate client portals (and what actually worked)

Aldo Barbosa — Fri, 28 Aug 2026 14:40:38 +0000

A few days ago I posted here about a simple tool I put together to handle client milestone sign-offs.

Reading through the comments and chatting with other devs, one thing kept coming up over and over:

The second you force a client to create an account, the system is dead.

Why standard client portals fail

Most portals are built by devs for devs. We're totally fine logging in, dealing with 2FA, checking kanban boards, and organizing tickets.

Non-technical clients don't care. If they have to:

Open an invite email
Set a password
Remember their login 2 weeks later

...they just won't do it. They'll abandon the board and go right back to texting you on WhatsApp or DMing on Slack asking for "quick status updates".

What actually worked for my client projects

To stop the endless DM chaos, I stripped out everything that causes friction:

Single magic link: Client gets one private URL for the project. No password, no signup.
Visual milestone breakdown: They see the exact deliverables for that specific stage.
One-click sign-off: They click to approve before I start the next phase, which locks it with a timestamped audit log.

Since putting this into Velloxis, client compliance went to basically 100% simply because there's zero barrier to entry.

If you do client work, do you still use dashboards with logins, or have you moved to frictionless links/docs?

Built a simple client sign-off portal to stop endless unpaid revisions

Aldo Barbosa — Tue, 25 Aug 2026 16:53:10 +0000

anyone who freelances knows the pain: you finish a website build, send it over, and suddenly the client remembers 10 "small tweaks" that end up taking another week of unpaid work.

i tried using trello, jira, and notion to get them to sign off on stages, but non-tech clients never bother creating accounts. they just ignore the invite and text you on whatsapp anyway.

got tired of arguing about scope, so i put together a lightweight tool called Velloxis.

the idea is stupidly simple:

you send the client a private link (no login, no password, no signup for them).
they see what’s done for that milestone.
they click a button to approve it before you start the next phase.
it logs a timestamped sign-off.

now if they come back later asking to redo something they already approved, there is a clear record and it makes charging for extra hours way less awkward.

curious how other devs here handle milestone sign-offs with stubborn clients?