Sometimes it is not a large project. Sometimes it is simply something that does not work. Something that has been left undone for far too long. A process that could be simpler. An old system that no one really wants to touch. Or simply something that needs to be done.
We can do quite a few things and are happy to help you with them.
Do you have something that needs to be done?
Maybe you already know quite precisely what needs to be done.
Maybe you only know the problem so far.
If it is a good fit for us, we are happy to support you. That can be a small task for a few hours, an unusual technical problem, or something larger that is worth taking a closer look at.
For example:
- Unix, Linux, and OpenBSD
- debugging and troubleshooting
- old software and legacy systems
- shell, Lua, and small automations
- servers, mail, and migrations
- transferring, transforming, or extracting data from old systems
- small websites and technical web work
- technical documentation
But sometimes the actual task lies one level deeper.
You know something is wrong – but not exactly what yet?
Organically grown systems can keep working for an astonishingly long time. At some point, making a change becomes difficult, dependencies are no longer clear, or a process that should actually be simple has become increasingly complicated over the years.
In that situation, immediately imposing a new solution does little to help.
We prefer to look at a manageable section:
- What actually happens?
- Which processes and systems are involved?
- Which interfaces do we know?
- Where are the dependencies?
- Which assumptions are supported – and which are not?
- Where does unnecessary complexity arise?
- Which deviations are actually a problem?
The point is not to claim after a few days that we understand an entire company.
Together, we define the relevant section of the system and try to develop a robust picture of it. Only then does it make sense to discuss whether anything should be changed at all – and if so, what.
Depending on the task, this includes Systems AnalysisStructured examination of a system, its properties, and relationships as a basis for technical decisions
Auch bekannt als: System Analysis, Technical Discovery, Verification & ValidationEvaluation of whether a system meets specified requirements and is suitable for its intended use
Auch bekannt als: Verification & Validation, V&V, Solution ArchitectureArchitectural description of a concrete solution for a defined problem or set of requirements
Auch bekannt als: System Architecture, Systems IntegrationConnection of different components or systems into a cooperating overall system
Auch bekannt als: System Integration, or Legacy ModernizationTargeted modification of existing systems and their environment without automatically equating modernization with complete replacement
Auch bekannt als: Legacy System Modernization, Application Modernization, Legacy Migration.
You work with AI – but cannot always trust the results?
We know that from our own work.
AI can significantly accelerate research, programming, documentation, and many other tasks. But it can also produce very convincing results that are wrong, incomplete, or inconsistent.
That is why one of the questions we work on is how AI can be integrated into workflows without handing responsibility for the result over to it.
This includes, for example:
- checking results against defined rules
- combining different verification paths
- providing the information relevant to a task specifically as context
- keeping context small and traceable
- distinguishing between known and unknown assumptions
- checking technical claims against real systems where possible
- retaining human control at the points where it is necessary
Today, parts of this are grouped under terms such as AI AssuranceSystematic generation, evaluation, and communication of evidence to enable justified trust in relevant properties and the use of an AI system
Auch bekannt als: Artificial Intelligence Assurance, AI EvaluationSystematic evaluation of the properties, results, and behavior of an AI system based on defined criteria
Auch bekannt als: AI Evaluation and Testing, LLM Evaluation, Context EngineeringSystematic design and provision of the context relevant to a specific AI task
Auch bekannt als: Context Management, or Architecture ConformanceConformance of the actual structure and implementation of a system with defined architectural specifications
Auch bekannt als: Architecture Compliance.
We are also researching and developing our own tools for this. Not all of them are finished – much of it is currently emerging from our daily work.
Would you like to become more digitally independent?
Not every problem needs a new cloud service, another framework, or the next platform.
We have worked with open and self-hosted systems for many years and deal with digital sovereigntyAbility to make autonomous decisions about digital systems, data, and dependencies and to remain capable of acting when conditions change
Auch bekannt als: Digital Independence, Technological Sovereignty: understandable dependencies, open formatsData format whose technical structure and meaning are sufficiently publicly documented so that independent implementations can create, read, and process data
Auch bekannt als: Open Format, free software, self-hostingOperation of a digital service or system under one's own technical and organizational responsibility
Auch bekannt als: Self Hosting, Self-Hosted Operation, and the ability to leave a provider or technology again later.
The same applies here: running something yourself is not automatically better, and open source does not solve every problem.
What matters is what makes sense for the particular system.
Do you work for clients yourself?
Sometimes something lands on a client’s desk that does not fit your own area of expertise.
Maybe you build websites and do not want to deal with the old server underneath. Maybe you design something and suddenly a special technical solution is needed. Maybe a client needs help with an old system, a migration, or a problem for which you do not currently have the right people.
We can work with you, stay in the background, or – if it makes sense for everyone – speak directly with your client.
Your client relationship remains your client relationship.
Even if it is only a few hours or a single day, we are happy to help.
How we work
We like small, manageable systems.
Not because the world is always simple, but because manageable systems make it easier to see what a change actually does.
With larger systems, we therefore do not try to understand everything at once. We define the relevant section, examine its known interfaces with the environment, and expand the picture as new dependencies become visible.
Not every deviation has to be eliminated immediately. Sometimes it is an error. Sometimes the system can live with it perfectly well. And sometimes it leads to something no one had thought of before.
Not every task is a good fit for us. If we believe we are not the right people for it, we will tell you.
Remote is normal
Most of the things we do do not require a shared desk. We work remotely. Where you or we happen to be therefore usually does not matter much.
Who will look at your problem?
Many of the technical projects at dragons@work are accompanied by Michael.
He has worked with technical and operational systems for more than four decades – from mainframes, networks, and enterprise software to international platforms and embedded systems, and today’s AI-assisted workflows.
What is it about?
Feel free to write us a few sentences about what you would like to do, what is not working, or where you could use some support.
Please do not send us passwords, credentials, or confidential files through the form. If we need such information for the work, we will agree on an appropriate way to exchange it.