Peter Wiederkehr

More than 190,000 lines of Next.js 10 / React 17, web only, migrated into a new codebase that ships web and native mobile — the mobile apps came out of the migration itself, not after it. The legacy frontend was switched off in production in July 2026, one engineer on the work. It ran as a pipeline, not a rewrite: agents followed the legacy imports to find everything a feature actually touched, then extracted its observable behaviour into a platform-neutral specification — business rules, user stories, API inventory, state — which planning and implementation worked from. The spec was written by an agent that never read the legacy code, so nothing was carried over by imitation; a separate parity pass compared old against new, area by area, and every gap went to a person to decide. Twenty-one features went through it. What came out is not a port: it is a codebase built to be worked by agents, and the same pipeline that migrated it now builds on it.

Running a system is normally knowledge rather than material: which settings each service needs, where its data lives, what must never be done to production — and it sits with whoever set it up. Here the platform describes itself instead, so every operation is derived from that description rather than typed from memory, and the rules that protect production hold because they are written down rather than remembered. That is what makes the work agent-runnable: an agent can deploy, check what is running, rotate a secret or restore a database, because the parameters are on the page and not in someone's head. It can investigate as well as execute — read production logs and telemetry, and query the production databases through connections that are read-only by construction, the read-only property itself tested by attempting writes and requiring them to fail. The limit is deliberate: the operations that could destroy something ask for a person at a terminal and offer no flag to skip it. Automating everything was never the point — making everything explicit was, and the automation follows from that.

The goal was that taking on the platform should not mean taking on people. Work a client would otherwise staff happens inside the product: writing and sharpening the text that sells an experience, translating it, generating the images that go with it, researching a provider or an event on the web, drafting social posts inside each platform's limits, matching people to what actually suits them, and reviewing what users submit before it goes live. Each of those was a task someone did by hand; each is now something a client reviews rather than produces — which is what lets a client grow the business they run on the platform without growing the team that runs it. The models behind it come from several providers, chosen per capability and exchanged by configuration rather than by rewrite, and the cost of every call is tracked per request, so what the productivity costs is a number rather than a guess.

Using AI well is a skill, not a topic — and the skill transfers across every tool. A three-hour foundations course for business professionals built on that idea: eight modules, from a working mental model of what AI actually is, through writing instructions that work, to privacy settings and the ways AI gets it wrong — hallucination, bias, agreeing too easily — shown live in ChatGPT, Claude and Gemini side by side, in plain language. The goal is deliberately the basics: the principles understood well enough that whoever wants to go deeper starts on solid ground.

The team's remit ran across the whole software development lifecycle: evaluate which AI providers and tools the company should put to work, and where. Led the agentic-coding part of it — a half-year evaluation that ended in a decision: Claude Code, from Anthropic. Built a two-day practical course on working with it and delivered it five times to roughly 80 software engineers, with a completed train-the-trainer handover.

An annual programme built to find the people the company should be developing into specific positions: a cohort of 20–25 per round, each nominated by the manager they reported to, brought together for two days, taught on subjects like leadership, writing and presenting an offer, or sharpening a USP, and then assessed. The assessment mixed group work — a team preparing a fictional offer and presenting it — with individual role-play: a real working situation, played out in the room, to see how the person would behave in it. Ran more than ten times, putting over 200 people through it.

The ti&m Banking Suite taken live as the new eBanking for Esprit Netzwerk AG and all 24 banks in its network. A new eBanking is an integration project before it is anything else: every bank's core systems, processes and data had to be worked into it, each of the 24 had its own view of how it should be done and all of those views had to be taken into account, and the old eBanking had to be shut down and cut over — all 24 concurrently. Over 270,000 eBanking customers moved, on a bespoke migration module built from the ground up because nothing manual would work at that scale — the Suite's largest multi-tenant deployment.

An Avaloq-based bank, and the clearest case for how the Banking Suite was built: modular, so a bank takes the modules it wants and keeps what it already runs. Baloise had an advanced chat platform of its own, so that was integrated into the eBanking rather than replaced by the Suite's own chat module — close enough that a customer never meets a seam.

Tambas in the German branch, Finnova in the Swiss, both integrated into a single instance of the ti&m Banking Suite as separate tenants. VZ also brought a large estate of its own applications that the eBanking had to present as parts of itself: advisory mandates rendered from VZ's internal systems, execution-only mandates from the Suite's own views — one product to the customer either way.

A first customer is where a product becomes a product. Bank CIC ran on Avaloq, every gap that surfaced against a real core banking system was closed inside the delivery, and what went live became the platform every later bank was built on.

A numbered account was, at the time, the most closely guarded thing a Swiss bank had: an account whose owner almost nobody inside the bank itself was allowed to know. Lead engineer on the application to manage those accounts for Credit Suisse, and on its integration onto the platform; the platform itself was another team's work. The secrecy was the requirement: every layer, from the application down to the platform it ran on, was built to a security bar well above what banking software already has to clear — because what there was to protect was the customer's identity itself.

Built on Jive, a social collaboration platform, twice — first for a bank, then for the company itself. For Credit Suisse: a platform where the bank published to its external asset managers and worked with them in one place, using the full collaboration feature set rather than a one-way channel. That client work made the tool a known quantity, and the concepts and planning followed to establish it as ti&m's own company intranet, then around 300 people: sites and spaces modelled on how the organisation actually worked, rights and access deciding who saw what, the old solution's content migrated across, the requirements of every department worked in — and the training and support that made the platform stick.

One of the earliest client projects, at ti&m: COMAR — the Common Marketing Architecture Roadmap — at Novartis, a programme centred on data warehousing, business intelligence and reporting. The question behind it is simple to ask and hard to compute: what share of each market do Novartis products hold. Answering it meant sourcing information on drugs and sales figures from many places into one warehouse, modelling it into data marts and cubes, and reporting from there. More than a year of that was writing the ETL processes that fed the warehouse, alongside the data modelling that made the figures comparable at all.