I quoted a "straightforward build." It wasn't.
This is something most freelancers go through, especially in the early days. A project comes in. The core tool is familiar, maybe Make.com, maybe n8n, maybe something else. But the client's stack includes a platform they've never touched. Poor docs, barely any community support. They take it on anyway because the money is there and they want to prove they can deliver. And the problems that follow are sneaky, because they don't look like mistakes at first. They look like hustle. → Discovery risk. They didn't know what they didn't know. The tool behaves differently than expected, edge cases surface mid-build, and they're making changes on the fly. This isn't the client moving the goalposts. This is the freelancer underestimating complexity because the tool was unfamiliar. But from the outside, it looks like poor planning. → Pricing mismatch. They quoted it as a straightforward build because they're already an expert in the main automation tool. But the unfamiliar pieces eat up hours that were never accounted for. Now they're either eating the cost quietly or having an uncomfortable renegotiation conversation that chips away at trust. → Bleeding timeline. They're learning as they go. Delivery slips. The client starts checking in more often. Confidence drops. And the worst part is they can't explain why it's taking long without admitting they're learning on the client's dime. → Opportunity cost. This is the one nobody talks about. While they're spending weeks buried in a poorly documented platform for one client, they could have delivered two or three projects confidently in their comfort zone. They didn't just underprice one project. They gave up the revenue from the projects they didn't take. Now, there's a real counterargument. Early on, taking unfamiliar-stack projects IS how freelancers build range. Getting paid to learn has real value. But this strategy has diminishing returns. At some point, the learning premium stops justifying the delivery risk.