Principal software engineer, 15+ years. Architecture and frontend for regulated, security-critical systems, healthcare, finance, defense, public sector. Plus LLM integration that actually runs in production, and accessibility that survives a formal review.
Not staff augmentation billed by timesheet. Clearly scoped engagements with a defined outcome, timeframe and handover, each one ends with something that stays in the repo.
Fixed days per month inside the team. Standup, review, architecture round, as the technical counterpart, not a ticket processor.
Old platform, grown requirements, no downtime allowed. A staged relaunch that runs alongside production instead of betting on a big bang.
Why did every change get expensive? I read the code, the pipelines and the decisions, then say what stays, what dies, and in what order.
From prototype to dependable building block: retrieval, tool use, guardrails, evaluation, including the uncomfortable question of whether it really beats what you had.
Manual review against WCAG 2.2 AA, keyboard and screen reader, not just an automated scan.
Fixes at the root instead of the symptom: inside the design-system components, so one fix repairs a hundred screens.
Since mid-2025, German and EU accessibility law applies to a large share of consumer-facing digital products. Most teams notice when a regulator or a large client asks. I come in before that turns into an emergency project, and afterwards it stays measurable.
Manual testing with keyboard and screen reader, backed by automated checks. The output is a findings list with WCAG criterion, severity and estimated effort, sorted by impact, not by chapter.
Fixes in the components rather than in individual screens: focus order, names and roles, contrast, form errors, live regions. Delivered as PRs in your repo, reviewable by your team.
axe-core and Playwright in the pipeline, acceptance criteria in the ticket template, a workshop for the team. Plus the accessibility statement you are legally required to publish.
This page carries its own a11y switch in the top right: contrast, text size, reduced motion. Keyboard focus is visible throughout, every section reachable via skip link. The principle: demonstrate it, don't claim it.
Architected and built core components of a public-sector electronic health record: role-based access, data isolation, auditability. Ownership of technical standards and the long-term maintainability of platform components.
Relaunch of a high-traffic public-broadcasting audio and editorial platform. Ongoing, frontend architecture, accessibility and web performance under public-sector requirements.
Overall technical ownership of architecture, quality and evolution of complex platform solutions in security-critical environments.
Complex web applications in finance and consulting; architecture and technology decisions for frontend platforms.
Scalable web applications for transport and logistics, highly available platforms with real-time data.
Security-critical banking applications, regulatory and internal compliance requirements.
Digital publishing and platform work: content systems, scalable web architecture, performance optimisation.
Side projects are not portfolio filler, they are the lab: where I test architectural assumptions before they get expensive in client work.
A custom Chromium fork for web data extraction at scale: extraction in C++ instead of through JavaScript, network observation in the core, cloud-native execution on Lambda with cold-start tuning and distributed egress. If that layer interests you, engine internals, latency budgets, reproducible environments, I am happy to go deep on it.
Open evidence repository for a sparse-attention ablation: frozen harness, configs, raw artifacts, preregistered reading memos, incident log, verification reports. Every number in the post resolves to a named artifact.
A local-first code intelligence engine: search, symbols, dependency graph and pattern detection for actually understanding a real codebase, without shipping it to a cloud service.
A small implementation for setting the backlight colour of the Cherry MX-LP 2.1 Compact Wireless. Born from wanting to understand a protocol myself instead of trusting the vendor app.
You describe the context and the pain, I ask the uncomfortable questions. Outcome: an honest read on whether I can help, and with which package.
A short look into the code, repo or product. Then a proposal with scope, timeframe, deliverable, and an explicit list of what is not included.
Weekly status, visible interim results, work happening in your repo and on your board. No black box, no waterfall finale.
Documentation, ADRs, tests and a walkthrough with the team. The goal is that you can continue without me, and choose to bring me back for the next thing.
An email with two sentences of context is enough. You get an honest assessment back, including when that means you don't need me for this.
simon@skynet.lol