Scoping a custom business platform: a requirements checklist

Scoping is the work of turning "we need a system for this" into a description precise enough that a developer can estimate it and you can check the result against it. It is the single biggest factor in whether a custom platform arrives on budget and does what you expected. This checklist is written for the manager who will brief the developers, not for the developers themselves.

A good scope answers three questions: who does what, with which data, and how will we know it works.

Step 1: describe the problem, not the software

Start with a paragraph about what happens today and why it hurts. For example: "Our property maintenance team receives work requests by phone, email and text. Jobs are tracked in a shared spreadsheet, technicians photograph completed work on personal phones, and invoices are built by hand from those photos. Jobs get lost, and invoicing takes two days each month." This tells a developer far more than a list of screens.

• What triggers the process, and what is its final output?
• Which tools are involved today (spreadsheets, shared drives, email, paper)?
• Where do delays, errors or duplicate entry happen?
• What would a clearly better month look like?

Step 2: list users, roles and permissions

Every platform is built around who signs in. List each role and what it may see and change. Keep the roles few; each one multiplies testing.

Also note how accounts are created and removed. Who invites a new client? What happens to a technician's access on their last day?

Step 3: walk through each workflow

For each core process, write the steps in order, naming the role at each step. Then add the exceptions, which is where most of the effort hides.

1. Client submits a request with photos through the portal.
2. Administrator reviews it, assigns a technician and sets a date.
3. Technician receives a notification, completes the job and uploads photos and notes.
4. Administrator approves the job; the system generates an invoice from a template.
5. Client receives the invoice and a link to the job record.

Exceptions to cover: the client cancels, the job needs a second visit, the technician cannot attend, the invoice is disputed. If an exception happens rarely, it may be fine to handle it manually and say so in the scope.

Step 4: define the data and documents

• The main records (clients, jobs, assets, invoices) and the fields each one needs.
• Which documents are uploaded, generated or both, and their typical size and volume.
• Existing data to import, its format and how clean it is.
• Retention: how long records and files must be kept, and who may delete them.
• Whether any data is sensitive, such as financial account details or health information, and needs extra protection.

If documents arrive as scans, note it. Reading them automatically with OCR is a separate piece of work with its own testing; our guide to OCR accuracy and workflow design explains what to expect.

Step 5: integrations, devices and non-functional needs

• Integrations: accounting, CRM, e-signature, calendar, storage. For each, note whether it must send data, receive data or both, and whether the vendor offers an API or only file exports.
• Devices: desktop only, phones in the field, or both. Whether offline work is required. Our article on web app, PWA or native app helps here.
• Security: sign-in method, password rules, two-factor authentication, audit history of who changed what.
• Hosting and backups: where the platform runs, how often it is backed up and who can restore it.
• Notifications: which events send an email or push message, and to whom.
• Reporting: the three or four reports you will actually open every week.

Step 6: set priorities and acceptance criteria

Sort every requirement into must-have for launch, should-have soon after, and later. A first version that covers the core workflow well is worth more than a complete system delivered months later. For each must-have, write one sentence that describes how you will test it, for example: "A technician can mark a job complete with three photos on a phone with weak signal."

Finally, write an out-of-scope list. Naming what the platform will not do in its first version prevents the most common source of disputes and cost overruns.

Common scoping mistakes

• Copying every feature of a large commercial product instead of describing your own process.
• Leaving out the person who does the work today from the requirements conversation.
• Assuming an integration is possible before checking the other system's API.
• No named owner on your side to answer questions and test during the build.

Turning the checklist into a quote

At heliostech.eu we use answers like these to write a scope listing roles, workflows, data, integrations and exclusions, and BIT LOGIC DEV S.R.L. confirms price, term and start date in writing before anything is billed.

Questions and answers