Guide
How we scope a software project.
What happens in discovery, what you walk away with, what moves an estimate up or down, and how change is handled once work is underway.
- Scope first
- Written plan
- Terms tailored per client
Why we scope first
You cannot price what nobody has defined.
A number given before anyone understands the users, the data and the systems involved is a guess, and guesses turn into disputes later. So every engagement starts by agreeing what is being built, why, and what is deliberately left out.
That is also why we do not publish prices. Two projects with the same name can differ enormously once integrations, data, security and support are on the table.
Discovery
What happens in discovery.
Goals and success measures
What has to be true for this project to be worth doing, and how we will know it worked.
Users and workflows
Who uses the system, what they do today, and where time or quality is being lost.
Data and integrations
The systems involved, the data that moves between them, and what is reliable.
Constraints
Security, compliance, hosting, budget range and the dates that genuinely matter to you.
Options and a recommendation
Approaches considered, the one we recommend, and why.
What you receive
What you walk away with.
A written scope: what is in, what is out, and the assumptions behind it
An architecture outline and the main technical decisions
A delivery plan in milestones, with the first release defined
Known risks and how each one will be handled
The recommended engagement model and commercial proposal
What moves an estimate
The factors that change the size of a project.
Integrations
Every system the project must read from or write to adds design, testing and failure handling.
Data
Migrating, cleaning or reconciling existing data is often larger than it looks.
Security and compliance
Regulated data, audit trails and access models add design and review work.
Users and roles
More user types and permissions mean more flows to design and test.
Platforms
Web only, mobile only, or both, and how many devices and languages.
Support after launch
Whether the system is handed over or run and improved by us as a managed service.
Change
How change is handled once work is underway.
Change is normal and usually a good sign: it means people are using what has been built. We assess each change for its effect on scope, risk and the plan, agree it with you in writing, and only then build it. Nothing grows quietly.
Small changes are often absorbed by re-prioritizing what is already planned. Larger ones are scoped like any other piece of work.
Questions
Common scoping questions.
Why don't you publish prices?
Because scope drives cost, and no two projects share the same integrations, data, security needs and support. A published number would be wrong for most buyers.
Can we get a rough idea before discovery?
Yes. Our proposal generator drafts an indicative proposal from a short description of your project, and a first call can narrow it further.
What engagement models do you offer?
Fixed scope delivery, dedicated teams, and managed services with agreed service levels. We recommend one based on how defined the work is and how urgent it is.
How do you report progress once work starts?
Milestones, weekly status updates, risk tracking and written decisions, so you always know what is done and what is next.
Why are commercial terms tailored per client?
Because they follow the scope, the engagement model and the support you want after launch, which are different for every client.
Start with a discovery call.
Tell us what you want to build and why. We will tell you what we would need to know to scope it properly.