How we build.

01 — WRITE

Externalise decisions.

Before we write code, we write architecture documents. Every feature starts with a clear requirements document: we record in writing, up front, which problem is being solved for whom, how the solution is structured, which alternatives existed and why we decided as we did.

The rule: what is not in the architecture document does not exist. Implicit assumptions are made explicit or dropped. That slows the start of a feature by hours — and speeds up its completion by weeks, because no discussions have to be revisited.

Behind this is a fixed working principle we call WISC internally: in four clear rules it sets out which information is gathered, cleanly separated, deliberately selected and condensed before a decision is made — whether a human is working on it or an AI agent.

02 — COMPLIANCE INVARIANTS

Compliance before convenience.

Security invariants are not sprint goals but architectural obligations. At OneLog these invariants apply without exception:

• →Every customer sees only their own data — enforced down to the individual database row. Whatever is not expressly permitted stays locked, without exception, including for privileged accounts.
• →Every interface checks on every access who is allowed to do what — against fixed role and attribute rules. No access without explicit authorisation.
• →Every security-relevant event is logged, signed with future-proof cryptography and continuously chained — so subsequent changes become detectable.
• →Operation only in European cloud — no US hyperscalers, no US building blocks. AI model, email delivery and storage stay in the EU.
• →Credentials live centrally in a protected vault, never in plain text in the code. Hard-coded keys are rejected automatically before they can be committed — without exception.

Anyone wanting to bypass an invariant writes an ADR (Architecture Decision Record) with a justification. The ADR goes into the repository. Reviewed. Documented. Auditable.

03 — TEST-BEFORE-DONE

No “should work”. Only green pipelines count.

Before we report done, the complete build and test pipeline runs green. In every language, every time, without exception. On failure, the engineer (or agent) autonomously enters a correction loop — analyses, fixes, re-validates. Only after a green build does the answer reach the user.

The same applies to texts the AI produces: before an automatically generated document is released, it is checked automatically and must reach a defined quality score (evaluation pipeline with a score threshold). It is checked three ways — for freely invented details (hallucination check), for adherence to your requirements (compliance check) and for the appropriate writing style (tone-of-voice check). If the score is not reached, the document automatically goes back for revision and is checked again.

04 — AGENTIC BY DEFAULT

A click in the UI is UX debt.

We do not build dashboards for human click-work. We build platforms that detect, resolve and log problems — before an operator sees them. Dashboards are escalation paths, not workspaces.

This is more than “automation”. It is an architectural bet: if a problem can be solved deterministically, it is solved deterministically. If it cannot be settled by a fixed rule, a group of cooperating AI agents takes over and records every step traceably. Only when both routes get stuck does a human see the problem — and then with full context.

That changes our customers' business model: an MSP technician who looks after 50 devices today looks after 500 with OneLog. Not through more clicks per hour — but through dramatically fewer clicks needed.

Stack choices, briefly

What we build with — and why.