How to scope a custom software project

A useful software brief describes a business problem before it describes a product. “We need an app” is a starting point. It does not yet explain who will use the system, what they need to accomplish or how the business will know that the investment has worked.

For a company comparing software partners, a clear brief makes proposals easier to evaluate. It also exposes decisions that would otherwise surface late in development, when changing them is more expensive.

Start with one workflow

Choose a concrete operation: processing a customer request, booking a service, approving a purchase or collecting field data. Describe how that operation works today. Record the people involved, the information they exchange and the points where work stops or is repeated.

Then describe the desired result. A measurable objective might be reducing the time needed to prepare a quotation, avoiding duplicate records or giving a customer a reliable view of an order. A list of features without an operational objective can produce a working interface that solves the wrong problem.

Name the users and their permissions

An administrator, an employee, an external partner and a customer usually need different views of the same operation. Define what each role can read, create, change, approve and export.

Include uncomfortable cases. Who can correct an incorrect record? What happens when an employee leaves? Can a customer access another customer's information by changing a link? These questions belong in the specification, alongside the main workflow.

Describe the data before choosing integrations

List the information the application needs and where it comes from. Separate information entered by users from records imported from another system. Identify which system is authoritative when two sources disagree.

For every proposed integration, record the provider, access method, ownership of the account and the expected behaviour when the service is unavailable. “Connect to our accounting system” is incomplete until the team knows which records move, in which direction and how failures are handled.

Write acceptance criteria people can verify

Replace subjective requirements with observable examples. “The dashboard should be fast” is hard to approve. “An authorised operator can search an order by reference, open its history and export the result” is a testable workflow. Performance requirements also need a defined environment, data volume and target rather than an unsupported adjective.

A short acceptance table helps:

Workflow	Expected result	Evidence
Customer inquiry	A valid request is stored once and receives a reference	Matching record in the management panel
Content publication	A draft stays private until publication	Public page shows only the published revision
User access	A user sees only permitted records	Tests across roles and direct links
Backup recovery	A saved copy can be restored	A separate environment opens the recovered data

Separate the first release from later ideas

Identify the smallest useful release that supports a complete operation. A smaller release should still handle validation, errors, permissions and the information users need to finish their work.

Keep later ideas in a separate backlog. Label assumptions and dependencies explicitly. An optional integration that requires an unapproved provider account should not silently become a condition for launching the first release.

Plan who operates the system

Development is only part of the responsibility. Decide who owns hosting accounts, domains, repository access, deployment credentials and data exports. Agree how incidents are reported and how changes are released.

Backup planning should cover recovery, not just file creation. Decide what must be preserved, how often it is copied, where the copy is stored and how recovery will be checked. These decisions should reflect the consequences of losing or interrupting the business workflow.

What to send with an initial inquiry

A company can start with a concise brief: the operation to improve, the people who use it, examples of existing records, required integrations, timing constraints and a definition of a successful first release. Sensitive production data is not necessary for an initial discussion; anonymised examples are usually more appropriate.

Vatesco’s software research is at an early stage. This article is an educational guide.

Vatesco’s software research is at an early stage. This article is an educational guide.