Show the work, not just the claims
A case study explains how I reasoned about a system. A public repository lets you check that reasoning against the code — how it's named, where the boundaries sit, what's tested, and what happens when a design turns out to be wrong. A private project can't hand over its source, but it earns its place the same way: it's real production work, and what it shows about how I build doesn't disappear because the code stays closed. This page is here to show the engineering, not only the part of it that's public — the same instinct behind case studies that show tradeoffs instead of victory laps.
Why I publish
I publish work for the same reason the case studies on this site show tradeoffs instead of results alone: claims about engineering quality should be checkable. A repository shows the things a portfolio page can't — how I structure a codebase, where I draw boundaries, what I choose to test, and how I document a decision so the next person doesn't have to reverse-engineer it.
Writing code I expect to be read changes how I write it. Public work gets an honest README, an architecture written down before the implementation, and fewer shortcuts — because the shortcuts are visible too. Where a piece of a project turns out to be generally useful, I pull it out into something reusable rather than leaving it welded to one codebase.
It's also where I learn in the open. Rebuilding a system I've only read about, or trying an approach before I'd risk it on a client's production, happens here first — with the reasoning left in the commit history rather than polished out of it.
Featured projects
A few projects, chosen for what they demonstrate rather than how many stars they have. The public ones link to their source; the private ones are production work whose code I can't share.
Project Planning Platform
Private RepositoryInternal planning platform replacing Jira-centric planning with Google Calendar workflows.
Why it exists
- Moves planning out of Jira and into engineers' daily Google Calendar workflow — simplifying planning for 1,500+ users while cutting licensing cost.
- Bun/Elysia services communicate over gRPC across a polyglot store — PostgreSQL, ScyllaDB and ClickHouse — with Kafka carrying events between them.
- Bun
- Elysia
- TypeScript
- PostgreSQL
- ScyllaDB
- ClickHouse
- Kafka
- Google Calendar API
- gRPC
AutoSocial AI
Private RepositoryAI-powered social media content generation platform.
Why it exists
- Explores autonomous AI workflows, prompt orchestration and production-ready LLM integrations behind a social-content pipeline.
- FastAPI
- LangGraph
- Redis
- Next.js
- OpenAI API
Engineering standards
Every project above is held to the same standard, whether anyone is watching or not. This is what production-quality means in practice, not as a slogan.
README before features
The first thing a stranger sees explains what the project is, why it exists, and how to run it — before it does anything clever.
Architecture before implementation
The shape of the system is written down and reasoned about before the first feature is built on top of it.
Typed APIs
Boundaries are typed, so misuse is a compile error a contributor sees immediately, not a runtime surprise a user finds later.
Testing
Tests exist to document how the system behaves and to protect the parts that must not silently break.
Documentation
Decisions are recorded next to the code — the why, not only the what — because the reasoning is the expensive part to recover.
Maintainability
Every repository is organised for the next person to change it, on the assumption that person won't be me.
Current experiments
What I'm reading into and building with right now — not commitments, just where my attention is.
- Claude Code
- Context Engineering
- AI-assisted software architecture
- Agentic workflows
- Local LLMs
- Event-driven systems
- High-performance Bun backends
Want this standard of engineering on your system?