Development & Implementation

From specification to integration: OTOKO® develops applications and connects them with your existing systems and business processes.

Business applications, digital products or internal tools: we develop software for processes that cannot be meaningfully mapped with existing systems.

Requirements analysis with the business unit, threat model and target architecture based on the C4 model Domain model, data model and interface contracts before the first line of code Development in short iterations with code reviews and acceptance by the business unit Secure development under OWASP ASVS, checked dependencies and signed builds Handover with source code, architecture documentation and operations manual

Working application with source code and build pipeline Architecture documentation with threat model Operations manual with runbooks and emergency plan

Examples of today’s workflows and exceptions People responsible for business decisions Existing systems, data sources and operating requirements

Maintenance planning has so far been managed in spreadsheets. A business application brings together assets, appointments, responsibilities and approvals. The first expansion stage covers one site; further sites follow only after the business side has checked the process.

.NET C# Go Rust TypeScript PostgreSQL

The starting point is the workflow for which the investment should pay off. We model terms, states and business rules together with the people who will later work with them. An approval, for example, is not just a button: deputizing arrangements, permissions, deadlines and the reversal of a decision must all fit together. These rules become part of the data model and the tests. The first version focuses on one complete, usable process. We add further features based on feedback from actual use. This creates a product with verifiable benefit rather than a large collection of unfinished screens.

For the backend, user interface and data storage, we choose technologies based on your existing system landscape and expected future development. Existing skills, interfaces and operating requirements weigh more heavily here than a short-term technology trend. The current offering includes .NET, Go and TypeScript, among others; system-level components are assessed separately. We define module boundaries and responsibilities so that changes stay traceable. Credentials do not belong in source code, and business rules do not belong solely in the user interface. Reviews, automated checks and versioned database changes accompany the implementation from the start.

Every iteration shows usable features with known limitations. Business acceptance and technical release are considered separately: a correctly calculated order can be functionally right while load behavior or error handling is not yet ready for production. Together we define which evidence is required for each expansion step. The agreed scope of delivery includes source code, reproducible builds and documentation. For go-live, we clarify data migration, training, responsibilities and how incidents are handled. Usage rights, third-party components and later maintenance are settled before the handover.

An application must also work correctly when several people change the same stock at the same time. Two reservations must not allocate the same last item without anyone noticing. We therefore determine which changes must succeed together and which conflicts require business feedback. Database constraints, transactions and version checks can solve different parts of this task; the user interface alone cannot enforce these rules. Longer business processes, on the other hand, often do not fit into a single transaction. An order, an external payment service and a shipping approval each have their own failure states. We model the case with explicit states and permitted transitions. Repeated requests receive a suitable case identifier so that a connection failure does not automatically trigger a duplicate action. In the event of partial failures, a business-defined correction is needed, such as reversing an approval, instead of a blanket technical restart.

For SaaS products and internal platforms, we distinguish a user’s identity from their rights to a specific record. A logged-in employee must not automatically be able to read every invoice or every order. We check access in the backend at the level of organization, role and case. Exports, search indexes, background tasks and cached results must also respect these boundaries. Shared tables with a tenant identifier, separate database schemas or dedicated databases each bring different requirements for isolation, migration and recovery. We choose the model based on the separation required and your operations organization. Tests with multiple tenants specifically check for unauthorized access. An audit log documents business-relevant changes with suitable context; what data it contains and how long it remains available is explicitly defined.

The data structure follows the queries and business rules. We examine typical filters, sorting, evaluations and write operations before introducing additional storage technologies. Unbounded result lists, repeated individual queries and large data transfers can slow an application down even though the server appears barely loaded. Measurements with realistic data volumes show whether indexes, query changes, pagination or a different division of tasks help. Caching is a deliberate decision about timeliness: it must be defined when a stored result becomes invalid and which users are allowed to see it. Extensive calculations can run as background jobs, but then need progress indicators, restart capability and failure states. For extensions, we separate business rules from technical adapters. Automated tests and versioned database changes secure these boundaries so that a new channel or a different provider does not require changing every module.

Application landscape, requirements, risks Business unit, IT, information security, OTOKO® Software Architect Assessed initiatives, inventory, security and operations requirements

Architecture, technology, operating model Business unit, architecture, data protection, information security Target architecture, threat model, test strategy, operating model, milestones