Choosing a partner
How should you scope a first software project?
Direct answer
Scope a first project as one completed task for one kind of user, plus an explicit list of what this version will not do. Include the data that must move and the other systems that must be touched, because those are the scope, not footnotes. A specification can be the result of that conversation; it does not have to exist before the conversation starts.
Name the person and the finished task
“A portal” is not a scope. “A client can see the documents still missing on this year's engagement and upload against each one” is a scope. The second sentence has a person, a task, and a way to know it worked. If you cannot write that sentence, you are not ready to compare quotes. You are ready to have a discovery conversation.
One task is allowed to be the whole first version. The second task goes on a list. Firms worry this sounds small. Small and finished is how the second task gets a calm budget. Large and vague is how the first task is still being discussed at month four.
Write the exclusions in the same document as the features
Exclusions are not pessimism. They are how you stop a reasonable side request from becoming the project. No billing, no mobile app, no migration of closed years, no public booking until the desk trusts the list: each of those is a decision that keeps the date honest.
Put them where the features are, not in an appendix nobody reads. A vendor who will not write exclusions is reserving the right to treat every new idea as either a change order or a reason the date moved. You want that conversation now.
Data and integrations are the scope
“We'll export it later” is a scope item pretending not to be one. Say which records move, from where, who is responsible for cleaning them, and what happens to the records that do not fit. Say which external product must be read or updated, and what you will do if it has no interface.
Permissions belong here too. If a partner, a staff member and a client see different things, that is three views, and it is easier to name them at the start than to discover them as bugs.
What the firm has to supply
Sample records, a person who can answer “what do we do when this happens”, and a decision-maker who will actually decide. Software projects stall in the gaps between those three. Putting them in the scope makes the firm's time visible, which is fair, because that time is part of the schedule.
Sunbeam would rather write this down with you than receive a long document that has not survived contact with the people who do the work. The proposal comes after. The guide on cost explains why the number is meaningless before this page exists.