01
Application engineering
Backend services, data models, APIs and user interfaces built as one coherent system rather than disconnected parts.
01IT engineering company
KiS GmbHSystems built to keep working.
We design, build and maintain business technology: custom applications, web platforms, cloud infrastructure and the integrations that hold them together. Our work is aimed at organisations that need software to be dependable long after the first release.
Custom software engineering
Cloud and infrastructure work
Integration and automation
Infrastructure engineering — illustrative imagery
02 / Introduction
An engineering partner, not a supplier of screens
KiS GmbH works with organisations whose day-to-day operations depend on software. That usually means a mixture of things: an application that supports a core process, a set of internal tools, data that has to move between systems, and infrastructure that has to stay available while all of it changes.
We take responsibility for the technical side of that picture. That includes understanding the business process before writing code, choosing technology that the organisation can live with, and documenting decisions so the work remains understandable to people who join later.
Engagements vary in size. Some begin with a short piece of consulting work; others start with a defined build and continue into long-term maintenance. In every case the goal is the same: software that behaves predictably and can be changed safely.
03Core technology capabilities
A single technical team across the application lifecycle
02
Data and persistence
Relational and non-relational storage, schema design, migrations and reporting structures that reflect how the business actually works.
03
Infrastructure and delivery
Environments, build pipelines, deployment automation, monitoring and the operational routines that surround a running system.
04
Interfaces and integration
Service interfaces, message flows and connectors between internal applications and third-party platforms.
05
Automation
Scheduled and event-driven processing that removes repetitive manual steps from established workflows.
06
Technical advisory
Architecture reviews, technology selection and planning support for teams deciding what to build, buy or replace.
04Custom software development
Software shaped around the process it supports
Off-the-shelf products cover common needs well. Custom development becomes worthwhile when a process is specific enough that generic tooling forces the business to work around the software instead of with it.
We start from the operational detail — who does what, in what order, with which data — and turn it into a system with clear boundaries. Work is delivered incrementally so the shape of the product can be reviewed while it is still inexpensive to change. Code is written to be read: consistent structure, meaningful names, tests around the parts that carry risk.
05Web applications and platforms
Digital platforms people use every working day
Web applications are often the surface where a business meets its systems: customer portals, internal administration tools, dashboards, ordering and scheduling interfaces.
Interface work
Layouts, states and flows designed for repeated daily use rather than a first impression.
Application state
Predictable data loading, validation and error handling so the interface stays truthful.
Responsiveness
Layouts that hold up on small screens, large displays and varied input methods.
Performance
Attention to payload size, caching and rendering so screens stay usable under real conditions.
06 / Cloud infrastructure and modernization
Moving systems forward without stopping the business
Modernization is rarely a single migration. More often it is a sequence of controlled steps: describing the current environment, isolating the parts that can move first, and building the deployment and monitoring foundation before anything critical is relocated.
We work with cloud and hybrid environments, infrastructure defined as code, containerised workloads, environment separation and automated delivery pipelines. Cost, operational load and the skills available inside the organisation are treated as design constraints, not afterthoughts.
07Systems integration and workflow automation
Making separate systems behave like one
Most organisations run more software than they intended to. Integration work reduces the cost of that reality: data is exchanged deliberately, ownership of each record is defined, and failures are visible instead of silent.
Automation follows the same principle. Once a process is documented and stable, the repetitive parts — transfers, transformations, notifications, reconciliation — can run on a schedule or in response to events, with logging that makes it possible to check what happened.
Interfaces
REST and messaging interfaces with documented contracts and versioning.
Data mapping
Field-level mapping and transformation rules agreed with the people who own the data.
Error handling
Retries, dead-letter handling and alerts so nothing disappears quietly.
Observability
Logs and metrics that answer operational questions without guesswork.
08IT consulting and technology planning
Decisions made with the technical detail in view
Technology decisions are easier to defend when the trade-offs are written down. Consulting engagements produce exactly that: an assessment of the current situation, realistic options, and the consequences of each one.
- Review of existing applications, architecture and delivery practices
- Comparison of build, buy and modernization options for a specific need
- Technical scoping and sequencing ahead of a larger programme of work
- Support for internal teams during planning, estimation and hand-over
09Security-conscious engineering
Careful defaults, applied consistently
Security is treated as an engineering habit rather than a separate phase. We describe our practices plainly and make no claims about certifications, audits or regulatory status.
Least privilege
Access to systems, data and infrastructure is scoped to what a role actually requires.
Secret handling
Credentials and keys are kept out of source control and rotated when circumstances change.
Input and output discipline
Validation at boundaries, parameterised queries and careful encoding of anything rendered back to users.
Dependency awareness
Third-party libraries are kept current and reviewed when known issues are published.
Change control
Code review, traceable deployments and the ability to roll back a release.
Data minimisation
Collecting and retaining only the data a feature genuinely needs to function.
10 / Project workflow
Six stages, each with something reviewable at the end
01
Discovery
Understanding the process, the constraints and the people involved. We look at existing systems, data and pain points before proposing anything.
02
Planning
Scope, architecture, sequencing and the assumptions behind them, written down so they can be challenged.
03
Development
Incremental delivery in short cycles, with working software available for review as it takes shape.
04
Testing
Automated tests around critical logic, plus structured functional review of the behaviour users will rely on.
05
Deployment
Repeatable releases through defined environments, with configuration handled outside the code.
06
Maintenance
Monitoring, corrective work, dependency updates and planned improvement after the system is live.
11Engineering principles
What we optimise for
Maintainability
A system is finished only in the sense that it can be handed on. We favour clear structure, small components and documentation that explains why, not just what.
Reliability
Predictable behaviour under normal and unusual conditions: sensible timeouts, graceful degradation, and logging that supports diagnosis.
Accessibility
Semantic markup, keyboard operability, readable contrast and text that scales — considered while interfaces are being built, not retrofitted.
Usability
Interfaces that reflect the user's mental model of their work, with fewer steps and clearer feedback.
12Illustrative use cases
Examples of the problems this work addresses
The scenarios below are illustrative examples written to explain typical needs. They do not describe completed client projects.
Operations running on spreadsheets
A team coordinates work through shared files that no longer reflect reality. A small internal application with defined records, roles and history replaces the ambiguity.
Two systems that disagree
An ordering system and an accounting package hold conflicting versions of the same data. An integration defines which system owns each field and reconciles the rest on a schedule.
A legacy application nobody can change
An older application still works but is risky to modify. Behaviour is documented and covered by tests, then components are replaced one at a time.
Manual month-end processing
A recurring set of exports, transformations and checks consumes days of staff time. The steps are automated with logging and a clear failure path.
A customer-facing portal
Customers request status updates by email. A portal exposes the same information directly, with authentication and an audit trail.
Environments that differ
Deployments behave differently in test and production. Infrastructure is described as code so environments can be rebuilt consistently.
13Collaboration and communication
Fewer surprises, in both directions
Projects are shaped as much by communication as by code. We keep a written record of decisions, share progress at a regular rhythm, and raise problems early enough that there are still options.
A single point of contact
One person responsible for the conversation, with direct access to the engineers doing the work.
Visible progress
Regular demonstrations of working software instead of status percentages.
Written decisions
Choices and their reasoning recorded where the whole team can find them.
Honest estimates
Ranges and assumptions rather than single numbers presented as certainty.
14Frequently asked questions
What kinds of organisations do you work with?
Organisations that rely on software for internal operations or customer-facing services, across a range of sectors. The common factor is a need for systems that are maintained rather than replaced every few years.
Can you work alongside an internal IT team?
Yes. Engagements are often shared, with our engineers taking specific components or providing capacity while the internal team keeps ownership of the wider environment.
Do you take over existing systems?
We can. That usually begins with a review of the code, data and infrastructure, followed by documentation and a plan for stabilising the parts that carry the most risk.
How is a project scoped?
Through discovery. We look at the process, the existing systems and the constraints, then propose a scope with the assumptions stated explicitly so they can be revised as understanding improves.
Which technologies do you use?
We choose based on the problem, the existing environment and what the organisation can maintain. We avoid introducing technology that leaves a team unable to support its own system.
What happens after launch?
Maintenance covers monitoring, corrective work, dependency updates and planned improvements. The scope of ongoing support is agreed in advance rather than assumed.
How do you handle documentation?
Architecture notes, decision records, setup instructions and operational runbooks are produced as part of the work, not as a separate deliverable at the end.
How do enquiries start?
By email to [email protected]. A short description of the situation and what you would like to achieve is enough for a first conversation.
15 / Company and contact information
Getting in touch with KiS GmbH
Enquiries are handled by email. A short outline of the business context, the objective, the systems currently in use and any timing considerations gives us enough to reply with something useful.
