Data before interpretation
A system should keep observed facts, derived conclusions, and unsupported assumptions separate. The interface should preserve that separation.
Karabeg / MrFrayman
I build software for data-heavy workflows where correctness matters more than novelty. The work is usually practical: define the source of truth, make failure states visible, and keep the system understandable enough to maintain.
Core Philosophy
A system should keep observed facts, derived conclusions, and unsupported assumptions separate. The interface should preserve that separation.
Architecture should prefer explicit contracts, readable flows, and changes that can be reversed without drama.
A dashboard is not decoration. It's where people make decisions, correct records, and notice when the system is wrong.
Selected Systems
Read project deep dives| Project | Type | Primary concern |
|---|---|---|
| Schema-Drift-Detector-CLI | Open-source API safety utility | A CLI utility for comparing JSON structures and catching breaking API changes before they reach the frontend. |
| JS-Static-Call-Graph | Logic auditing utility | A small static-analysis tool that maps JavaScript function calls so a developer can inspect unfamiliar logic faster. |
| PropWatch UAE | Property intelligence engine | A property intelligence system for the UAE market that starts with buildings, not listings. The goal is to avoid treating duplicated or weak property data as fact. |
| Hopen | Urban route-sharing platform | A route-sharing platform built around repeated city travel: where people go, when they go, and which routes can reasonably be shared. |