How we scope software projects honestly
Every failed project we've ever heard about shares the same root cause: not bad engineering, but a scope that nobody wrote down properly. Across the projects we've shipped, we've landed on a scoping process that keeps both sides honest.
Start with the outcome, not the feature list
When a client says 'we need a dashboard', they don't want a dashboard — they want to know which of their numbers are slipping this week. So we start every project by asking what decision the product has to help someone make.
Only after we understand the outcome do we write down the features. That order is what separates a project that gets built from one that gets built twice.
Write down the assumptions
A fixed quote is only honest if the assumptions behind it are visible. Our proposals list every assumption in plain language — how many user roles, which integrations, what data volumes — so when something changes, it's a change, not a surprise.
This also protects us. When a client asks for 'just a small extra screen' at week eight, we can point to the scope and give an honest estimate of what it really costs.
Build in a discovery sprint
For anything more than a landing page, we recommend a short paid discovery phase before we quote a fixed price. It costs a fraction of a full build, and it turns 'a vague product idea' into 'a clear plan with a realistic budget'.
Nine times out of ten, the fixed quote that follows the discovery phase is lower than the one we'd have given on day one. We know our blind spots; that's how we price around them.
Written by the Sadhna Infosys team.
Next article: Choosing the right stack for your 2026 product