Software development & system architecture
Develop custom software. Connect existing systems. From requirements and architecture to implementation, with Michael Tilke as your direct partner. AI where it makes the solution better.
Consider the whole. Build the details.
01 / What systemnomics builds
A direct development partner for projects that connect business, processes and technology. The task determines the scope, from a focused component to a complete application.
Web applications, internal tools and digital workflows where standard software misses a critical requirement. With a suitable data model, understandable logic and interfaces designed for the work.
Output: An implemented application with agreed acceptance criteria.
Connect existing applications through suitable interfaces. Address data formats, access rights, synchronisation and error handling explicitly.
Output: Defined data flows and integrations that can be tested.
Add language and document processing, search or assistance where the additional value can be justified. Give AI a bounded task, verifiable outputs and a defined response to uncertainty.
Output: A focused AI capability within the appropriate workflow.
Understand existing code, data and dependencies. Address specific bottlenecks and add capabilities without turning every improvement into a complete rebuild.
Output: A justified change scope, implementation and handover.
02 / The system behind the interface
The technical solution follows from requirements and constraints. These four layers are considered together before individual choices become embedded in code.
Users, workflows, exceptions and acceptance criteria. What does the system need to support reliably?
Data models, systems of record, data quality, access rights and exchange formats. Where does information come from, and who can change it?
User interfaces, business rules, processing and AI where appropriate. What is deterministic, what is probabilistic, and where is approval required?
Deployment, configuration, logging, error handling and maintenance. How will the solution remain understandable and manageable in everyday use?
From a problem to an operable system.
03 / A closer look at implementation
Four conceptual examples. They illustrate possible architecture decisions and checks, rather than completed client projects or promised integrations.
Messages and attachments arrive unstructured, while the receiving system expects defined fields and clear ownership.
A defined mailbox or form, with access to an agreed target system.
One possible implementation
Map free text to a defined schema and flag missing or conflicting details.
Validate fields, check assignments, detect duplicates and make repeated write attempts safe without creating a second case.
Review uncertain assignments and critical information before transfer.
A validated record is transferred through an interface; failed transfers remain traceable.
Extraction quality, correct assignment, duplicate processing and recovery after failure.
A mobile submission needs to become a complete report without inventing details or passing on unreviewed information.
A voice note, a job identifier and available job data.
One possible implementation
Transcribe the note and produce a structured draft, keeping uncertainty visible.
Validate the report format and required information. Separate drafts from approved versions and attribute changes to a user.
The responsible person corrects and confirms the report before export or transfer.
A reviewed report is attached to the correct job and produced in an agreed format.
Transcription errors, missing details, correction effort and correct job assignment.
Information is scattered. A summary alone does not establish what is supported, current or relevant.
Approved public sources and, where authorised, internal data.
One possible implementation
Summarise material and suggest leads for a specific research question.
Retain source references, timestamps and access rights. Separate facts from hypotheses and store results for retrieval.
Review relevance and supported claims. Decide explicitly on outreach or further use.
A searchable dossier with traceable evidence and no automatic messaging.
Source coverage, supported claims, freshness, access boundaries and search quality.
Review and approval happen across scattered files and messages. Status and decision grounds are difficult to trace.
Documents and available purchase order, master and permission data.
One possible implementation
Extract fields from inconsistent documents where needed; process structured data directly.
Validate data, define states and roles, log decisions and control writes to external systems.
Assess discrepancies and provide the agreed operational or financial approval.
A traceable review and approval workflow with clear ownership of unresolved cases.
Invalid state transitions, permissions, missing evidence and behaviour during partial failures.
04 / From requirements to implementation
The approach adapts to the project’s size and risk. Decisions stay explicit, and each next step has a clear purpose.
Review use, existing systems, data and constraints. Record the objective, scope, open questions and acceptance criteria.
Design the data model, components, interfaces and responsibilities. Test critical assumptions with a small technical experiment where needed.
Implement in steps that can be reviewed. Test behaviour, integrations, permissions and relevant failure cases against the requirements.
Prepare deployment and integration into the intended environment. Clarify configuration, documentation, ownership and ongoing maintenance.
A technical experiment is not yet a production system. Moving into production requires passed checks, clear ownership and explicit approval.
MICHAEL TILKESoftware development & system architecture05 / Your direct partner
Michael Tilke combines experience in service and aftermarket leadership at BSH, Franke Coffee Systems and Melitta Professional with process design and hands-on software development. At systemnomics, he brings requirements, system architecture and implementation together as a direct external partner for your project.
I want to understand how the whole needs to work before deciding how to build its individual parts.
Michael on LinkedIn06 / Before we talk
Custom applications, internal tools, integrations and focused extensions to existing systems. The right solution and scope follow from your requirements and the technical environment already in place.
Both are connected: requirements and architecture are clarified far enough to turn into working software. An engagement can also cover a clearly bounded development or integration task. Deliverables and handover are agreed in advance.
No. Existing software and established components are part of the assessment. A rebuild needs a reason, just as AI does. Suitability, effort, risks and future maintainability guide the decision.
After an initial assessment, scope, acceptance criteria and fees are agreed. The agreement also needs to cover source code and usage rights, third-party services, data processing, deployment and maintenance responsibilities. Ongoing operation is not an implicit extra.
Through available APIs, suitable interfaces or controlled data imports. Before implementation, we review data models, permissions and technical constraints. Workflow automation also covers errors, approvals and traceable logs; feasible connections depend on the specific system.
07 / Your project
Describe the task, the existing systems and the result you need. A concrete situation is a good starting point; a finished technical specification is not required.
hello@systemnomics.comYour entries stay in this browser. Copying and downloading happen locally. “Prepare an email” opens your email application; you decide whether to send it. Please do not enter confidential or personal data.
