Scope planner for custom software and customer portals

Define your first software release with users, roles, migration and acceptance criteria. Download a scope for a focused project discussion.

A list of screens is not yet a bounded software assignment. This planner records the work the first release should support, who uses the result and which requests are deferred. It gives you a draft to discuss with users and a developer.

Start with one complete user operation: for example, a customer submits an enquiry and later sees the correct status, or an employee reviews a schedule. Describe the exceptions around that operation. A concrete starting point makes an existing product easier to compare with custom development.

Prepare your plan

Your answers stay in this page. Download the draft to keep it; closing or resetting the page clears your input.

First useful outcome

Describe what one user should be able to complete with the first version.

Users and decision maker

Who uses the result and who decides whether it is correct?

Inside and outside the first release

Include at least one request deliberately deferred.

Proposed approach

A choice remains provisional until the main assumptions have been investigated.

User audience

Internal software can also require role or team boundaries.

Roles and record boundaries agreed?

Define who may view and change a particular request, attachment or status.

Migrate existing data?

Distinguish new input from historical data that needs to be moved.

Acceptance criteria and exceptions

Which situations should succeed, stop or go to a person?

Define the outcome before listing features

Describe how somebody knows that the task is complete. Storing an enquiry does not necessarily mean accepting it. An employee may need to review its content, or another system may need to confirm capacity. These distinctions determine the statuses, information and follow-up operations required.

Record what the first release excludes as well. A portal for new enquiries does not immediately need historical files, invoicing and every exception in the existing process. Deferral still requires a workable route for excluded cases and a clear explanation of that route to users.

Treat access and migration as separate decisions

Illustrative example: a maintenance company wants customers to follow their own enquiries and attachments. Its first release supports one contact per customer organisation. Multiple branches, shared accounts and representation of other organisations need separate investigation. The scope includes a test in which customer A attempts to open customer B’s enquiry.

Moving historical information is a distinct work package. Record which data is needed, how it can be exported and who decides whether a trial import is correct. An integration for new changes does not automatically repair historical duplicates or unclear file relationships. Keep an unknown migration scope visible rather than silently including it in the first development phase.

Compare proposals using acceptance criteria

A useful acceptance criterion describes a situation, its expected result and what happens when something differs. Include normal input, missing information, insufficient access and a temporarily unavailable integration. Agree who assesses the examples and which topics can wait for another release.

Download the draft and discuss open questions before committing to a fixed scope or schedule. Add technical findings, dependencies and access and maintenance arrangements after investigation. This tool does not produce a quotation; it helps compare proposals built around the same operation and boundaries.

Understand the decisions behind your plan

Custom software & portals ↗

01 / Custom software & portals

Scope planner for custom software and customer portals

Prepare your plan

Define the outcome before listing features

Treat access and migration as separate decisions

Compare proposals using acceptance criteria

Understand the decisions behind your plan

Standard software or a custom application: compare the work that needs doing

Define custom software scope: turn a wish list into a usable first release

What does custom software cost? Compare scope, uncertainty and operation

Customer portal roles and permissions: who may use which record?

Customer portal statuses: explain what happened and what still needs doing

Import data into new software: turn an export into reviewed records

Accept custom software: assess complete tasks and agreed boundaries

Deliver new software: arrange code, accounts, data and future development