Carved in code. Built to last.
Got into code because a game made me curious about what was underneath it. Stayed because the problems never stopped being interesting. From infected server files to live streaming platforms — no stack is foreign, no system is too broken to read.
SEE THE CRAFTSome developers write code. Others read systems. The difference shows up the moment something breaks in production at 2am, or when a client's site has been quietly compromised for months and nobody noticed. That's where the interesting work begins.
The path here started with games — not playing them for fun, but pulling apart how they worked, what was underneath the rendering, what logic was driving the decisions. That curiosity became code. The code became systems. The systems became a craft.
Runecraft exists because freelancing, done properly, is about one thing: understanding a client's problem better than they do, then building exactly what solves it — nothing more, nothing less.
Five domains. Each one a system of its own. Each one carved through actual work, not tutorials.
Most projects fail before a single line of code is written. The problem was never understood properly, the scope was never defined honestly, or nobody asked who actually has to use this thing. Every engagement starts the same way — with questions, not assumptions.
Before anything else: What is the end result you need? Where exactly is the problem? Who is the end user? How far do you want me to go? These four questions determine everything that follows.
Every requirement gets examined for what it says and what it doesn't say. The gaps between requirements are where projects fail. Possible outcomes are mapped, assessed, and prepared for presentation — not just the obvious path, but the credible alternatives.
The most credible options are presented with full explanation. Not a list of features — a walkthrough of what each path means, what it costs, what it risks. The client chooses from clarity, not confusion.
Once the path is chosen, it gets stress-tested. Edge cases, market niche, technical constraints, what can go wrong. A second walkthrough follows — more detailed, more precise. By this point the client understands their own product better than when we started. That's intentional.
Work begins only when the picture is complete. Not before. The build follows the map. Adjustments happen — they always do — but the destination stays clear. The end result almost always matches what was pitched. Almost always.
Not waiting for clients to stay sharp. Always making something. These are the things in motion right now.
Building the system I actually want to use. Understanding what makes habits stick before writing a single line of code.
Every free app is either broken or bloated. Building one that does exactly what's needed and nothing else.
First game built from the other side of the screen. Not about shipping something perfect — about understanding how games are actually made.
Odia is disappearing from the digital world. Building something to push back against that. A language deserves more than being forgotten.
Have a problem that needs solving, a system that needs building, or a project that needs a second pair of eyes? Drop a message. No intake forms, no pitch decks required. Just tell me what you're working on.