Why We Quote by Scope, Not by Man-Days

In our first years we quoted like most software teams: headcount times days times a rate. It was easy to explain and easy to compare, but the longer we did it, the clearer it became that it solved nothing that actually mattered.

Three side effects of man-day pricing

First, it pulls attention to hours instead of solutions. Nobody asks whether the same requirement could be met in a simpler way.

Second, the team learns to fill the days. Hours are both the unit of billing and the proof of effort, so finishing early becomes awkward to explain.

How we quote now

We start with a scope workshop, splitting requirements into must-have, later and explicitly out of scope, then commit to a price range. Once the scope is written down, the number holds up on its own.

Every quote lists its assumptions: who provides third-party APIs, who cleans the data, how acceptance is judged. If an assumption changes, we revisit the price.

This approach cost us a few deals early on, but it filtered for clients willing to describe their problem honestly. In the long run that is worth more than winning on the lowest number.