Users and core function
Define the first usable function and its acceptance criteria before adding further requests.
Build around a real workflow
Web app development
Web app development for a defined workflow: a customer portal, internal tool or configurator. We agree the users, core function and acceptance criteria before planning the build.
A web app makes sense when people work with data to complete a task. Start with the workflow: who enters information, who can access it and what needs to happen next?
Describe the current process and its main bottleneck. We use that to scope an initial usable function. A website project is usually the better starting point for presenting services and collecting inquiries.
Where it fits
Which job should the web app do?
Customer portal
Customers see agreed documents and status information, with defined roles and visibility.
Internal tool
A recurring workflow gets clear inputs, responsibilities and a usable overview.
Calculator or configurator
Visitors assess inputs or choose options, using rules and a handover process agreed together.
Agreed scope
Web app development: functions and scope
Screens and interaction
Build agreed screens, inputs, feedback states and mobile interactions.
Data and access roles
Define data sources, roles and allowed actions, then check them against concrete cases.
Required integrations
Assess existing systems and interfaces. Scope each integration, data flow and failure case.
Acceptance and handover
Document agreed test cases, operating guidance and ownership of ongoing work.
Planned extensions
Prioritize further functions by usefulness and effort, then quote them separately.
How we work
From the current workflow to a usable first version
Step 01
Review the workflow
Discuss users, data, the bottleneck and existing systems.
Step 02
Agree scope and acceptance
Define the core function, screens, roles and test cases; quote price and timing on that basis.
Step 03
Build and review together
Build the agreed function, check typical and failing workflows and prepare the handover.
Acceptance and operation belong in the project plan. We agree ownership of access, hosting, backups and future changes. Ongoing work and external services are scoped separately.
A project quote depends on functionality, data and integrations. A website entry price does not automatically apply to a custom application. You receive the agreed scope and price before implementation.
Questions before a web app project
The price depends on the core function, screens, data and integrations. We review the current workflow and define a first version. That gives us a basis for agreeing the project quote, timing and ongoing costs.
Yes. We scope a usable core function with defined acceptance criteria. Further functions are considered by need and effort, so it stays clear what the first version does and which extensions are outside the initial commission.
This offer focuses on browser-based applications. A native app published through app stores is a separate project with additional requirements. If you need that, we assess feasibility and the right approach separately.
We first assess available access, interfaces and the data needed. An integration only enters the quote once data flow, permissions, responsibilities and failure cases are defined.
We define which users may view and change which data. Acceptance includes agreed typical workflows and failure cases. Additional checks, such as an external security assessment, are planned separately where needed.
Describe who will use the application, what is difficult today and the outcome needed. A sketch or anonymized example is a useful starting point, alongside existing systems, timing and an approximate budget.
Which workflow should get easier?
Describe the users, workflow and desired benefit. We discuss a useful first function and its scope.