Portfolio
Full-stack engineer focused on building and scaling real-world systems. I care about trade-offs more than tools, and I design systems around real constraints rather than theoretical ones.
I prefer simple systems that can be evolved over time. I ship early, measure real usage, and adjust based on constraints rather than assumptions.
Most client work is under NDA. What I can share is the architecture, the trade-offs, and what I'd change.
✨ Featured Projects
📣 Promotional Campaign Platform
High-volume code ingestion and real-time consumer interactions across concurrent campaigns
Problem
The platform needed to ingest ~600GB/day of factory-generated product codes and serve real-time consumer campaign interactions across multiple concurrent clients.
What I did
- ›Developed multi-tenant campaign management portal and consumer-facing mobile/PWA apps
- ›Designed real-time scan notification and feedback system
- ›Built modular satellite products extending the core platform for event-specific use cases
- ›Adjusted fraud detection thresholds after observing high false-positive rates impacting campaign engagement
- ›Collaborated across engineering, analytics, and product stakeholders
Impact
- +5,000+ scans/day, higher during peak campaigns
- +Launched new client campaigns without rebuilding the platform from scratch
- +Added new campaign formats without disrupting live campaigns
- +Lowered infrastructure cost for large-scale data analysis
Key Decisions
- ›Multi-tenant core: reuse across campaigns and clients, avoids duplicating logic per client
- ›Modular satellite apps: adapt to new use cases without adding complexity to the shared core
- ›Real-time scan feedback: async-only would break the user loop that drives campaign engagement
- ›Fraud detection calibration: tuned geo-based false positive rate against user friction rather than maximizing detection accuracy at the cost of experience
Constraints
- ›600GB/day ingestion required careful pipeline design to avoid downstream bottlenecks
- ›Fraud detection (geo-based) generated false positives with real user-facing consequences
What I'd change
- ›Separate ingestion and analytics pipelines earlier; conflating them created coupling that made independent scaling harder
Success
Multi-tenant architecture and modular satellite pattern became the reference design for all subsequent client campaigns. Fraud detection reduced abuse while keeping false positive rates below the threshold that broke campaign UX.
Failure
Initial fraud detection thresholds were too aggressive. False positives blocked legitimate users mid-campaign, causing drop-off that only surfaced through support tickets. Required emergency threshold recalibration during a live campaign.
☀️ Solar Plant Monitoring Platform
Real-time telemetry and remote control across a distributed solar fleet
Problem
Operators needed real-time visibility and remote control across 300+ solar plants (~60,000 devices). The existing system couldn't scale reliably under a growing device fleet.
What I did
- ›Led engineering as EM while contributing full-stack and infrastructure
- ›Built real-time monitoring (status, production, alerts) and notification system (Telegram + in-app)
- ›Designed and built remote control system in coordination with the hardware team
- ›Led platform architecture and ML/AI vision integrations (e.g. panel rotation detection)
- ›Iterated on broker architecture after observing scaling bottlenecks under real fleet growth
Impact
- +~4,000 msg/sec at peak (20 messages per device every 5 minutes)
- +Handled more plants per server without adding hardware
- +Remote interventions reduced on-site operation frequency
- +Onboarded new plants without provisioning new servers
Key Decisions
- ›MQTT over HTTP polling: lower latency and significantly lower server load at 60k-device volume
- ›Async processing for non-critical flows: decouples ingestion from downstream consumers, reduces peak load on the ingestion path
- ›Centralized multi-tenant architecture: simpler ops and shared infrastructure vs isolated per-client deployments
Constraints
- ›Had to evolve a production system incrementally without breaking existing behavior
- ›Hardware coupling required continuous cross-team alignment on protocol and timing changes
What I'd change
- ›Decouple ingestion and processing layers earlier; tight coupling created scaling bottlenecks that were expensive to fix retroactively
Success
Scaled to 60,000 devices across 300 plants without infrastructure duplication. Remote control system eliminated the need for frequent on-site interventions and the async architecture kept the ingestion path stable under peak load.
Failure
External energy pricing API returned wrong values during DST transitions without errors. Required retrofitting defensive time-zone handling across the pipeline.
🛡️ B2B Compliance Platform
Compliance tooling with consumer-grade UX for European companies (EM + full-stack)
Problem
Compliance tools had poor usability, leading to low engagement despite mandatory usage. The business needed to monetize through subscriptions while keeping users engaged enough to retain.
What I did
- ›Led engineering as EM while contributing full-stack and infrastructure
- ›Built subscription and access control system (Stripe integration, roles/claims model)
- ›Worked with UX team to simplify navigation and clarify the permissions model for non-technical users
- ›Integrated enterprise systems: SAP for invoicing, LinkedIn API for content
- ›Implemented CI/CD with blue/green deployments, E2E test coverage, and observability
Impact
- +~200 companies onboarded, ~100 MAU per company
- +Subscription model directly monetized the platform
- +Users reported the permissions model was finally understandable after the redesign
- +Zero downtime during releases for paying customers
Key Decisions
- ›Heavy UX investment despite B2B context: compliance tools people actually use outperform technically correct ones they resent; this drove adoption
- ›Blue/green deployments from early on: deployment risk asymmetry with paying customers makes the ops overhead worth it
- ›Embedding-based search for documentation: improved discoverability without requiring a rigid taxonomy
Constraints
- ›Needed to balance enterprise integration complexity (SAP, compliance rules) against the UX simplicity goal
What I'd change
- ›Delay scalability decisions until usage patterns justified them; we overbuilt early under customer pressure and took on complexity that wasn't yet needed
Success
~200 companies onboarded with measurable user satisfaction improvement after the UX redesign. Subscription model successfully monetized the platform. Blue/green deployments maintained zero-downtime for paying customers throughout the rollout.
Failure
Overestimated short-term scale requirements under customer pressure and built infrastructure that sat underutilized. The complexity cost showed up in slower iteration cycles when product direction shifted.
🚚 Truck Management Platform
Cross-platform transport operations system, used by ~3,000 drivers
Problem
Drivers and operators relied on fragmented manual processes. No self-service tooling for drivers meant high support volume and operational friction.
What I did
- ›Built Android, iOS, and web apps with a shared backend architecture
- ›Designed backend and deployment pipeline across all platforms
- ›Worked with UI/UX team on interfaces optimized for non-technical users in mobile contexts
- ›Implemented real-time tracking and driver self-service workflows
Impact
- +Used in production by ~3,000 drivers
- +Camera-based plate scanning replaced manual input, reducing driver errors
- +Driver self-service reduced support ticket volume
- +Real-time visibility improved operator coordination
Key Decisions
- ›Unified architecture across platforms: consistent behavior, faster iteration, and a single backend contract instead of platform-specific divergence
- ›UX investment for non-technical users: driver adoption is the primary success metric; a system they won't use reliably solves nothing
Constraints
- ›Consistent behavior required across mobile and web under variable network conditions (drivers in low-connectivity areas)
What I'd change
- ›Invest in offline-first architecture earlier; network unreliability in field conditions surfaced after release and required retrofitting
Success
Adopted by ~3,000 drivers in production. Camera-based plate scanning and self-service workflows measurably reduced both manual input errors and support ticket volume.
Failure
Shipped without real offline support. Network unreliability in field conditions surfaced quickly post-launch, requiring a retrofit that took significantly longer than building it correctly from the start would have.
🎯 Side Projects
Personal bets. Some in production, some still evolving.
🎟️ Live Events Management Platform
Problem
No off-the-shelf solution handled the full event lifecycle (organizer backoffice, attendee app, face-based check-in) with real multi-tenancy and GDPR compliance built in.
What I built
Multi-tenant PWA: organizer backoffice (events, attendees, payments), attendee app with push notifications, face-based check-in with automatic duplicate detection across photo sets (unsupervised clustering), S3 presigned media uploads, and a web scraper for public event aggregation.
Impact
- +Currently onboarding first organizers
- +Check-in reduced from manual list-scanning to sub-5s per attendee
- +S3 offload handles concurrent media uploads across multiple events without server-side scaling
Key Decision
Multi-tenant from day one: more complex upfront, but avoids a painful schema migration after the platform has real data and real users.
What I'd change
Build with at least one real organizer from week one. Shipping the full product before user validation was an explicit bet: accepted, but won't repeat.
📚 Daily Learning App
Problem
No existing tool properly combined push notifications, structured sessions, and spaced repetition for non-language content.
What I built
Push-notification-driven PWA with a structured session: cold recall question, 30–40 word concept reveal, dual-encoding example (visual + numeric), and a self-graded quiz. Reviews follow a 1-3-7-14-30-90 day schedule; correct answers advance the stage, wrong ones step back.
Impact
- +Used daily for 18+ months
- +100+ concepts loaded across decision theory, mental models, and business strategy
Key Decision
Built custom instead of Anki: needed push notifications and a structured session flow Anki doesn’t support. PWA to skip app store review cycles. Self-graded quiz: trusting user honesty beats building gamification overhead.
🩺 SeeDoctor
Problem
Healthcare providers had no integrated system for patient booking, missed-call follow-up, and automating data entry into their proprietary medical device systems.
What I built
Full scheduling platform: patient-facing booking, provider calendar with real-time availability validation, automated reminders, Android app for missed-call follow-up prompts, and integration with proprietary medical device systems for automated post-appointment data entry.
Impact
- +Active in production with real healthcare providers
- +Missed-call Android app measurably reduced patient drop-off between first contact and booked appointment
- +Device integration eliminated manual data entry for doctors post-appointment
Key Decision
Optimistic locking for concurrent availability: prevents double-bookings without serializing all requests, which would have added latency and complexity proportional to calendar load.
🚀 VPS Deployment Automation
Problem
Deploying 8+ personal projects with different stacks (Next.js, .NET, static) was fragmented. Each project had its own ad-hoc process.
What I built
Each project gets a YAML config declaring its type and target. A local script reads it, runs the correct build, applies per-project post-build transformations, deploys via SFTP+SSH, restarts via Docker, and runs a post-deploy health check.
Impact
- +Standardized deploys across 8+ projects from a single script
- +Cold deploy under 2 minutes end-to-end
- +Post-deploy health check catches failures before I notice them manually
Key Decision
Local script over GitHub Actions: zero cost, works offline, no token management, and doesn't require internet to deploy to a machine on the same VPN.
🤖 Autonomous AI Media Platform
Problem
Triggering an LLM call on every agent interaction in an autonomous system makes cost unpredictable and tightly coupled to activity volume, not output volume.
What I built
Agents stored as rows in PostgreSQL (traits, memories, relationships). State transitions are deterministic; LLMs are called only at render time to produce final prose. Output distributes automatically to web, Twitter/X, and Instagram. Analytics feeds back into agent traits.
Impact
- +Runs continuously with zero human intervention
- +LLM cost stays flat regardless of agent interaction frequency
- +Performance analytics close the loop: top-performing patterns reinforce agent traits
Key Decision
Deferred LLM rendering: compute scales with output volume, not with system activity. Agents as data structures, not services: simpler to query, replay, and debug.
🧠 EmotiveBrain
Problem
Existing journaling and mental health apps prioritize supportive language over honest accountability. I wanted radical honesty with perfect memory and analytical skills, available 24/7.
What I built
Emotional journaling and mood-tracking app with an AI that doesn’t coddle. Surfaces recurring patterns users might not notice in themselves and gives honest, actionable responses rather than generic wellness platitudes. Persistent memory across sessions provides context no stateless chatbot has.
Impact
- +Active personal use over 12+ months
- +Surfaced recurring thought patterns that weren’t consciously noticed
Key Decision
Honest AI over supportive AI: deliberate, driven by direct feedback asking for accountability. Persistent memory across sessions: context is what differentiates this from a stateless chatbot.
📸 Instagram Content Automation
Problem
Testing content strategies manually has high marginal cost per post: writing, generating images, uploading, scheduling.
What I built
End-to-end pipeline: structured criteria → LLM-generated text → AI-generated images and short videos → auto-published to Instagram. Parameterizable by topic, tone, and visual style.
Impact
- +Zero marginal cost per post: pipeline runs on existing infrastructure
- +Batch-test multiple content strategies in one run before investing in manual creation
Key Decision
Parameterizable by topic, tone, and visual style: enables strategy testing at scale without manual effort.
⚙️ GitHub Actions Runner Autoscaler
Problem
Hosted runners have billable minutes and fixed capacity. Self-hosted runners on persistent VMs idle between jobs. The team needed burst CI capacity at low cost.
What I built
Monitors GitHub pending workflow runs and open PRs, provisions Hetzner VMs on demand, registers them as ephemeral self-hosted runners, and terminates them after the job completes. Core provisioning logic covered by integration tests.
Impact
- +Core provisioning logic covered by integration tests
- +Never reached production: honest constraint, noted openly
Key Decision
Ephemeral runners: clean state per job, no configuration drift between runs. Hetzner over AWS: comparable performance at significantly lower cost for burst CI workloads.
💻 Open Source
Public on github.com/omaxel.
- IKEA Rodulf Smart Controller: Reverse-engineered the serial protocol of an IKEA standing desk, built ESP32 firmware, and added a web interface for scheduling and reminders. Full stack from PCB wiring to browser UI.
- SimplePatch: NuGet library for HTTP PATCH in ASP.NET. Cleanly solves partial updates without reflection-heavy workarounds. Published and used in production.
- Meet Light Sync: Browser extension: Elgato Key Light turns on when you join Google Meet, off when you leave. One thing, done well.
- AI Semantic Search: Semantic search using vector embeddings in C# and PostgreSQL. Clean, minimal reference implementation.
- MIDI Graph: Browser tool to record piano note timing and velocity via Web MIDI API with millisecond precision. Built for music/physics visualization research.
Want to dig deeper?
I'm happy to walk through any of these in detail: architecture, trade-offs, what I'd do differently, and what I learned.
Get in touch