Principal Full-Stack Engineer modernizing real codebases — .NET, Java, TypeScript, Angular, PHP, Vue and Docker — real bugs disclosed, found and fixed.
coolify-full — Principal Full-Stack Engineering Demonstration
An enhanced fork of Coolify (a self-hostable Heroku/Vercel alternative) used as a technical portfolio piece: a live, real-world Laravel monolith modernized incrementally rather than rewritten from scratch.
- 84/84 pages migrated from Livewire to Inertia.js + React, one page at a time, each conversion verified with automated tests — not a big-bang rewrite
- PHPStan baseline taken from 1,306 → 55 suppressed errors, phase by phase, each phase individually verified with a full test-suite run
- 1,605 Pest tests, real pre-existing bugs found and fixed along the way (documented, not hidden)
- Full Docker Compose dev environment, de-commercialized (billing/subscription surface area removed) for a clean self-hosted fork
Every claim in that repo's README is checkable against its own commit history — see the README's "Reading the commit history" section for exactly how.
platform-main — Principal Frontend Engineering Demonstration
A from-scratch rebuild of NgRx's core state-management libraries, module by module: real, MIT-licensed source ported where fidelity to a battle-tested implementation matters, and specific classes deliberately redesigned where the original violates its own interface.
- 6 classes redesigned from RxJS inheritance to composition, fixing a genuine Interface Segregation violation in the real upstream source — found across three audit passes, not a spot-check
- 7,046 Vitest tests, 0 lint errors, across all 13 modules and the Helpdesk app
- Code-review audit complete: all 13 modules, 270/270 files, each with its own issue and reviewed PR — including an aliased import that silently turned off 14 of the ESLint plugin's rules, and a state property name that permanently broke
patchState. Then the 31ng updatemigrations, reviewed the same way (27 fixed), and type-level tests for every module's public API (11 type mismatches and 3 runtime bugs found) - An 18×/4.5× real performance fix, found by refusing to accept a reporting-config change that only looked like a fix, and tracing it to the actual bug instead
- Now building a real app on top of it, not a demo: a help desk that uses every module, with a NestJS API, PostgreSQL and real sign-in (#303)
- 10 CodeQL security findings (6x ReDoS + 4x prototype pollution) found and fixed in ported source, landed through real Pull Requests
Every claim in that repo's README/case study is checkable against its own commit history and live CI — see docs/case-study.md for the full writeup.
saga-full — Principal Full-Stack Engineering Demonstration (Java)
A from-scratch implementation of the Distributed Saga pattern across independent microservices — a JWT-guarded API gateway in front of order placement, payment, and fulfillment, coordinated with compensating transactions instead of a shared database transaction. All six backend modules are built, wired end-to-end, and fully containerized; a file-by-file code-review audit covering the entire codebase is complete, the same discipline already proven on coolify-full and platform-main. A register/POS frontend — login, order entry, live order status via Server-Sent Events — is now functionally complete and tested end-to-end; a professional visual layout pass is the one thing still planned.
- 6/6 backend services complete, 181/181 tests passing, verified against real Postgres and Kafka infrastructure, not mocked, plus a separate 20-test Vitest/React Testing Library suite for the React/TypeScript frontend
- Fully containerized: 5 per-service
Dockerfiles +docker-compose.yml, the whole stack starting with one command, verified end-to-end including the saga's compensation path - Code-review audit complete: all 6 modules, 73/73 files, 26 real findings fixed, 0 left open — plus a separate, deeper test-coverage-gap scan that found 9 more real gaps/dead-code items afterward
- 31 real bugs found & fixed — build-tooling incompatibilities (JDK 25 vs. Gradle, Lombok, Mockito, Spring Boot's bundled ASM), two real security fixes in the login flow (a user-enumeration issue and its timing-side-channel sibling), a live IDOR the code-review audit caught and closed, a Kafka poison-pill gap, a second cross-service log-injection trace, a data-integrity validation gap, a payment-decline path that never existed, a refund compensation that never checked whose order it was refunding, an inventory module that could never actually allocate anything in a real run, a missing DB constraint that let duplicate Kafka delivery create two tickets for one order, a Gradle task-ordering bug that could silently break the consolidated test report, a 10-day-old CodeQL alert finally run to ground and resolved (genuinely fixed, not just re-flagged), the same unbounded-Kafka-timeout and missing-error-handler gaps already found once each, caught a third time, an unlocked stock-deduction race reachable once
restaurant-servicescales past one replica, a login call silently executing on a shared Reactor Netty event-loop thread instead of an isolated scheduler, two CWE-117 log-injection bugs on the gateway's auth path (a malformed JWT's decoded payload, and the login email itself) confirmed by reading auth0's actualjava-jwtsource rather than assumed, a gateway circuit-breaker timeout that only surfaced by actually running the full containerized stack, an SSE stream that replayed stale buffered status updates to a late-connecting client (a ReactorSinkssemantics gap), a Spring Cloud Gateway route-method predicate with zero preflight-awareness that silently dropped every real browser CORS preflight, and a second, subtler CORS bug rooted in aHandlerMappingrace between the gateway's own routing and a local@RestController— found and fixed acrossorder-service's,payment-service's,restaurant-service's, andapi-gateway-service's code-review passes, the container rollout, and the frontend build itself - Original gRPC contract design, not a copy of any reference material used only for the module layout
- Full reasoning for every decision recorded in
docs/architecture.md, progress tracked intodo.md, and work tracked on a public project board
conduit-full — Full-Stack Engineering Demonstration (React/Express)
An independently modernized fork of the RealWorld Conduit example app — a Medium-style publishing platform (CRUD, auth, pagination) built with React 19/Vite/Express 5/Sequelize/PostgreSQL. Rather than copying the source repo over wholesale, it's being rebuilt one file at a time, with dependencies and patterns brought up to their current latest along the way.
- Backend complete: 100% TypeScript, 228 tests passing, 30 real bugs found and fixed along the way (disclosed in
todo.md, not hidden) - Frontend complete, TypeScript from file one: all 16 planned API service modules, both context files, all 32 components, all 12 route pages, and the app entry point are done — the full stack runs end to end, verified live against a real Postgres database. 40 more real bugs found along the way; a real gap disclosed too — 62 of the 69 files tracked by issue #71 still have no behavioral tests yet (7 done so far), tracked openly rather than hidden
- Yarn workspace, MIT license (original upstream copyright preserved), and CI (ESLint, Prettier, Vitest, CodeQL) in place — none of which existed in the source repo
Every claim here is checkable against this repo's own commit history and live CI — see todo.md and the project board for current status.
eshop-full — Full-Stack Engineering Demonstration (.NET Aspire)
An independently modernized version of Microsoft's dotnet/eShop reference app — a .NET Aspire microservices e-commerce platform (Catalog, Basket, Ordering, Identity, Payments, Webhooks, a React storefront in place of upstream's Blazor, RabbitMQ event bus). Rather than copying the source repo over wholesale, it's being added one file at a time, with every package version individually researched against what's actually current rather than assumed.
- 6 of 21 projects done (EventBus, EventBusRabbitMQ, eShop.ServiceDefaults, IntegrationEventLogEF, Identity.API/Duende IdentityServer, Identity.WebApp) — real bugs found and fixed along the way, not just version bumps: a Polly retry pipeline that never actually awaited its own operation (so it silently never retried the failures it was configured to catch), a null-conditional that made an error-handling branch unreachable dead code, a disabled JWT audience check that would have let a token issued for one downstream API be replayed against another, a silent event-type-collision bug in the transactional outbox's reflection-based type resolver, a CodeQL-caught log-injection spot plus an external-login callback that crashed instead of falling back cleanly (both found in Identity.API's own Duende-shipped source), and a Vite dev-proxy Host-header issue in
Identity.WebAppthat broke every Duende-triggered top-level browser redirect, found and fixed once its React SPA replaced Duende's Quickstart Razor UI - Every completed project is fully tested: 186 MSTest tests on .NET's newer Microsoft.Testing.Platform runner plus a 118-test Vitest/React Testing Library suite for
Identity.WebApp's React SPA — 304 passing tests across all 6 done projects, with CI coverage collection and PR-visible test reporting verified against real GitHub Actions runs. That Polly retry fix above? Verified end-to-end for the first time by one of those tests — not just fixed and assumed correct - Full reasoning recorded in
docs/architecturedesign.md, progress tracked intodo.md, and work tracked on a public project board
This one's still early — see todo.md for current status rather than assuming it's finished.
AxonFramework-Full — Full-Stack Engineering Demonstration (Java/Gradle)
A Maven-to-Gradle build-system migration of Axon Framework 5 — a 14-module Maven reactor converted one file at a time, each file individually inspected against the source and given its own migration decision, rather than an automated conversion tool run or a bulk copy of the source tree.
- Build-logic conventions,
common, andupdatemodules all done: all three shared Gradle convention plugins in place (published/internal/base),test-logging,common(144 of 144 source files), andupdate(27 of 27 source files) all converted and published/complete, one file at a time in dependency order - 43 real bugs found & fixed: a circular dependency Gradle's convention-plugin model has no Maven-inheritance workaround for, an undocumented Gradle 9.2/nmcp configuration-cache crash, a
.gitignorecollision between real tracked content and Gradle's own output directory, a missingaxon-artifact prefix that had been silently publishing under the wrong Maven coordinate, a stricter-javadoc rejection of Axon's own HTML that upstream's Maven build already suppresses and Gradle hadn't, dead module references in upstream's ownpom.xml, a CIgradle-versionshorthand that fails outright, a jar manifest still crediting upstream's org, a stale pre-Java-7 UTF-8 idiom carrying a dead catch block in two files, two contract inconsistencies incommoncaught by cross-checking new files against the interfaces/siblings they implement rather than reading each in isolation, a nullness-contract chain spanning four files resolved only after checking with the user, a nullness gap grounded in a documented JDK API contract, a deliberate Oracle-version rewrite whose first attempt was wrong until tested against a real disposable database instance, an interface/implementation nullness mismatch found by reviewing a whole 12-file circular closure together rather than one file at a time, an ambiguous lambda overload resolution fix matched to a sibling pattern already established in the same file, a decorator contract nullness gap found by checking a new file against the interfaces it actually calls, and thirteen more found finishingcommonand a deliberate retroactive DRY/SOLID re-audit of all 144 finished files once it was done — two backwards error-message polarities, a wrong exception type, a dead unused import, a javadoc claim that didn't match its own implementation, an assertion message describing only half of what it checks, and seven more places a value could genuinely benullwithout the type saying so — and twelve more found completing the entireupdatemodule (27 of 27 files) and a second comprehensive re-audit of bothcommonandupdatetogether: a dead parameter silently discarding real vulnerability data, a duplicated classpath scan next to a record built from an uncheckedPropertieslookup, a singleton field any external caller could reassign, an interface-wide nullness gap repeated across three implementations plus one more nullness gap on a different class's own failure-cause field, an unsynchronized lazy-init field missing bothvolatileand@Nullable, two more javadoc claims that didn't match their own implementation, a thread-safety gap on two more fields confirmed identical in the real upstream source, a GradlecompileOnlydependency-scoping gap affecting every future module built oncommon, one more missing-@Nullablegap, and one more error message naming the wrong thing entirely - CI (build verification on push/PR), GitHub Pages, a wiki, and architecture diagrams all live and cross-linked
- Full status recorded in
todo.md, work tracked on a public project board
This one's still early — see todo.md for current status rather than assuming it's finished.
directus-main — Principal Frontend Engineering Demonstration (Vue/Node.js/Yarn)
A redesigned rebuild of Directus's admin-panel state layer, package by package — now including a real, deployed Vue app: Pinia stores and a DirectusError class hierarchy built fresh from the real project's domain, not reproduced from its source.
- Try the live app: routed login/home pages (
vue-router), a working auth flow whose session now survives a hard refresh, and a logout button —demo@directus-main.dev/demo1234, or anything else to see the real error path - 3 packages complete, 2 more in progress,
api/genuinely wired in:stores(four Pinia stores, 20 tests, 100% coverage),constants, anderrors(a real class hierarchy, redesigned away from the source's factory-function-plus-enum pattern) — plussystem-data(the realtypes.tstype surface, done) andutils(started) — and a real Express server whose tested/auth/loginthe app now genuinely calls in local dev - Two independent-refs-that-must-stay-in-sync bugs found and prevented by design, not patched over — both
useAuthStore's session state anduseAppStore's hydration state were collapsed into a single discriminated value so the invalid combination can't be represented at all - A repo-wide drift sweep found and fixed a real test-isolation bug (leaked component instances interfering with later tests via a shared router) plus several stale docs and issues — this entry included
This one's still early — see todo.md for current status rather than assuming it's finished.
GridPulse — Principal Full-Stack Engineering Demonstration (.NET Aspire/React/Kafka)
An original, from-scratch event-driven platform simulating a utility company's meter-reading, usage-aggregation, and billing pipeline — not a fork or a cloned reference app. Designed to exercise the same skills a Principal Developer role expects: microservices decomposition, event streaming, polyglot service boundaries, resilient service-to-service communication, CI/CD, and production-grade observability, with the full architecture, event contracts, and rationale written up before a line of service code was. Phases 1 through 3 are all done, plus three features shipped ahead of Phase 4: a direct-REST core loop first, then real Kafka events through a real Confluent Schema Registry, then a genuine Account/Customer Service and a polyglot Node.js/TypeScript Notification Service, then a real Green Button/NAESB ESPI usage-data export, a real Stripe test-mode payment integration, and a Grid Operations service correlating real outages and work orders from meters that stop transmitting — six services verified live end-to-end, including a real AccountId-keyed invoice landing in Postgres, a real webhook actually received, a real Stripe payment collected, and real outages detected from a real stopped meter, backed by 102 automated tests.
- Deliberately staged across 6 build phases: a direct-REST core loop (Meter Simulator → Usage Aggregation → Billing) on a single Postgres database first, then Kafka + a schema registry, then Account/Customer Service + a polyglot Node.js Notification Service — all three now complete, plus ESPI data export, Stripe payments, and Grid Operations (outage detection & work orders) shipped ahead of schedule; a React/Redux Toolkit dashboard behind a BFF gateway, GitHub Actions CI/CD, and OpenTelemetry observability come next
- .NET Aspire orchestrating every service from day one; rate-plan billing logic built around the Strategy pattern (flat, tiered, time-of-use), documented in the design document
- 23 real bugs found and fixed by actually running the thing, not just compiling it — logged in
todo.md
Phases 1 through 3 complete, plus ESPI, Stripe, and Grid Operations (outage detection & work orders) — see the README for current phase status rather than assuming it's further along.
BEX — FX Strategy Platform Design (Architecture / .NET Core, GCP, React)
A ground-up architecture and design document for an FX strategy platform serving broker-dealer and commercial-banking needs — design phase only, no service code written yet. The core idea: every FX trading behavior (market making, TWAP/VWAP execution, smart order routing, last look, hedging, NDF pricing) is designed as an interchangeable implementation of one IFxStrategy interface, built directly on the GoF Strategy pattern and selected/versioned at runtime instead of hardcoded per client or desk.
- Full design doc: business requirements (broker-dealer vs. commercial-bank FX needs), the strategy-pattern engine design, a 10-strategy catalog, GCP microservice architecture (GKE, Pub/Sub, Cloud SQL), CI/CD with canary-by-traffic-slice strategy promotion, security/compliance controls, and a phased rollout plan
- Dev environment isolated via a Dev Container (.NET 8 + Node 20, 19 scoped VS Code extensions) so working on it doesn't touch or conflict with any other project's global tooling
- This is architecture/design work, not a running system — see the repo for current status rather than assuming an implementation exists



