How to Scope a Custom Software Project Before You Build It

Scope is a description of behaviour, not a list of screens

Most briefs arrive as a list of nouns: a dashboard, a login, a reports page, a mobile app. Nouns are cheap to write and expensive to interpret. "A reports page" could be four fixed tables or a query builder with saved views and scheduled exports — two projects with nothing in common but the word.

Write verbs instead. Describe what a specific person needs to accomplish, in what circumstances, and how you will know it worked. "A branch manager closes the day's till, and any discrepancy over a threshold is escalated to finance before the branch can close" is a sentence any engineer can estimate. "A cash management module" is not.

The five things that actually drive effort

• Integrations. Every external system you must talk to — accounting, e-invoicing, payment gateway, WhatsApp, a supplier's portal — is a separate contract with its own failure modes. Integrations, not screens, are usually the largest share of a build.
• Roles and permissions. One user type is straightforward. Five user types with overlapping visibility rules multiply the paths that must be designed, built and tested.
• Data migration. Moving history out of spreadsheets and a legacy system is its own project. The cleaning is the work; the import script is an afternoon.
• Offline and unreliable networks. A tool used in a warehouse or a delivery van has to behave when connectivity drops. Decide this early — retrofitting it is close to a rewrite.
• Bilingual and RTL. Full Arabic parity is straightforward when designed in from the start and painful when added later, because it touches layout, typography, sorting, dates, numerals and every piece of copy.

Separate the must-run from the nice-to-have, on paper

Ask one question of every requirement: if this were missing on launch day, would the business stop? If the honest answer is no, it belongs in a second list. Almost every brief we receive contains a first version that is three times larger than the version that would have been enough to start learning from real users.

What a good discovery phase produces

A discovery phase exists to convert your intent into something buildable and comparable. When it is done well you should be holding artefacts you could hand to a different team entirely, which is exactly why it is worth doing before you commit to a builder.

• A process map of how the work happens today, with the specific points where it breaks.
• User stories with acceptance criteria — the verbs, written so that "done" is not a matter of opinion.
• An integration inventory: every external system, what data crosses, in which direction, and who owns the credentials.
• A data model and a migration plan for the history that has to come along.
• A release sequence: what ships first, what it proves, and what the second release depends on.

Reading a proposal critically

• Does it restate your problem in its own words? A proposal that only echoes your list has not understood anything yet.
• Does it name what is excluded? Explicit exclusions are a sign of experience, not of a team hedging.
• Who owns the code and the data? Establish this in writing before anything is built, not at handover.
• What happens after launch? Software that nobody maintains degrades. Ask how changes are handled once the project ends.
• How is quality demonstrated? Ask what is tested automatically and what is checked by hand — see how we approach quality assurance.

A precise scope is worth more than a persuasive proposal. It makes competing bids comparable, it makes disagreements surface in a meeting rather than in month four, and it is the single largest thing under your control that determines how the project goes.