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
NFT Metadata Storage
IPFS's own documentation is direct that a gateway URL is not the canonical address for NFT data, and EIP-4906 defines the events that tell a marketplace when metadata actually changed rather than merely moved. This guide works through where token metadata and media actually live, tokenURI under EIP-721 and uri with {id} substitution under EIP-1155, a five-option storage decision matrix (fully on-chain, IPFS with redundant pinning, Arweave, an HTTPS server, hybrid) and the failure modes a rushed build can run into: pin loss, gateway shutdown, mutable HTTPS metadata and a reveal whose rarity map can leak before it goes public.
IATA One Record Integration
ONE Record replaces sending a shipment record with publishing it once and granting access by URI, revocable at any time. This guide works through the model behind that standard: the logistics ontology and where its class hierarchy actually breaks, JSON-LD as the serialization, the API surface from creation to audit trail, subscriptions and access delegation, the published Cargo-XML migration path and the version and vocabulary conflicts a real integration hits inside the specification itself.
Battery Passport Data Model
Article 77 of the EU Batteries Regulation requires an electronic record for LMT, industrial and electric-vehicle batteries, and the record is harder to design than it looks. This guide works through the decisions a platform makes when it implements it: why one passport belongs to one battery instance rather than one model, how three access tiers become an authorization model, where custody of the record moves across a battery's life and where a durability figure actually comes from.
Legacy Data Migration Strategy
Google Cloud's own migration guidance states the constraint every cut-over plan has to accept: genuinely zero downtime is impossible. This guide works through the decision a legacy data migration actually turns on, big bang against outbox-based trickle against log-based change data capture, why a dual write without a transactional outbox can silently diverge two databases, reconciliation tiered from row counts to field-level checks and the rehearsal and rollback discipline AWS's own cutover guidance describes.
TCF Consent String
What a first-party platform has to get right when it reads an IAB TCF TC String: three version counters that are not the same number, purpose bitfields indexed from zero while purposes are numbered from one, a vendor list that must be pinned to the version the string names rather than to the newest one, an event-driven read path on web and in app and a consent log that keeps the string itself.
HACCP Software Requirements
A HACCP plan is not a document a platform stores. Treated as a data model it becomes a set of entities: hazards joined to process steps with their reasoning, critical limits that carry a version history, monitoring records naming a person and a device, corrective action as a workflow with states, verification events that point at the records they reviewed and retention expressed as a rule with a named party rather than a number.
Last updated: