A clear foundation for your internal tool, portal or web app

Internal tools, customer portals, dashboards and admin systems have different requirements. We therefore start with a specific task: who needs to enter, find or approve which information today? What happens before and afterwards? A list of desired features is not enough to define the scope of a useful first version.

A suitable starting point includes a known user group, a recurring problem and a responsible person. If the need is still unclear, we make that uncertainty visible. A technical outline should not pre-empt a decision about users or usage that the company has not yet made.

Useful inputs include the current process, redacted examples of forms or spreadsheets and a list of the systems involved. We also need user roles and an understanding of which data each role may view or change. Existing required fields and approval steps help distinguish business requirements from preferences about the interface.

We record which interfaces are known, which assumptions still need checking and who can provide answers. An integration is not treated as feasible merely because two tools use a similar term for their data. Test access, permissions and technical limitations need their own evaluation.

The result brings business requirements and technical considerations together. It defines a focused first scope and puts later requests into context. Unresolved points remain identifiable. This allows a development discussion based on documented decisions rather than hiding different expectations inside a general idea of an app.

• The problem, user group and specific usage situations
• Prioritised requirements and boundaries for the first version
• A user journey with roles, inputs and approval steps
• A technical implementation outline and relevant dependencies
• Open questions, assumptions and a reasoned next step

We walk through the proposed journey using a concrete task. For an internal approval tool, one person might enter a request, another review it and a third view the status. This reveals which information is needed at each stage and where questions or corrections must be possible.

Exceptions also belong in the outline: an incomplete record, a rejected request or an interrupted step. This review describes intended future behaviour. It does not prove that an application has already been developed or tested in production; an executable prototype is included only through a separate agreement.

The implementation outline considers data sources, responsibilities, access and the existing technical environment. We distinguish decisions needed for the first scope from questions that require closer investigation before a production rollout. AI is a possible component when it suits the task; it is not a prerequisite for a web app.

For this fictional approval tool, we ask: which required field is missing, and who completes it? Who may approve or reject, and what happens next? What appears after an interruption? The outline describes these rules; implementation and a prototype remain separate.

You assess whether the proposed scope addresses your specific problem and whether the identified dependencies are acceptable. Documented open questions show which information is still missing before development. Implementation can then be scoped and offered separately. Data migration, production integrations and ongoing operation are separate decisions.

For the initial assessment, describe the intended user group, the current process and the most important task for your app. Daniel Djogic discusses the starting point directly with you. A description in the enquiry form is sufficient; confidential documents and credentials are not required at this stage.