Software that moves your work forward.

If the goal and the solution approach are still open, start with software consulting and architecture. For an existing process, choose development or portals and apps; for a problematic legacy system, choose modernization. Interfaces, testing, DevOps and maintenance can be ordered on their own or combined with a development project.

Yes. A scoped first work package can examine requirements, code, architecture or operations. It ends with documented findings, open risks and a proposal for the next steps. The subsequent implementation is a separate decision.

We can take on defined work packages or collaborate with your business and development teams. Responsibilities for architecture, business decisions, reviews and approvals are agreed in advance. Shared repositories, documentation and knowledge transfer are part of the agreed collaboration.

The target environment can be your data center, a suitable cloud or a combination of both. Data locations, external services and operational responsibility are reviewed before the architecture decision. Choosing a region alone does not answer every question about data flows and access rights.

We define results and acceptance for each work package. Effort drivers such as interfaces, data quality and availability requirements are named early. Where requirements are still open, smaller stages with verifiable results help; changes are assessed for their impact on scope and schedule.

The scope of delivery is defined in the proposal and can include source code, build configuration, tests, and architecture and operations documentation. Usage rights, licenses for third-party components, access and briefing are explicitly agreed. This makes clear how your team can take the application forward.

When business units need new features but IT must first clarify costs, dependencies and risks, we create a shared basis for decisions.

Requirements workshops with the business unit and IT Comparison of standard software, customization and in-house development Analysis of data flows, interfaces and operating requirements Architecture concept and technical feasibility review

Requirements and a prioritized backlog Architecture and data flow overview Decision paper with options and effort drivers

Existing process descriptions and system overview Access to business owners and IT architecture Budget range, target dates and known constraints

A business unit wants its own order platform. Before development, we compare extending the existing ERP system with adding a complementary portal. A prototype tests the critical ERP connection; the client then decides on the scoped first expansion stage.

Process model Architecture decisions Technical prototype

A list of desired features does not yet explain which problem is meant to be solved. That is why we go through the actual workflow with the business unit, IT and future users: who starts a case, what decision follows, what data is missing and where rework happens today? From these conversations, we develop prioritized use cases, roles and measurable acceptance criteria. Exceptions, deputizing arrangements and error cases are part of this as well. The result is a workable backlog with clear boundaries. Business decisions remain with you; we explicitly document technical assumptions and open questions. This shows which features are needed for the first production use and which extensions can follow later.

Not every requirement justifies custom development. We compare suitable solution paths based on process coverage, integration capability, ongoing costs and the option to switch later. For standard software, we also consider extension points, export options and vendor lock-in. In-house development becomes worthwhile where special processes or product features create a distinct benefit. A decision paper shows options with prerequisites and consequences. We separate one-time implementation effort from operations, licenses and further development. Unknown interfaces are treated as uncertainty and, if needed, examined through a limited technical prototype.

We plan system boundaries, data ownership, interfaces and access paths together. A modular structure does not automatically mean microservices: a well-structured monolith can be the better choice for a small team. Availability, expected load, recovery and the capabilities of your operations organization determine the complexity. We record architecture decisions with their rationale and the alternatives that were discarded. For risky assumptions, we agree on evidence, for example an interface integration or a load test. This results in an actionable target architecture, prioritized risks and a proposal for the next work packages.