• English
  • Deutsch
Analysis · Coaching · Custom Software · Zurich

From requirements
to resilient systems.

fbt Berger analyses your business requirements, empowers your team through coaching, and builds the custom software to match when you need it – on commercially usable open source, replicated via a self-built, tested Raft library.

30+ years19 of them at Google
Analysis & coachingas core services
Own Raft corefrom scratch, Apache-2.0
Arrange a call → View services

Understand requirements.
Empower teams.

Two core services form the focus – custom delivery comes on top whenever you need it.

Core service 01

Business Requirements Analysis

Before a single line of code: your business requirements captured cleanly, questioned critically and translated into a solution that will hold. From over 30 years of engineering – 19 of them on systems at global scale – I know which questions to ask early.

Structure, sharpen and prioritise business requirements
Assess technical feasibility, scaling and risks early
From requirement to a sound architecture decision
Core service 02

Coaching

I empower your team to ship faster and more safely on its own – with two areas of focus.

Vibe-Coding

AI-assisted development at high velocity that still produces tested, documented and maintainable systems.

Large replicated systems

Building fault-tolerant, replicated architectures – in-house, for noticeably more data security and data sovereignty.

Delivery on request

Custom software development

If you would rather hand off delivery: custom software, built on the same foundation the reference projects run on.

Commercially usable open source Own Raft library · replication User management via Keycloak Apache-2.0 / MIT · legally clean

The foundation
behind the services.

Analysis and coaching only convince with real technical depth. Four building blocks every fbt Berger project stands on.

01

Distributed Systems & Consensus

Replication, quorum, fault tolerance and linearizable consistency. The machinery that keeps systems correct across node failures – a core competency, not a bought-in add-on.

02

Own Raft Library

A from-scratch implementation of the Raft algorithm in Java 17: leader election, log replication, joint consensus, snapshotting, linearizable reads. Apache-2.0 – so it can be used freely in your projects.

03

User Management with Keycloak

No reinventing authentication: I integrate Keycloak, the established open-source standard (OIDC / OAuth2, JWT) – multi-tenant and ready to use as a preconfigured setup.

04

Commercially Usable Foundation

Exclusively permissively licensed open-source components (Apache 2.0, MIT). Legally clean to use in your product – without copyleft traps.

Three projects.
One shared core.

The references are no coincidence: fbtberger-calendar and fbtberger-kwatro both use the same self-built Raft library for their replication. That proves the capability – and shows how fast it turns into working software.

CONSENSUS CORE fbtberger-raft L F F 3-node cluster · quorum REPLICATION REPLICATION fbtberger-calendar RFC-compliant calendar system · CalDAV · iTIP fbtberger-kwatro Distributed card game · gRPC · Svelte
58
Commits · fbtberger-raft
Jun 23 – Jul 6, 2026 · 14 days
Apache-2.0 · from scratch
200
Commits · fbtberger-calendar
Jun 28 – Jul 6, 2026 · 9 days
Distributed-systems demo platform
6
Modules · fbtberger-kwatro
proto · server · client · web · raft
Demo platform, built in days
Timeframes and figures come straight from the projects' Git history.
PDF Datasheet: the consensus core in detail →

The projects
in detail.

One reusable building block, two demo platforms that show what it makes possible.

Building block · Apache-2.0
fbtberger-raft
Period 23.06–06.07.2026
Scope 58 commits
Language Java 17
Status reusable
The consensus core – a complete Raft implementation from the ground up.

Implemented after Ongaro & Ousterhout, including the optimisations from the dissertation. This is the building block that gives client projects consistent replication across node failures.

Protocol Buffers gRPC / Netty / Hadoop RPC Berkeley DB JE Segmented WAL · CRC32 Prometheus / JMX TLS · mTLS
Leader election with PreVote & leader stickiness against partition disruptions
Cluster reconfiguration via single-step and joint consensus
Log compaction with chunked, copy-on-write snapshots
Linearizable reads via ReadIndex and lease-based
Chaos tests, JMH benchmarks and multi-transport integration tests
PDF Datasheet fbtberger-raft · 1 page →
Demo platform
fbtberger-calendar
Period 28.06–06.07.2026
Scope 200 commits
Stack Spring Boot 3.3
Purpose Capability proof
An RFC-compliant calendar system that shows the distributed architecture under load.

A pure demo platform: built to prove skills in distributed systems and vibe-coding. It combines standards compliance with serious scaling decisions – replicated via fbtberger-raft, secured with Keycloak.

Java 17 Spring Boot 3.3 PostgreSQL Keycloak · OIDC RFC 5545 / 5546 / 4791 fbtberger-raft
iTIP fanout / fanback with RFC-5546 conflict resolution
O(1) memory usage for events with 100,000+ attendees
Federation of external principals via iMIP (RFC 6047 / 6638)
Eventual consistency with four coordinated mechanisms
Docker cluster with mTLS and quorum-aware health checks
Demo platform
fbtberger-kwatro
Period June 2026
Structure 6 modules
Stack gRPC · Svelte
Purpose End-to-end demo
A distributed multiplayer card game as a compact architecture demonstration.

A pure distributed-systems demo platform: taken end to end from protocol to web frontend. It shows how a typed gRPC interface, replicated state and a reactive UI cleanly work together.

Java 17 Spring Boot 3.3 gRPC 1.64 Protocol Buffers Svelte · Vite fbtberger-raft
Multi-module structure: proto, server, client, web and Raft integration
Typed game protocol entirely over Protocol Buffers
Replicated game state based on the own consensus core
Reactive Svelte frontend with lobby, board and scoreboard

From over 30 years of engineering
to self-employment.

It starts in 1992 with a computer science degree from ETH Zurich – in practice earlier, with software work alongside the studies. Fifteen years follow across production control systems, intralogistics, engineering management and architecture consulting.

From August 2007 to February 2026 I worked at Google Switzerland GmbH on software at large scale – systems where availability, consistency and clean engineering are not optional but a given.

Since 2026 I have brought that experience together in fbt Berger – Future Build Technology Berger. As a sole proprietorship in Zurich, I build custom distributed systems for European SMEs: close to the client, without friction, on a foundation proven over years.

The phoenix in the logo is deliberate: proven engineering, set up anew.
1986–1992

ETH Zurich

Computer science degree (dipl. Informatik-Ing. ETH) – accompanied throughout by part-time software engineering at ABC Systems AG.

1989–1997

Production control and intralogistics

Application development at Mettler-Toledo, then project manager at VOLAG AG: a radio-linked warehouse management system, rolled out at more than six retail customers.

1997–2007

Management, consulting, architecture

Head of development and managing director roles at GLANCE and MEDICA, then senior consultant at sd&m and software engineer at PDF Tools AG.

2007–2026

Google Switzerland

19 years of engineering at global scale – incl. Google Calendar, Shopping and Maps.

2026

Founding of fbt Berger

Sole proprietorship in Zurich for custom distributed software – consulting, coaching, delivery.

2026 →

Core & references

Own Raft library plus two demo platforms as documented proof of capability.

Selected roles at Google
Google Calendar

Contributed to Google Calendar

Calendar and scheduling logic at global scale – exactly the domain behind the calendar reference.

→ Calendar domain depth
Google Shopping

Designed an AI-based policy-enforcement pipeline

Automated detection of policy violations using machine learning – designed for the Shopping catalogue.

→ AI-driven pipelines
Google Maps

Helped introduce incident display

Helped shape the display of incidents in Google Maps – real-time data, visible to millions of users.

→ Real-time & distributed systems

How I work.
Stated up front.

The terms of engagement belong at the start of a conversation, not at the end of one. Here is the shape of a mandate with fbt Berger – so you can tell within a minute whether it fits.

Engagement

Mandate, not employment

I work on a mandate basis as an independent Swiss company – no employment relationship and no staff leasing. Contract, liability and social insurance sit with fbt Berger.

Capacity

Part-time by design, around 60%

Deliberately reserved capacity: it keeps room for parallel mandates and for the continued development of the technical core my clients build on.

Location

Remote-first, one day on site per week

Switzerland and the wider DACH region. One regular on-site day a week keeps a team connected; the rest is more productive remote.

Availability

Immediate

No notice period to serve – as a sole proprietor I can start as soon as the scope is clear.

Contact

You talk to the person who builds it

No account management, no handover to a delivery team you have not met. The person answering your first email is the person writing the code – which is also why I take on a small number of mandates rather than many.

Not a fit? Then it is better established now than after three weeks. If your project needs full-time presence, a permanent hire or on-site work every day, I am happy to say so early.

Where an outage
stops the floor.

One focus area: the control layers of intralogistics – warehouse management, warehouse execution and material flow control. Availability there is not a quality attribute. It is the precondition for anything moving at all.

The layer

WES and material flow control

Between warehouse management and machine control sits the layer that knows which order is where right now. That state is short-lived, business-critical – and cannot be reconstructed from the WMS.

The risk

The state lives on one node

Many of these systems grew over decades and hold their runtime state on a single instance. When it fails, what is missing is not a service but the knowledge of what the floor is currently doing.

The answer

Replicated state, not a failover script

Consensus replication across several nodes: the state exists more than once, a node failure costs seconds instead of hours, and nobody has to maintain a restart order by hand.

The background

From hands-on project work

Project manager at VOLAG AG, Schlieren: a radio-linked warehouse management system for retail distribution centres, rolled out at more than six customers. Largest site: over 10,000 storage locations, around 5,000 picking orders a day, more than 50 radio terminals in real-time operation.

Safety-critical

Experience from environments where mistakes are expensive

As a senior consultant at sd&m: requirements engineering with DOORS for a fire alarm control panel, and an architecture audit in a nuclear power plant context. Traceability there is not a documentation duty but part of the construction – a mindset machine control benefits from too.

The Raft library the fbt Berger solutions build on was written for exactly this case: state that has to survive a node failure without anyone opening a runbook at night.

Let's build your system.

Whether consulting, coaching or full delivery – tell me what you have in mind. The reply comes from the person who also does the building.

Write an email →
fbt Berger
Future Build Technology Berger
Riedhofstrasse 98
8049 Zürich · Switzerland
© 2026 fbt Berger · Future Build Technology Berger · Riedhofstrasse 98, 8049 Zürich