Case studies - STAR format
Six concrete stories - situation, task, action, result.
No invented metrics. Each case starts from a real constraint, defends a technical decision and ends with measurable outcomes or publicly explainable proof.
STAR is the format senior technical interviews usually expect.
The open-source C# framework whose lineage reached Rockstar Games
CTO 2019-2021, 250 concurrent connections, 15-person team
- 250
- Concurrent connections
- 30,000+
- Accounts created
- Server sold in 2021 · lineage reached Rockstar (2023)
- Outcome
Situation- the context that made the project hard
At 19, I wanted to understand how a real-time server could hold hundreds of concurrent users. In 2016, the ecosystem was fragmented and many serious multiplayer tools were proprietary or immature.
Task- what the project had to achieve
Design a C# / C++ real-time networking framework and operate a community server that could hold 30,000+ accounts, 250 concurrent connections and weekly live releases.
Action- what I did, decision by decision
- Designed an authoritative client/server model with custom binary serialization and low-level UDP networking.
- Built CI/CD, monitoring and rollback discipline for weekly production releases.
- Led a 15-person team across development, QA, moderation and operations.
- Documented enough architecture for the server to survive my departure.
Result- measures, not adjectives
- 30,000+ accounts and 250 persistent concurrent connections over years of production.
- Community server sold to German investors in 2021.
- The broader Cfx.re / FiveM lineage was brought into the Rockstar Games ecosystem in August 2023.
- The project created the production discipline I still use on .NET and GenAI missions.
Trade-off I defended
I chose a custom binary protocol instead of HTTP/REST. The cost was a higher barrier for contributors; the benefit was much lower bandwidth and real-time latency.
IoT firmware deployed on 150,000 systems per year
From 256 KB RAM devices to cloud dashboards
- 150,000+
- Systems in production / year
- ÷ 3
- Incident time-to-diagnose
- 4 weeks → 1
- Developer onboarding
Situation- the context that made the project hard
Gecko Alliance ships connected spa control systems at global scale. Firmware, cloud ingestion and mobile apps had to work as one production chain.
Task- what the project had to achieve
Contribute across embedded C / FreeRTOS firmware, AWS IoT telemetry, mobile control flows and production diagnostics for 150,000+ systems per year.
Action- what I did, decision by decision
- Optimized C / FreeRTOS firmware under tight memory constraints.
- Worked on MQTT to AWS IoT Core telemetry pipelines with Lambda and DynamoDB.
- Implemented OTA and rollback-aware firmware update paths.
- Helped connect observability so production failures could be diagnosed remotely.
Result- measures, not adjectives
- Firmware deployed on 150,000+ IoT systems produced per year.
- High-frequency telemetry ingestion validated over production usage.
- Remote diagnosis reduced the need for field-level guesswork.
- A unified architecture view made onboarding easier across firmware and cloud.
Trade-off I defended
DynamoDB was favored over a specialized time-series database to reduce operational surface at the current scale, accepting a future migration if volume grows by an order of magnitude.
Field apps used by 250,000+ telecom technicians
Offline-first, BLE, 100 countries, critical field data
- 250,000+
- Technician users
- 100
- Countries covered
- 0
- BLE regressions in production
Situation- the context that made the project hard
Fiber and 5G field technicians often work with weak network coverage while communicating with proprietary measurement devices. Losing a field measurement means repeating an on-site intervention.
Task- what the project had to achieve
Contribute to Flutter / C# field applications, integrate low-level BLE protocols and preserve offline data integrity until synchronization returns.
Action- what I did, decision by decision
- Integrated Bluetooth Low Energy and Wi-Fi communication flows with measurement devices.
- Contributed to offline-first synchronization patterns for field measurements.
- Strengthened simulated BLE integration tests to reduce dependence on physical hardware in CI.
- Documented protocol communication patterns for future device generations.
Result- measures, not adjectives
- Applications deployed across 100 countries.
- Used by 250,000+ telecom technicians.
- BLE integration moved from manual confidence to automated regression coverage.
- No regression on existing BLE patterns during the new-device integration work.
Trade-off I defended
I pushed for offline-first behavior by default. It costs more during development, but it protects the exact field conditions where the product matters.
OneRP - multi-tenant real-time framework with Fusion RPC
2,048 concurrent connections target - pattern reused across SaaS contexts
- 2,048 (4× direct competitors)
- Concurrent connections targeted
- 1,150+
- Cumulative tests
- 3 other SaaS
- Pattern reused on
Situation- the context that made the project hard
Classic RP frameworks stack REST APIs between server, UI and admin tools. Under heavy concurrent events, accumulated request latency kills the user experience.
Task- what the project had to achieve
Design a multi-tenant .NET platform using one reactive state model across cloud server, Blazor admin, legacy Mono in-game DLLs and 48 React mini-apps.
Action- what I did, decision by decision
- Used Fusion RPC end to end over a dedicated WebSocket channel with MessagePack.
- Enforced tenant isolation with InstanceId, EF Core query filters and middleware.
- Built Roslyn analyzers to block anti-patterns at compile time.
- Created an offline NUI harness so all mini-apps can be tested without the heavy client.
Result- measures, not adjectives
- 2,048 concurrent connections targeted on the same virtual world.
- 1,150+ tests across .NET and React surfaces.
- Pattern reused on SaleCast, PromptVault and Racine.
- Prometheus, Grafana, Seq, OpenTelemetry and Serilog stack prepared for production operations.
Trade-off I defended
Fusion has a steeper learning curve than SignalR, but it gives automatic reactive invalidation that SignalR does not provide alone.
PromptVault - turning team prompts into reusable internal tools
Same prompt in browser and VS Code, PII masked before LLM calls
- GDPR-ready
- PII masked before the LLM
- 3 (Web · Chrome · VS Code)
- Surfaces on the same API
- 34
- Fusion feature slices
Situation- the context that made the project hard
Useful ChatGPT / Claude prompts often live in personal notes. They are not reusable, non-technical users cannot run them safely, and sensitive data may leave the company.
Task- what the project had to achieve
Build a B2B SaaS that turns prompts into internal tools: variables become forms, prompts can be chained, ContextPacks preserve company tone, and PII is masked before LLM calls.
Action- what I did, decision by decision
- Designed feature slices around Fusion compute services, endpoints and Blazor components.
- Built shared backend contracts for Blazor Web, Chrome MV3 and VS Code extensions.
- Separated Privacy Shield as a transverse layer for client-side PII masking.
- Added OpenTelemetry, Seq and Hangfire jobs for operational visibility.
Result- measures, not adjectives
- PII is masked before reaching OpenAI or Claude.
- Three surfaces consume the same API: web app, Chrome extension and VS Code extension.
- Multi-provider auth and workspace billing foundations are in place.
- Private active development with a clear B2B roadmap.
Trade-off I defended
I chose Blazor SSR plus Interactive Server instead of WASM to keep the first render fast and SEO-friendly, accepting less native offline behavior.
Poisson Engine - 100,000 entities at 60 FPS in a browser
WebGPU pipeline, graceful fallback, public live demo
- 100,000
- Entities at 60 FPS
- 60× faster
- vs CPU implementation
- Public demo + MIT license
- Proof
Situation- the context that made the project hard
Many teams still assume the browser is too slow for serious simulations. WebGPU changed that, but the data structures must be designed for GPU execution.
Task- what the project had to achieve
Build a WebGPU simulation engine, support graceful fallback and target 100,000 autonomous entities at 60 FPS on a recent MacBook.
Action- what I did, decision by decision
- Built an eight-pass GPU pipeline with zero allocations during simulation.
- Adapted spatial partitioning to flat GPU buffers.
- Added five levels of detail for rendering dense worlds.
- Implemented WebGPU, WebGL and Canvas2D renderer fallback.
Result- measures, not adjectives
- 100,000 entities at 60 FPS validated on compatible hardware.
- About 60x faster than the equivalent CPU approach.
- 70 automated tests around spatial partitioning and renderer behavior.
- Public demo available for inspection.
Trade-off I defended
I prioritized a minimal, auditable package over fast CDN-driven adoption. That slows distribution but keeps the core easier to trust.
Does your situation look like one of these six?
The first call is free. We can quickly check whether the architecture has a clean path and whether I am the right profile.