Founder & engineering leadership
Dmytro Nasyrov
Founder and CTO Pharos Production
Founder of Pharos Production, PhD in Artificial Intelligence and lecturer at Igor Sikorsky Kyiv Polytechnic Institute.
About
Dmytro Nasyrov is the founder and CTO of Pharos Production, a software development and AI engineering company since 2013. With 23 years of engineering experience and a PhD in Artificial Intelligence, he leads engineering culture at Pharos and lectures at Igor Sikorsky Kyiv Polytechnic Institute.
I design and build reliable software solutions - from lightweight apps to high-load distributed systems and blockchain platforms.
PhD in Artificial Intelligence, MSc in Computer Science (with honors), MSc in Electronics & Precision Mechanics.
Education and credentials
- PhD in Artificial Intelligence
- Lecturer, Igor Sikorsky Kyiv Polytechnic Institute
- Alumnus, Igor Sikorsky Kyiv Polytechnic Institute
Areas of expertise
- Artificial Intelligence - LLM integration, RAG, agents, ML platforms
- Blockchain protocols - DeFi, NFT, smart contracts, dApps
- FinTech platforms - payments, compliance, RegTech
- Custom software development - web, mobile, enterprise
- DevOps and cloud architecture
- Engineering leadership - strategy, technical due diligence
Career timeline
-
Founder and CTO, Pharos Production
Software development and AI engineering. 90+ engineers, 110+ apps for 200+ clients across 28 industries. Aligned with ISO 27001, SOC 2, HIPAA, PCI DSS and GDPR frameworks.
-
Lecturer, Igor Sikorsky Kyiv Polytechnic Institute
Teaching engineering at Ukraine's leading technical university.
Ideas from practice
Articles by Dmytro Nasyrov
GPSR Online Marketplaces
A build guide to Regulation (EU) 2023/988 for marketplace platforms: the four listing information blocks and the conditional responsible-person rule as seller-onboarding validation, the two contact points, the clocks on authority orders and notices with their working-day outer bounds, Safety Gate ingest, the recall-notice pipeline with the seven elements Article 36(2) lists, some of them conditional and an evidence log derived from the duties to inform, each mapped to its article.
Bordereaux Reporting
Lloyd's mandates the data set and the Delegated Data Manager is listed as an elective LIMOSS service. A procedural guide to bordereaux reporting for coverholders and MGAs: the risk, premium and claims bordereaux and who produces and receives them, the Coverholder Reporting Standards field set stated by version, then the pipeline from extraction through mapping, validation, exception handling and cadence to delivery and the audit trail.
Secure HLS Delivery
RFC 8216 spends exactly one sentence on protecting an HLS decryption key, and says nothing about who may ask for one. This guide works through the decisions that actually secure a stream: the key request as an authorization decision, signed manifests against signed segment URLs, CDN caching rules that can silently leak a key response and the boundary past which AES-128 stops helping and a licensed DRM system takes over.
OpenXR Cross Platform Development
Khronos's own specification defines OpenXR's extension model around one rule: every extension is optional per runtime, so a codebase has to query extensions with xrEnumerateInstanceExtensionProperties, and optional core features such as STAGE with their own enumeration call, before depending on them. This guide works through the decisions that follow from that rule: action-based input bound to interaction profiles instead of raw controller state, reference spaces with no shared origin, engine-level OpenXR coverage that depends on each engine's own gap list and why visionOS is a separate platform with no OpenXR runtime to target, not another runtime to detect.
RESO Web API Integration
RESO's own wiki defines ListingKey as a local key of the system that issued it, not the durable, cross-system identifier most integration plans assume. This guide works through the ten decisions a RESO Web API integration gets wrong on the second MLS: ModificationTimestamp polling against the EntityEvent alternative, a Lookup layer that resolves a local synonym back to one standard value and what a "RESO certified" server actually promises to expose.
NIS2 Entity Registration
NIS2 puts two different filings behind one word. Member States build the list and require entities to submit identifying information for it, on a two-week update clock, while a narrower set of digital entity types files a longer record with its national authority, corrects it on a three-month clock and has it forwarded to ENISA without its IP ranges. This guide separates the two, marks who is bound by each, and shows what national portals add on top.
Last updated: