About
Platform, data and the systems that have to keep running
Deyan Peev
Founding Engineer · Sofia, Bulgaria
I work at the seam between the product and the platform. Close enough to the product to know why a feature matters, close enough to the platform to know what it will cost to run — and on the hook for both. The problems I gravitate toward are the ones where the constraint is operational rather than algorithmic: systems that have to keep running, migrate without downtime, or scale past whatever their original design assumed.
AI and architecture are where that interest runs deepest: AI applied to how software gets built rather than bolted on as a feature, and the service boundaries, contracts and failure modes that decide whether a distributed system survives contact with production. Close behind those, infrastructure I can rebuild from an empty account, and the data layer underneath it — how data is modelled, where it lives and what it costs to query decides more about a system than the framework wrapped around it, so I have spent a lot of time across relational and document stores, caches and search engines.
That mix is what I do at 1club today, as founding engineer on an AI-native platform for gyms and sports clubs — the cloud footprint in Terraform, the API and data model, the admin and member portals, the mobile check-in app. Before it: platform engineering at OfficeRnD, my own company, and four years at VMware on virtualisation and migration tooling.
Areas of expertise
AI as leverage
Applied to how software gets built, not bolted on as a feature. MCP servers that let assistants work against a platform directly, LLM-driven reporting, and delivery run with agents working from specs kept in the repo. That is how one engineer covers the surface of a team without the codebase becoming a liability.
- MCP
- LLM-driven reporting
- Spec-driven agent delivery
Distributed systems & architecture
Service boundaries, the contracts between them, and what happens when one of them is down. Domain-driven design when the domain earns it, plain interfaces when it does not — plus the monitoring, log aggregation and alerting that make the design honest once it is running.
- Domain-driven design
- gRPC
- GraphQL
- REST
- WebSockets
- Apache Kafka
- Apache Spark
- NestJS
- Go
- Grafana
- Sentry
Cloud & infrastructure as code
Three AWS associate certifications and a HashiCorp Terraform one, but the part that matters is the practice: infrastructure that can be rebuilt from an empty account, and migrations onto it that customers do not notice. I moved a platform off EC2 onto serverless at OfficeRnD, and built a whole Google Cloud footprint from nothing at 1club.
- Terraform
- Pulumi
- AWS CDK
- AWS
- Google Cloud
- Docker
- Kubernetes
- ECS
- Serverless
- Ansible
- GitHub Actions
Data & databases
Relational and document models, caching layers, search and analytics stores — and the migrations between them, which is usually where the real difficulty lives. Most recently a data platform at OfficeRnD; earlier, an RDF triple store and Lucene index behind a scientific search product.
- PostgreSQL
- MongoDB
- Redis
- MySQL
- SQL Server
- Elasticsearch
- OpenSearch
- Lucene
- RDF / SPARQL
How I work
Boring is a feature
The interesting choice and the right choice are rarely the same one. I optimise for the system somebody else can still operate in two years.
Boring is a feature
Own the whole path
Writing the code is a fraction of the job. Deploying it, watching it, and being on the hook when it breaks is what makes the design honest.
Own the whole path
It should not live in one head
Quality gates, black-box test suites, runbooks and written specs. If operating the thing depends on me being available, I have not finished it.
It should not live in one head
Use the multiplier
AI agents against specs in the repo let one engineer cover the surface of a team. The discipline is in the specs, not the prompting.
Use the multiplier
Boring is a feature
The interesting choice and the right choice are rarely the same one. I optimise for the system somebody else can still operate in two years.
Own the whole path
Writing the code is a fraction of the job. Deploying it, watching it, and being on the hook when it breaks is what makes the design honest.
It should not live in one head
Quality gates, black-box test suites, runbooks and written specs. If operating the thing depends on me being available, I have not finished it.
Use the multiplier
AI agents against specs in the repo let one engineer cover the surface of a team. The discipline is in the specs, not the prompting.
Experience
Feb 2026 — Present
Founding Engineer · 1club
An AI-native platform for gyms, studios and sports clubs. Product, cloud platform and delivery pipeline, end to end.
2023 — Jan 2026
Senior Platform Engineer · OfficeRnD
Moved the platform off EC2 onto serverless, pulled shared libraries out of the monolith, and built the monitoring and alerting behind them.
2021 — 2023
Co-Founder · DIV Motion
Leading discovery with CTOs and technology directors at small and mid-sized companies, then architecting and building what came out of it.
2017 — 2021
Software Engineer → Technical Team Lead · VMware
Automation and orchestration for enterprise virtualisation, ending as the lead on client migration planning and the tooling that automated it.
2015 — 2017
Software Consultant · Accedia
Financial, insurance and scientific search systems, and the AWS build and validation pipelines that shipped them.
Education
New Bulgarian University
Master · IT Project Management
2016 — 2018
Technical University of Sofia
Bachelor · Computer and Software Engineering
2012 — 2016
Returned in 2016 as a part-time assistant, teaching the third-semester Java course — OOP, data structures and algorithms.
Certifications
- 2023
AWS Certified SysOps Administrator
Associate
- 2023
AWS Certified Developer
Associate
- 2023
HashiCorp Certified: Terraform
Associate (003)
- 2022
AWS Certified Solutions Architect
Associate
Want to talk shop?
Architecture, platform work, or something you are trying to get unstuck — my inbox is open.
