Running WorkflowHyd as an independent practice alongside other work taught me things no employment contract ever will, mostly because the mistakes are entirely mine to absorb. Here's what actually changed, not the advice that sounds good in a tweet.
Vague scope is the root of almost every bad project
My worst projects, without exception, started with a scope document that felt "close enough." A line like "build a website for our business" without agreement on page count, revision rounds, or what counts as a change request versus a new feature is where scope creep is born — not out of client dishonesty, but out of genuinely different mental models of what was agreed. Now every project starts with a written scope specific enough that both sides could point to it mid-project and agree on whether something is in or out.
Scope creep is rarely bad faith. It's usually just two people who never agreed on the same definition of "done."
Fixed price only works with fixed scope
I used to quote fixed prices for loosely defined work because it felt more "professional" than hourly billing. That backfired more than once — a small, reasonable-sounding addition mid-project would quietly double the actual effort while the price stayed the same. Now fixed pricing only happens once scope is genuinely locked; anything with real ambiguity gets priced differently, usually in phases with a defined deliverable per phase.
Clients don't want status updates — they want confidence
Early on I under-communicated during heads-down build weeks, assuming silence read as "working hard." It reads as "something might be wrong." A short weekly update — what shipped, what's next, anything blocking — costs almost nothing to send and does more for a client relationship than any amount of extra polish on the actual deliverable.
| Old approach | What replaced it |
|---|---|
| Loose scope, fixed price | Locked scope before quoting a fixed price; phased pricing otherwise |
| Silent progress, big reveal | Short structured updates on a fixed cadence |
| Verbal agreement on changes | Every change request confirmed in writing before starting |
| Accepting every inbound lead | A short discovery call before quoting, to filter for fit |
Saying no to a bad-fit project is a skill
Not every inbound inquiry is worth taking, and learning to recognize the signs early — vague goals, unwillingness to commit to a scope, price sensitivity paired with high expectations — saved me from several projects that would have cost more in stress than they paid in revenue. A short discovery call before quoting anything has been the single highest-leverage addition to my process.
Technical excellence isn't the differentiator you think it is
Most freelance clients can't evaluate code quality directly — they evaluate communication, reliability, and whether the thing works the way they expected. That doesn't mean code quality doesn't matter; it matters enormously for how the project ages and how easy it is to extend later. But if a client is choosing between developers, the deciding factor is almost always trust built through clear communication, not a GitHub profile.
The invoice conversation should happen before the project, not after
Payment terms, milestones, and what happens if a client goes quiet mid-project all need to be settled before work starts, in writing, even when it feels unnecessary for a client who seems clearly trustworthy. It's not about distrust — it's that clear terms prevent an awkward conversation from ever needing to happen.
None of this is complicated. It's just the kind of thing you only really learn by getting it wrong once, at your own expense, on a real project.