Expertise
Custom software, enterprise platforms, applied AI and the connections between them. The sections below describe the operational problems, the systems we design, and the path from the first conversation to handover.
01 — Services
Seven areas of responsibility. A project may use one of them or several, depending on what the operation needs.
The operation has outgrown spreadsheets, inboxes or a product that cannot express how the company works.
A purpose-built application for the real workflow, including roles, exceptions and the reports people use. Documented so it can be maintained.
Python, TypeScript, PostgreSQL, APIs
Several teams share a process, but no system holds the current state, the permissions or the history.
A platform with explicit roles, approvals and connections to the systems that should remain. Designed so changes and decisions can be traced.
TypeScript, Python, PostgreSQL, Docker
A critical workflow sits in a site, a shared folder or a tool that cannot be extended safely.
A web application with a clear interface, tested behaviour and a structure another engineer can continue.
TypeScript, JavaScript, React
People need faster access to knowledge, without invented answers or data leaving its agreed boundary.
Retrieval over approved sources, assistants with a narrow task, and models only where they outperform a simpler rule.
Python, PyTorch, LLMs, RAG
Skilled staff re-enter data, copy status updates and chase the next approval.
Stable steps automated, exceptions left with a person, and the status of the work made visible.
Python, APIs, PostgreSQL
Figures disagree across tools, and every new connection is a one-off script.
A maintainable data path, explicit interfaces and an environment that can be operated after handover. Cloud choices follow the constraint.
Python, PostgreSQL, Docker, APIs
A project moves before anyone has agreed what is being built, or the interface hides the work instead of supporting it.
Architecture and interface design tied to the implementation, plus advice that remains useful while the system is built.
Product architecture, UX/UI engineering, TypeScript
02 — Method
We do not start engineering against an undefined problem, and we do not treat launch as the end of the work.
We look at the current tools, data and constraints, and separate what must change from what should stay. The result is a shared understanding of the problem.
Scope, assumptions, exclusions and risks are written down. The estimate is given when the problem is understood well enough to stand behind it.
Delivery is incremental. The people who will use the system review it. Tests cover the behaviour that matters, and costly decisions are recorded.
Deployment, documentation and a defined support arrangement. Later changes are estimated. The client can own the system.
03 — Standards
Working practices for client engagements. They are not certifications, and they are not a legal opinion.
We choose the smallest design that meets the operational need, can be explained, and can be changed by someone who was not in the original build.
Access is limited to the work at hand. Secrets stay out of source control. Environments are separated when the project requires it. Dependencies are reviewed before handover.
Personal and confidential data are identified before they are processed. For AI, the permitted sources are agreed. This website does not store contact-form submissions.
Progress is discussed in short, regular conversations. Support, response expectations and the path for later changes are written down.
04 — Typical solutions
A private assistant, an operational application, or a reporting path: the kinds of systems an engagement is built to produce.
A team needs answers from its own procedures or project files. A typical solution limits retrieval to approved sources, shows where an answer came from, and stays inside that scope.
Approvals and status live in inboxes. A typical solution is an application with roles, a visible queue and connections to the systems that already hold master data.
Management figures are assembled by hand and do not match. A typical solution replaces that assembly with a traceable pipeline and a view people can trust.
Bring the operational problem. We will say whether we are the right team, and what a sensible first step would be.
Contact
Describe the situation in a few sentences. We reply by email to arrange a first discussion. There is no automated scoring and no obligation to continue.
Switzerland · International projects