Workflow
Understand work and exceptions
We observe how work is actually completed. Roles, handovers, exceptions and measurable friction are documented before an interface is designed.
- Process discovery
- Non-goals
- Domain roles
Software that fits your workflow.
Your process should define the software, not the other way around.
We turn operational workflows into maintainable software and cover discovery, architecture, migration, secure delivery and ongoing operation. Reusable foundations shorten the start while domain logic, data and interaction fit your organisation.
Starting point identifiedYour process defines the product
01
Custom software and portals
02
Web and mobile use
03
Interfaces and data flows
04
Legacy modernisation
05
Workflow automation
06
Secure operation and transfer
Your starting point
Signs that the current setup no longer works
We start with the problem, its operational consequences and the people who will own the result.
01
The workflow lives in spreadsheets, email and people
Critical work depends on individual knowledge, manual transfers and exceptions that are only understood during day-to-day operation.
02
Standard software creates permanent workarounds
Teams maintain the same data more than once or build side lists because the actual workflow is not fully supported.
03
The legacy system blocks every change
Small improvements become expensive and risky because data models, interfaces, dependencies and ownership are no longer understood.
04
Nobody owns the outcome after the project
Development, hosting and domain teams point at each other while monitoring, recovery, updates and ongoing product decisions remain unresolved.
Technical coverage
From real work to secure operation.
We connect workflow discovery, architecture, development, security and operation. The result is not an isolated application, but an owned operational product.
Architecture
Design data, permissions and boundaries
Data models, tenants, roles, logs and system boundaries follow operating needs. The result can evolve without becoming arbitrary.
- Data model
- Permissions
- Audit log
Integration
Connect existing systems reliably
Interfaces cover more than the happy path. Retries, interruption, synchronisation, error handling and observable state are part of the design.
- API
- ERP and CRM
- Data flows
Security
Build protection in from the start
Threats, dependencies, secrets and approvals are considered early. Automated checks and documented decisions accompany every release.
- Secure by design
- Testing
- Supply chain
Delivery
Working slices instead of status slides
We deliver small, complete parts of the workflow. Domain users test realistic cases and make decisions using a running version.
- Vertical slice
- Preview
- Acceptance
Operation
Make adoption and evolution reliable
Monitoring, backups, recovery, updates and support are agreed before launch. Operating evidence feeds back into a controlled roadmap.
- Monitoring
- Recovery
- Roadmap
Modernisation in detail
From a legacy workflow to a working application.
A replacement is not successful when the new interface is complete. Data, exceptions, users and operations need a controlled transition from the old state to the new one.
Phase 1 Observe real work
Capture cases, handovers, waiting time and exceptions together with the people who will use the product.
Phase 2 Define the core and boundaries
Agree the smallest complete workflow, required data and explicit non-goals.
Phase 3 Build a working core
Deliver an end-to-end slice with permissions, logs and realistic test data.
Phase 4 Replace legacy safely
Validate data, secure interfaces and rehearse the transition with comparison and rollback.
Operation Operate with ownership
Enable users, monitor quality and prioritise the next changes using evidence from production.
Decision criteria
A production launch depends on more than completed features. Domain value, data, operations and transferability need to be viable together.
Business valueThe baseline and intended change can be measured
Data readinessSources, quality, migration and ownership are defined
Operational readinessPermissions, monitoring and recovery are demonstrable
TransferabilityCode, interfaces and decisions remain understandable
What you receive
- Workflow model with roles, exceptions and explicit non-goals
- Architecture for data, permissions, interfaces and operation
- Running versions delivered as domain-testable slices
- Automated tests and documented security decisions
- Validated migration plan with comparison and rollback
- Adoption, operating documentation and a prioritised roadmap
Market and decision
What is changing and what to decide first
We assess new practices by whether they improve domain value, risk, delivery or ongoing operation.
Development
Secure development becomes demonstrable
NIST and the German BSI treat secure software development as a complete lifecycle. Requirements, architecture, environments, components, tests and vulnerability response need to work together.
Development
The Cyber Resilience Act reaches operation
From 11 September 2026, affected manufacturers must report actively exploited vulnerabilities and severe incidents. Product inventory, ownership and response paths become operational necessities.
Development
Working slices replace the large acceptance day
A complete part of the workflow reveals domain risk earlier than a collection of disconnected screens. Reusable foundations shorten delivery without standardising the organisation's unique logic.
Primary sources · August 2026
Clarify before commissioning
- Describe the problem, baseline and desired outcome before individual screens
- Clarify domain roles, permissions and critical exceptions with real users
- Plan data quality, migration, parallel operation and rollback from the start
- Include security requirements and threat analysis in architecture and tests
- Include operation, recovery and ownership in the delivery scope
- Agree open formats, source access, documentation and transfer contractually
From problem to operation
A controlled path to a working product
- 01
Understand the workflow and outcome
We observe real work, capture exceptions, roles, data and measurable friction. This defines the intended result, explicit non-goals and the first useful scope.
- 02
Design architecture and transition
The data model, permissions, interfaces, migration, rollback and operating requirements are agreed before critical dependencies emerge.
- 03
Build in usable slices
We deliver coherent parts of the real workflow. Domain users validate realistic cases using a running version rather than waiting for a complete application.
- 04
Move data under control
Existing data is cleaned, mapped and migrated in rehearsals. Old and new systems run in parallel only as long as needed for a safe transition.
- 05
Adopt and operate with ownership
Training, monitoring, recovery, updates and documented ownership form part of launch. We can remain accountable for ongoing operation.
Outcome
What changes for your organisation
1
Fewer manual handovers
Data is captured, validated and processed where it originates. Duplicate maintenance and manual transfers are deliberately removed.
2
Early domain confidence
Running versions and realistic cases show whether the workflow, data and interface work together before the final release.
3
Security in the foundation
Permissions, logging, privacy, dependencies and recovery are treated as architecture decisions, not later additions.
4
Controlled dependency
Open data formats, documented interfaces, tests and a defined transfer path keep the product maintainable over time.
FAQ
Common questions about software development
Practical answers for an initial assessment.
When is custom software worth considering?
When an important, differentiating workflow only works through permanent workarounds, duplicate data entry or many manual steps in standard software.
Does a legacy system have to be switched off immediately?
No. A staged transition with data comparison, explicit interfaces and a rehearsed rollback is usually safer.
Do you also build mobile applications?
Yes. The choice between a responsive web application, a progressive web app and a native app depends on offline needs, device features, distribution and maintenance effort.
Can you connect our existing systems?
Yes. We assess available interfaces, data quality, permissions, failure conditions and synchronisation. If a direct integration is not reliable, we state that before implementation.
How do you prevent uncontrolled scope growth?
We first document goals and non-goals. We then deliver small, complete workflow slices and assess new requests transparently by value, risk and effort.
Who owns the code and data?
The client retains its data. Usage rights, source access, documentation, open formats and the transfer path are stated explicitly in the proposal.
Next step
Discuss your software initiative Turn your workflow into maintainable software
We assess the workflow, data, existing systems and operating requirements. You will understand the smallest useful scope and a controlled path to production.