Services
Mostly I review architectures and existing systems, and build defined backend or integration changes. Short assignments are welcome.
Architecture and advice
You bring a defined technical question. You get a written recommendation that weighs the options and says what to do next.
MonitoringHive: alternatives in a branding decision
Does custom portal branding need its own service, and what must it never be allowed to do? The decision record answers both and names the rejected alternatives, so the team can build it without reopening the question.
Unknown host returns the default MonitoringHive brand with HTTP 200 (never a 404/redirect). Resolution failures degrade to the safe default.
Full extract
Alternatives
- Dedicated branding microservice in v1: rejected as premature; static config behind the BFF meets Release 1 needs with far less operational cost.
- Tenant-editable CSS / theme upload: rejected; violates the CSP posture and the "no arbitrary CSS/JS" invariant. Only whitelisted tokens are allowed.
- Deriving navigation or feature availability from the brand/host: rejected; would create a second authority competing with effective access and break tenant isolation guarantees.
Technical review
Findings in order of priority, each with its evidence and what I'd change. The report also says what I didn't look at. One example of the kind of question: who can access which data, and how you can show it afterwards. How I approached that in MonitoringHive.
Buttler: a request-size finding and its fix
Can an authorised but compromised phone exhaust the gateway's memory? The finding shows how, how it was reproduced and what must change, followed by the fix and its tests. You know what to fix and how to check it.
F04: The gateway still buffers arbitrarily large authenticated JSON
Both POST handlers await request.json() with no gateway body-size limit. Only afterward do they enter the thread pool and acquire the four-upstream semaphore. The brain's body limiter cannot protect allocations and JSON parsing already performed by the gateway.
Full extract
Prerequisites and impact: A caller knows the house code, for example an authorized but compromised phone. A single request can consume large memory; concurrent requests compound it.
Reproduction: The real gateway app accepted a synthetic 2 MiB chat text and forwarded the entire JSON body through MockTransport. No brain or LAN service was contacted. This proves the missing gateway cap, not a measured production OOM.
Required correction: Apply streamed byte limits at the gateway before JSON parsing, with route-specific chat/voice budgets and safe overflow behavior. Test declared, absent and dishonest Content-Length values.
Fix: Added route-specific streamed limits before JSON parsing. Authentication now rejects bad credentials before body reads. Tests: declared/streamed overflow tests, dishonest lengths, normal voice traffic and a no-body-read authentication test.
Specialist implementation
An agreed backend or integration change, tested, documented and handed over to your team. We settle the acceptance criteria before I start.
Buttler: deployment and recovery instructions
How does the operator roll out a security change, and what if it only partly succeeds? The instructions say which failures can be rolled back, which must be repaired forward, and what to check afterwards.
This is a forward-only security migration, with a visible interval of unavailable HA actions. A bridge-code deployment failure occurs before utility cutover and uses the existing code rollback path.
Full extract
A later utility/configuration failure leaves the new code failing closed; repair and rerun the failed job. Do not restore the old HTTP URL or roll back to pre-bridge binaries after utility HTTPS has switched. A healthy liveness response does not certify completed migration.
After deployment confirm normal voice/chat, memory management, HA actions and certificate rotation. Check migration readiness and the running gateway UID.
Before we start
For a first conversation, a description of the problem and the outcome you need is enough. The first call is free and takes up to 30 minutes. Paid work starts only once we've agreed the scope in writing.
Before paid work begins, we write down:
- the question or scope,
- the systems involved and what they depend on,
- who makes decisions,
- when the work counts as done,
- which access it actually needs.
Small, clearly defined advisory and review engagements are welcome. If I can't estimate the work yet, I'll propose a short paid investigation first.
Rates
- Architecture advice and technical reviews: from CHF 190 per hour
- Specialist implementation: from CHF 160 per hour
- Minimum: 2 hours remote, 4 hours on site
- Travel: included within the city of Zürich. On site elsewhere within about an hour of Zürich by public transport: travel time at half the hourly rate, plus second-class fares. Further away, I work remotely.
Prices exclude VAT where applicable. Larger pieces of work get a fixed offer.
Advice and reviews happen in short blocks, implementation on days we agree. I confirm the start date with each offer.
I don't take on on-call duty or open-ended contracting, and I don't build complete apps from a loose idea.