Software Engineer / Systems & Open Source / est. 2014
Designing, building & running reliable systems · end‑to‑end.
From pricing engines and data pipelines to POS & fiscal integrations, realtime UIs and server administration · I design and ship software that does the unglamorous work of staying up, staying correct, and staying maintainable. I care about open source, durable architecture, and the kind of craft that shows up years later in someone else's codebase as clarity.
Years of operational experience across four interlocking disciplines. Below · the work I actually do, day to day, mapped to the tools and practices I bring to it.
These are the engagements where my background pays off the most · problems that sit between disciplines, where understanding the whole stack matters more than any single tool.
Service architectures in Python/Django, Java, or C++ · depending on the problem. I design models around the business, not the framework, and I keep the seams between domains explicit so the code stays legible as the system grows.
Angular + TypeScript front ends backed by WebSockets or MQTT for live telemetry, control surfaces and operational dashboards. Strict typing, deliberate state design, accessible UI, and the kind of interaction detail that makes a tool feel competent.
Point-of-sale flows, receipt printers, fiscal devices, ECR protocols and regulatory edge cases. The work that nobody likes touching · the last 5% that decides whether a system can actually go live in a retail or hospitality environment.
Rule-driven pricing, tiered discounts, real-time recalculation, and the ETL machinery that feeds them. I build pricing logic that auditors can read and operators can override, and pipelines whose failure modes are visible rather than mysterious.
Standing up and running Linux servers with the boring parts done right · Postfix & Dovecot tuned, DKIM/DMARC/SPF in good order, TLS automated, nginx and systemd configured properly, logs going somewhere useful. Mail in particular is a craft of its own.
Pragmatic security review for small-to-mid-sized systems · hardening, attack-surface reduction, sane defaults, and credentials done right. I'm also genuinely happy to contribute to open-source projects: from drive-by patches to maintainership and feature work.
Each of these represents a body of work · not a one-off. The kind of problem domains where I can step in, read the existing code, and start contributing within a day rather than a quarter.
Rule-driven, tiered, real-time. Logic that an auditor can read and an operator can override without breaking the model underneath.
Receipt printers, fiscal devices, ECR protocols, regulatory quirks. The unglamorous work that decides whether software can legally go live.
Ingestion, transformation, validation. Batch and stream. Built so failures are visible, replayable, and recoverable · not mysterious.
Angular dashboards backed by WebSockets/MQTT. Live telemetry, control surfaces and operator tools where latency and clarity both matter.
Linux administration with the boring parts done right · Postfix, Dovecot, DKIM/DMARC/SPF, TLS automation, nginx, systemd, logs that actually help.
Contributions, libraries, tooling. From drive-by patches to feature work and maintainership. Genuinely happy to collaborate on things people use.
Everything below is something I've shipped with, not just read about. "Core" means I reach for it without thinking. "Working" means I'm productive in it. "Supporting" means I use it where it fits.
Conviction matters more than fashion. These are the trade-offs I make on every project · the lens through which I read other people's code and the standard I hold my own to.
“Software is communication first. The compiler is just one of the readers.” working principle
Boring tools, used well, win almost every long-running engagement. I reach for the unfashionable, proven choice unless there's a real reason not to.
Every change is a second-order effect waiting to happen. I look for the seam, the queue, the timeout · the places where one component's certainty becomes another's surprise.
Code is communication. I write for the person who replaces me, name things honestly, and prefer the readable diff to the clever one. Comments only where they explain the why.
I design for the system in five years, not the demo in five days. Migrations are planned, secrets rotate, monitoring exists from day one, and someone can take over without a handover doc.
Contracts, long-term collaborations, open-source work, second opinions on architecture, or the kind of weekend favour that turns into a proper engagement · get in touch with what you're working on.
I'm currently accepting new work and happy to talk through what you're building. Short conversations are fine. Long, technical ones are better. Either way, the more context up front, the more useful the first reply.
Bulgarian and English. Comfortable across timezones, but Europe-aligned hours are easiest. Remote-first; in-person where it matters.