How we scope a project before quoting
Most bad software projects were mispriced before a line was written. This is the process we use to avoid that, and why we would rather give you a range than a confident wrong number.
Nearly every software project that goes badly went badly at the quoting stage. Not during the build — before it, when everyone was being optimistic and nobody wanted to be the difficult one asking what "and reporting" meant.
We ask what happens today
Not what you want the system to do. What currently happens, step by step, including the spreadsheet, the WhatsApp group and the thing someone does manually every Friday. That last one is usually where the complexity is hiding.
We separate what the software must do from what it should do
Everything on a wish list feels essential when you write it. Very little of it survives the question "if this did not exist in version one, would you still use the system?"
We give you a range, not a number
A single figure this early is either padded or wrong. We give a range with the assumptions written next to it, so you can see which assumption is doing the heavy lifting — and challenge it.
Where something genuinely cannot be estimated yet, we say that too, and quote a short discovery phase rather than pretending. Discovery costs a fraction of building the wrong thing.
Try it without talking to anyone
Our free software review runs through a version of this on its own. Answer the questions, get an estimated range and a complexity read, and a reference number if you want to take it further. No call required unless you want one.
Prêt pour un site qui fait grandir votre entreprise ?
Des sites modernes avec une formule mensuelle simple — nous les créons, les hébergeons et les entretenons.
