After losing money on a web app project early in my freelancing career, I made a decision: I would never quote a project without first understanding it properly. That mistake cost me three weeks of unpaid work and a lot of frustration. Here's the framework I've used ever since.
The Discovery Call is Non-Negotiable
Before I write a single line of code, I get on a call. Not to sell — to listen. The discovery call is where you find out what the client actually wants, which is often different from what they think they want.
I ask four questions in every discovery call:
- What does success look like at the end? This forces them to articulate the outcome, not just the features.
- What does failure look like? This surfaces hidden fears and constraints.
- Who else is involved in decisions? A project with three stakeholders has a different risk profile than one with one.
- What's your timeline and why? "We need it by Friday" and "we're launching at an event in six weeks" are very different constraints.
Write a Requirements Document First
I don't start scoping until I've written a one-page requirements doc. This forces me to slow down and capture the agreed-upon scope in plain English — no technical jargon, just: what are we building, what does it do, and what does it not do.
I send this to the client before any quote. If they correct it, great — we've just saved ourselves a scope argument mid-project. If they approve it, even better — we have written agreement on what we're building.
Fixed vs. Hourly: Which One Protects You
Hourly billing protects you when the scope is unclear or changes frequently. Fixed-price billing protects you when the scope is well-defined and you trust your estimates.
Early on, I defaulted to hourly because it felt safer. But clients hate not knowing what they'll spend. I now use fixed-price for clearly scoped projects and hourly retainers for ongoing work or R&D-heavy projects where requirements will evolve.
The key to fixed-price work is being ruthlessly specific about what's included. Which brings me to the next point.
What's Out of Scope is as Important as What's In
Your quote should always include a "What's not included" section. I typically list things like:
- Third-party API integration beyond the listed services
- Design work beyond the provided mockups
- Performance optimization beyond standard best practices
- Post-launch bug fixes beyond 30 days
This isn't about being difficult — it's about being honest. Clients respect engineers who are clear about boundaries. Vague quotes lead to scope creep, which leads to resentment on both sides.
Revision Limits
I include a revision policy in every fixed-price contract: two rounds of feedback per major milestone, with additional revisions billed at my hourly rate. This single clause has saved more projects than anything else.
The first revision round catches genuine misunderstandings. The second catches preference changes. Everything after that is usually indecision — and charging for it nudges clients to make faster decisions.
The Kill Fee
I include a kill fee clause in every contract: if the client cancels after work has begun, they pay for work completed plus 20% of the remaining scope as a kill fee.
This protects you from the client who disappears after you've turned down other work to take theirs. It also self-selects for serious clients who have commitment. I've only had to invoke this clause twice in five years — but both times it covered weeks of lost income.
Putting It Together
A well-scoped project starts with a proper discovery call, gets written down in a requirements doc, and gets contracted with explicit scope boundaries and a kill fee. This framework doesn't prevent all problems — but it prevents most of the expensive ones.
The best clients I've worked with through MadakLabs have appreciated this process. It signals that you're professional, thorough, and thinking about their project seriously. That reputation compounds over time.