Blog

A small website update can affect pages and components that were never meant to change. This is how responsive checks, visual comparisons and release evidence became part of my development workflow.

An RFP response is more than polished writing. Requirements, evidence, compliance and review all need to remain connected before a proposal can be trusted.

A working destination does not tell the whole story of an affiliate link. This is how I approach redirects, tracking information and repeatable audits, and how that thinking shaped Link Crest Pro.

Once AI software starts calling tools, requesting approvals and moving through multi-step workflows, the interface has to explain much more than a conversation. This is how I approach those operational states.

Choosing a web platform is about more than the design. This is how client handover, content ownership, responsive architecture and long-term maintenance shaped PlaySignal in Framer and Nexora in WordPress.

Building a localization handoff tool changed how I think about strings, screenshots, glossaries and context. Here's what I learned while developing it.

Duplicate records, missing information and inconsistent formats can complicate CSV imports. Here's how validation and clear error reporting make the process easier to manage.

Importing CSV or Excel data into React is easy until real-world spreadsheets introduce inconsistent headers, invalid values and large datasets. This guide explains how to build a reliable browser-side import workflow with parsing, column mapping, validation and data preview.

Getting a feature working is only part of a release. These are the checks I have gradually added to my own process to catch regressions, packaging mistakes and other avoidable problems before software reaches the user.

Building games introduced me to a long list of repetitive problems around testing, releases, browser behaviour, data, input and packaging. Over time, some of those problems became useful developer tools of their own.

August was less about building new parts of Axirune and more about getting the finished project in front of people. I prepared a playable itch.io demo, brought the complete Godot source project to Codester and learned how differently the game needed to be presented on YouTube and TikTok.

By July, most of Axirune was already built. The job now was much less exciting: play it repeatedly, find problems, fix them, and work out when I had done enough to finally call the game finished.

Creating Axirune’s finished identity meant moving beyond prototype visuals and building a consistent combination of vector artwork, interface design, music and sound effects that supported the puzzle gameplay.

Designing Axirune meant turning a simple directional-arrow concept into a complete puzzle system. This journal looks at the early game design, grid mechanics, replayability goals and planning that shaped Axirune into a focused 2D puzzle game.

After choosing Godot, the next challenge was learning how its scenes, nodes and scripting system worked. Small experiments with GDScript, input, signals and game logic gradually became the foundations of Axirune's first playable systems.

After defining the direction of my first game, the next decision was choosing an engine that could support a focused 2D puzzle project, an approachable programming workflow and releases across multiple platforms.

Before development began, I researched what kind of game could realistically be created as a solo developer while still offering replayability, accessibility and long-term value.